{"id":14553,"date":"2019-01-10T09:27:36","date_gmt":"2019-01-10T17:27:36","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/powershell\/?p=14495"},"modified":"2019-02-20T00:03:28","modified_gmt":"2019-02-20T07:03:28","slug":"windows-security-change-affecting-powershell","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/windows-security-change-affecting-powershell\/","title":{"rendered":"Windows Security change affecting PowerShell"},"content":{"rendered":"
\n

<\/a>Windows Security change affecting PowerShell<\/h2>\n

January 9, 2019<\/p>\n

The recent (1\/8\/2019) Windows security patch CVE-2019-0543<\/a>, has introduced a breaking change for a PowerShell remoting scenario. It is a narrowly scoped scenario that should have low impact for most users.<\/p>\n

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.<\/p>\n

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.<\/p>\n

<\/a>Example of broken loopback scenario<\/h2>\n
# Create endpoint that allows Users group access\r\nPS > 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\r\n\r\n# Create non-Admin credential\r\nPS > $nonAdminCred = Get-Credential ~\\NonAdminUser\r\n\r\n# Create a loopback remote session to custom endpoint using non-Admin credential\r\nPS > $session = New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin -Credential $nonAdminCred\r\n\r\nNew-PSSession : [localhost] Connecting to remote server localhost failed with the following error message : The WSMan\r\nservice could not launch a host process to process the given request.  Make sure the WSMan provider host server and\r\nproxy are properly registered. For more information, see the about_Remote_Troubleshooting Help topic.\r\nAt line:1 char:1\r\n+ New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin - ...\r\n+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin\r\n   gTransportException\r\n    + FullyQualifiedErrorId : -2146959355,PSSessionOpenFailed<\/pre>\n
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.<\/p>\n
<\/a>Example of working loopback scenario<\/h2>\n
# Create Admin credential\r\nPS > $adminCred = Get-Credential ~\\AdminUser\r\n\r\n# Create a loopback remote session to custom endpoint using Admin credential\r\nPS > $session = New-PSSession -ComputerName localhost -ConfigurationName MyNonAdmin -Credential $adminCred\r\nPS > $session\r\n\r\n Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability\r\n -- ----            ------------    ------------    -----         -----------------     ------------\r\n  1 WinRM1          localhost       RemoteMachine   Opened        MyNonAdmin               Available<\/pre>\n
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.<\/p>\n
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.<\/p>\n
This affects Windows PowerShell and PowerShell Core 6 (PSCore6) WinRM based remoting.<\/p>\n
This does not affect SSH remoting with PSCore6.<\/p>\n
This does not affect JEA<\/a> (Just Enough Administration) sessions.<\/p>\n
A workaround for a loopback connection is to always use Administrator credentials.<\/p>\n
Another option is to use PSCore6 with SSH remoting.<\/p>\n
Paul Higinbotham\nSenior Software Engineer\nPowerShell Team<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":600,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-14553","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"blog_post_summary":"
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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/14553","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/600"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=14553"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/14553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=14553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=14553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=14553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}