Skip to content

Don't use Win32 native APIs on non-Windows for crypto of secure string over remoting#8746

Merged
TravisEz13 merged 2 commits intoPowerShell:masterfrom
SteveL-MSFT:remote-secure-string
Feb 7, 2019
Merged

Don't use Win32 native APIs on non-Windows for crypto of secure string over remoting#8746
TravisEz13 merged 2 commits intoPowerShell:masterfrom
SteveL-MSFT:remote-secure-string

Conversation

@SteveL-MSFT
Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Jan 25, 2019

PR Summary

Remoting relies on Windows native crypto APIs to pass a secure string. Of course these APIs don't work on non-Windows. However, the remoting code does not expect this to fail so ends up in a hang waiting for an event that never happens.

Have not figured out how to return an error to the user in the case Get-Credential is called within a PSSession. Currently it just quietly closes the remote connection. @PaulHigin can you give a pointer to where this code would exist? Debugging the current code, it has a bunch of error handlers which just result in the pssession being closed and not sure where throwing is appropriate.

Fix #8723

PR Context

Fix is to provide implementations of the Win32 native pinvoke apis that throw an exception. The reason to do it this way is that there's a bunch of code that calls some of the APIs of the wrapper .Net class to setup structures that eventually get passed to the win32 api. Throwing in the managed class causes other things to fail early that should work on non-Windows.

PR Checklist

@SteveL-MSFT
Copy link
Member Author

The CodeFactor issues are all on existing code complaining about Hungarian notation which none of them are

Copy link
Contributor

@PaulHigin PaulHigin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems Ok as a temporary change to prevent a hang, although the result for a client initiated key exchange is the termination of the remoting connection. Only slightly better. For a server initiated exchange, a Windows DPAPI dll exception is generated and returned to the user, but the connection remains. We can easily change this (in serialization->HandleSecureString) to throw a better exception, but I see that the original exception gets lost and the user gets an obscure "Root element is missing" error, probably because the remoting packet XML is malformed (serializer is not supposed to throw but simply return nothing on errors). But this may be Ok until we get this working correctly.

@SteveL-MSFT SteveL-MSFT changed the title WIP: Don't use Win32 native APIs on non-Windows for crypto of secure string over remoting Don't use Win32 native APIs on non-Windows for crypto of secure string over remoting Feb 1, 2019
@SteveL-MSFT
Copy link
Member Author

@PaulHigin can you re-review?

@TravisEz13 TravisEz13 added the CL-Engine Indicates that a PR should be marked as an engine change in the Change Log label Feb 7, 2019
@TravisEz13 TravisEz13 merged commit 5ece96a into PowerShell:master Feb 7, 2019
@SteveL-MSFT SteveL-MSFT deleted the remote-secure-string branch February 8, 2019 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-Engine Indicates that a PR should be marked as an engine change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SSH remoting Credential objects from OSX can hard-lock Powershell

3 participants