Windows Security change affecting PowerShell
January 9, 2019
The recent (1/8/2019) Windows security patch CVE-2019-0543, has introduced a breaking change for a PowerShell remoting scenario. It is a narrowly scoped scenario that should have low impact for most users.
The breaking change only affects local loopback remoting, which is a PowerShell remote connection made back to the same machine, while using non-Administrator credentials.
PowerShell remoting endpoints do not allow access to non-Administrator accounts by default. However, it is possible to modify endpoint configurations, or create new custom endpoint configurations, that do allow non-Administrator account access. So you would not be affected by this change, unless you explicitly set up loopback endpoints on your machine to allow non-Administrator account access.
# Create endpoint that allows Users group access PS > Register-PSSessionConfiguration -Name MyNonAdmin -SecurityDescriptorSddl 'O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;BU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)' -Force # Create non-Admin credential PS > $nonAdminCred = Get-Credential ~\NonAdminUser # Create a loopback remote session to custom endpoint using non-Admin credential PS > $session = New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin -Credential $nonAdminCred New-PSSession : [localhost] Connecting to remote server localhost failed with the following error message : The WSMan service could not launch a host process to process the given request. Make sure the WSMan provider host server and proxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:1 + New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin - ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2146959355,PSSessionOpenFailed
The above example fails only when using non-Administrator credentials, and the connection is made back to the same machine (localhost). Administrator credentials still work. And the above scenario will work when remoting off-box to another machine.
# Create Admin credential PS > $adminCred = Get-Credential ~\AdminUser # Create a loopback remote session to custom endpoint using Admin credential PS > $session = New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin -Credential $adminCred PS > $session Id Name ComputerName ComputerType State ConfigurationName Availability -- ---- ------------ ------------ ----- ----------------- ------------ 1 WinRM1 localhost RemoteMachine Opened MyNonAdmin Available
The above example uses Administrator credentials to the same MyNonAdmin custom endpoint, and the connection is made back to the same machine (localhost). The session is created successfully using Administrator credentials.
The breaking change is not in PowerShell but in a system security fix that restricts process creation between Windows sessions. This fix is preventing WinRM (which PowerShell uses as a remoting transport and host) from successfully creating the remote session host, for this particular scenario. There are no plans to update WinRM.
This affects Windows PowerShell and PowerShell Core 6 (PSCore6) WinRM based remoting.
This does not affect SSH remoting with PSCore6.
This does not affect JEA (Just Enough Administration) sessions.
A workaround for a loopback connection is to always use Administrator credentials.
Another option is to use PSCore6 with SSH remoting.
Senior Software Engineer