Thanks to visit codestin.com
Credit goes to github.com

Skip to content

bug: Windows-RDP - password field in Devolution Form is not populated correctly #20

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bjornrobertsson opened this issue May 6, 2025 · 0 comments

Comments

@bjornrobertsson
Copy link

bjornrobertsson commented May 6, 2025

Extension: Windows-RDP
Platform: Coder/Workspaces
Guest OS: Windows VM

Description:
When submitting passwords through the Devolution Form in the Windows-RDP extension, any backslash (\) characters are omitted, resulting in incorrect password transmission.

Steps to Reproduce:

Include the Windows-RDP extension in a Workspace. Start it and use the 'Windows-RDP' Agent.

Observe that the password provided in the form is 'N;JVOUmL^aP', not 'N;JVOU\mL^aP' missing the backslash (using the 👁️ to reveal the password) and compare it to the Workspace UI.

Submit the Devolutions form/login with the filled-in data (remote host is localhost, but shows as undefined, this does not make any difference to the exercise)

Expected Behavior:
The password should be transmitted identical from the Workspace UI password/user password, preserving all characters, including backslashes.

Actual Behavior:
The backslash character is omitted from the password upon submission, leading to authentication failures, InvalidToken: CredSSP ... STATUS_LOGON_FAILURE [0xc000006d]

Impact:
This issue prevents users from authenticating when their passwords contain backslashes, which are common in complex passwords.

Potentially Affected Characters:
While the backslash is confirmed to be affected, other special characters may also be mishandled. Characters that often require escaping and could be impacted are listed here as a need to test:
This will also be 'random issue' for users where their requirement of special characters and/or randomness of the generated password will sometimes include all working characters.

  • Double quotes (")
  • Single quotes (')
  • Ampersands (&) and other 'HTML agnostic characters' such as % : \ $ @
  • Less than (<) and greater than (>) symbols
  • Pipes and redirection characters (| < >)
  • Caret (^) OK
  • Tilde (~)
  • Programmable characters that may be affected in parsing data {} [], although curly braces were found in the example to work ok

Suggested Investigation:
Review the input handling and encoding mechanisms within the Devolution Form, particularly focusing on how special characters are processed and transmitted. Ensure that characters like backslashes are properly escaped or encoded to prevent omission or misinterpretation.

Additional Notes:
This issue aligns with generic problems where special characters in passwords cause authentication failures due to improper handling. For instance, a similar issue was reported where the ` (backtick) character in passwords led to login problems in RDP sessions .

This shows another potential issue where we might not always control the password or if the user does not use the random_password (which could exclude \ character) and a more sturdy method is needed.

@Parkreiner Parkreiner transferred this issue from coder/modules May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant