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

Auto-login password abnormal operation #39

Closed
Joungkyun opened this Issue Apr 17, 2018 · 11 comments

Comments

Projects
None yet
2 participants
@Joungkyun
Member

Joungkyun commented Apr 17, 2018

Report of @Vangelis66 : (#33)

Auto-login password does not work properly on Windows 7 32bit device. Also he reported that he would login successful on Windows 7 64bit machines.

  1. I start iPuTTY-0.70.1-git-0627537, select and load (from file) session SSH_STUNNEL_UK_1;

  2. Navigate to "Connection -> Data", "Auto-login password" field is (of course) empty

  3. Manually type-in (or paste from clipboard) my 9-digit pw, I see 9 black dots.

  4. Navigate to "Sessions", saved sessions field has SSH_STUNNEL_UK_1 inside it, I click "Save" to store the newly input pw info inside the session local file.

  5. Back to "Connection -> Data", "Auto-login password", still 9 black dots are displayed.

  6. Click the Cancel button, iPuTTY 0.70.1 exits.

  7. Start anew iPuTTY 0.70.1 GUI => Sessions => Sessions from file => select SSH_STUNNEL_UK_1 => Load => is displayed in the Saved Sessions field

  8. Navigate to "Connection -> Data", "Auto-login password", now there's 11 blackdots there!

  9. If I click Open button, the session is opened, but, still, auto-login fails due to wrong sent pw:

So, this bug is still there in the x86 flavour of iPuTTY (load from file - in the iPuTTY GUI - a saved session containing auto-login password info), even on Win7 x64 !

@Joungkyun Joungkyun self-assigned this Apr 17, 2018

@Joungkyun Joungkyun added the bug label Apr 17, 2018

@Joungkyun Joungkyun added this to the 0.71 milestone Apr 17, 2018

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 17, 2018

As a result of testing, 32bit binary works well on Windows 10.

@Vangelis66 can you test again with attachted binary?

This bianry print follow message. ===> Password decrypt: (1324)
1

Please check the message on Windows 7 32bit device.

putty-debug-x86.zip

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 18, 2018

I tested with the VirtaulBox Windows 7 32bit image from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/.

However, I could not find the problem. There was no problem logging in as shown in the image below.

It is not an OS or architecture problem, but an environmental problem on the PC where the problem occurred.

11

This ticket will remain on hold until there is a response from the reporter.

@Vangelis66

This comment has been minimized.

Contributor

Vangelis66 commented Apr 18, 2018

This ticket will remain on hold until there is a response from the reporter.

... Thanks; do realise though we're many time zones apart, plus real life issues and other work/projects on my laptop meant I could not respond that promptly to #39 (comment)

Please check the message on Windows 7 32bit device.

putty-debug-x86.zip

OK, I fetched what is the debug version of iPuTTY-0.70.0-x86 (win32), or at least that's what it claims to be...

OSes that was tested on (actual 2 different machines, not VMs):

  1. Windows Vista SP2 32-bit (fully updated+Windows Server 2008 SP2 post-EOL updates, omitting the M & S patches), 3GB RAM
  2. Windows 7 SP1 32-bit (fully updated, Apr 2018 updates, including the Meltdown+Spectre patches), 3GB RAM
  3. Windows 7 SP1 64-bit (fully updated, Apr 2018 updates, including the Meltdown+Spectre patches), 4GB RAM

TL:DR: The issue persists on all 3 OSes tested, actually the debug version is worse in that context to the non-debug binaries already provided for testing.

What I did:

Launch iPuTTY (hitherto implies the putty-debug-x86.exe binary), select from file and load the session with no password previously saved inside it, type via keyboard the password (9 letters of English alphabet), return to Sessions tab and Save loaded session; returning to the Data tab (without exiting iPuTTY), this is what I see:

p1

(If, at that point, I click the Open button, the correct pw string will be sent and the SSH session will be established!)

Exit iPuTTY (Cancel button or X window red button)
Relaunch iPuTTY; Sessions tab, Sessions from file is selected, select SSH_STUNNEL_UK_1 from the list and click Load:
p2

... then switch to the Data tab; this is what I see:

p3

Instead of a 9-dot pw, there are now twenty (20) dots in the pw field (only 18 captured in the snapshot); with previously tested binaries, it was eleven (11) dots instead of 9...
Clicking the Open button results, as one would expect, in failure to authenticate:

p4

Please note that the "decrypted" part of the pw I have enclosed inside the blue-lined rectangle actually contains the correct 9 characters of my pw, but is then appended with the red-lined rectangle gibberish, which seems to contain random parts with every other iPuTTY invocation...
I cannot publicly disclose my pw string, since the SSH service used (displayed in the terminal window) "embeds" the pw to the username (so one can easily retrieve it), thus it'd be easy to figure that out and compromise my account...

It is not an OS or architecture problem

As stated, the issue I face involves only the 32-bit binaries of IPuTTY, but is still reproducible (by me) when running these on a x64 OS (Win7 SP1); I don't have access to Win8.1/Win10 of either architecture to test 😞

but an environmental problem on the PC where the problem occurred.

I am able to reproduce on two different machines, with vastly different setups:

  1. An older Toshiba laptop which can dual-boot between WinVistaSP2x86 + Win7SP1x86 (OS 1+2)
  2. A newer Dell laptop that runs (only) Win7SP1x64 (OS 3)

Possible but unlikely both machines suffer from the same ailment...

I tested with the VirtaulBox Windows 7 32bit image
(snip)
I could not find the problem. There was no problem logging in

It is unfortunate 😞 you can't reproduce even in a VM (which was what I'd suggest you try as a last resort...), this means there's close to no hope of solving this conundrum...

  1. Was your virtual Win7 machine fully updated? Perhaps there are some Windows Updates that mess this up, hard to tell...
  2. I can only invite you to test the service at
    https://www.fastssh.com/page/ssh-ssl-stunnel-servers/6 => SSH STUNNEL UK 1 => https://www.fastssh.com/page/ssh-account-creator-stunnel/server/1001033/ssh-stunnel-uk-1/

Remember, you have to select Don't start a shell or command at all and Enable compression in the SSH tab!; you could try that using x86 iPuTTY on Win7SP1 (fully updated), either x86/x64 (but I have 0 hope you'd be able to verify; just a very long shot...

I think I am finished testing; you and I have spent considerable time on this; unless others can step up, I can perfectly live with the simple workaround, that is issue the password string (in plain/unencrypted form) in the cmdline via -pw option; tested to work OK even with latest debug binary...
As I am some decades past my youth, I had better preserve my grey brain cells than waste them further over this... You look quite a young person (and may you live to be a 100), you'll start thinking like me when your age grows up in the 45+ region... 😃

Warmest greetings!

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 18, 2018

Thanks for test.

I have a question.

I understood that the decrypted string consists of complete passwords and additional garbage data. Is right?

For example, if the actual password is asdf, is the decrypted string displayed as asdf ■ ☏▦▦v▦?

If what I understand is right, padding of base64 decoding seems to be a problem.

You look quite a young person (and may you live to be a 100), you'll start thinking like me when your age grows up in the 45+ region...

Thanks, but I am not sadly young. I'm getting closer to 50 years old.

@Vangelis66

This comment has been minimized.

Contributor

Vangelis66 commented Apr 18, 2018

I understood that the decrypted string consists of complete passwords and additional garbage data.
Is right?
For example, if the actual password is asdf, is the decrypted string displayed as asdf ■ ☏▦▦v▦?

You nailed it (exactly that)! 👍

I did some further tests; you said previously that iPuTTY uses PuTTY's base64encode to encrypt and store the password string inside the savedsession local file; let's use for testing the fake password lollipop
I used an on-line service, encrypting that produces:
base64encode(lollipop) => bG9sbGlwb3A=

Now, I open putty-debug-x86.exe GUI, load session, input lollipop as the 9-char pw in the Auto-login password field, switch to Sessions tab and save the modification to the loaded session; then exit iPuTTY.
Session file "SSH_STUNNEL_UK_1" is opened with a text editor, "password" is searched; line 217 reads:
UserPassword\%2AA3bwlGbs9Gb\
Since = = A2%, the encrypted pw inside the file is the string produced by the online service, but in reverse order ( L-R => R-L ); is this expected and correct? If affirmative, we are sure the encryption upon saving is OK, what suffers is reading/decryption upon subsequent loads of the session file...

Launching iPuTTY, selecting and loading session with fake pw, then switching to Data tab, I can see 8 (not 9) blackdots in the pw field; clicking Open will result in:

p6

which suggests that the pw is correctly decrypted (but of course fails to authenticate, being a fake one)!

ISN'T ALL THIS JUST PURE MADNESS????

If I'm still sane, this implies the problem may lie with my actual (non-fake) password string, which creates decryption errors only on the x86 version of iPuTTY (????????)

I've taken the liberty of acquiring the e-mail address on your public GitHub profile (any affiliation with Daum PotPlayer?) and shall forward that password string for further troubleshooting on your part...

Thanks for your patience, I am certainly going mad myself... 😠

PS/OT:

I'm getting closer to 50 years old

Crossed that bridge some years ago... 😑

@Joungkyun Joungkyun added bug minor and removed pending labels Apr 18, 2018

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 18, 2018

Got it. I have a suspicious code and have modified it. Probably guess that a problem occurs when the length of password is a multiple of three.

Attach the modified binary and test again please.

putty-debug-2.zip

@Vangelis66

This comment has been minimized.

Contributor

Vangelis66 commented Apr 18, 2018

and shall forward that password string for further troubleshooting on your part

e-mail sent (check spam folder in case gmail filters it!)

Attach the modified binary and test again please.

Unfortunately, I will be unavailble for the next 3 hours (leave home; still on the 18th here) and I fear it's already very early in the morning in Korea as it is; testing will have to wait until I get back, or until tomorrow, perhaps...

Best wishes

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 18, 2018

e-mail sent (check spam folder in case gmail filters it!)

Looking at the results of your test, I think the problem seems to fit with what I think. I will look at the test results, and I will continue to look at the emails if they continue to have problems. (If there is no problem, I will delete it without seeing it.)

Unfortunately, I will be unavailble for the next 3 hours (leave home; still on the 18th here) and I fear it's already very early in the morning in Korea as it is; testing will have to wait until I get back, or until tomorrow, perhaps...

Don't worry. It is early morning as you think. Now I'm going to sleep. you can test it slowly or don't test.

Absolutely, thank you for your testing.

@Vangelis66

This comment has been minimized.

Contributor

Vangelis66 commented Apr 19, 2018

Probably guess that a problem occurs when the length of password is a multiple of three.
Attach the modified binary and test again please.

... OK, back to testing latest attached x86 binary, putty-debug-2.exe, modification timestamp 20180418192635Z:

As previously, same steps were followed:

Launch putty-debug-2.exe, select and load from file the session named SSH_STUNNEL_UK_1 with no password previously saved inside it; switch to Data tab, type via keyboard the valid password (9 letters of English alphabet), return to Sessions tab and Save loaded session; exit iPuTTY

Relaunch the iPuTTY configuration GUI, select and load from file the session named SSH_STUNNEL_UK_1; switch to Data tab, observe the Auto login password input field: it now displays 9 black dots, which is a first good sign 👍

Click the Open button, terminal window launches; even though this special debug build doesn't display the ===> Password decrypt: (<pwstring>) line, it appears authentication with the SSH server SUCCEEDS:

p8

IOW, 🥇🥇🥇🥇🥇 👍👍👍👍👍 😍
you have fixed the issue!!!!
I also verified from the cmdline,
"path\to\putty-debug-2.exe" -loadfile "SSH_STUNNEL_UK_1"
successfully loads, authenticates and initiates the session (no -pw switch needed in this case...).

In all honesty, I have to admit that was one of the most nasty and sneaky software bugs I have ever come across:

  1. Because of my OS bitness, I had to use x86 binary of iPuTTY;
  2. Bug exists only in x86 binary of the app, but only manifests itself with a specific type of password string!

That behaviour made it very hard for the maintainer to reproduce, since nowadays most OSes (MacOS, Linux, Win10) are 64-bit (and users choose to install 64-bit apps), and even harder for me to convince said maintainer I was actually experiencing the bug, not making this all up in my head 😧.
It certainly wasn't

an environmental problem on the PC where the problem occurred.

Anyhow, all's well that ends well, my most sincere congratulations to the dev for squashing that bug!

I will look at the test results, and I will continue to look at the emails
if they continue to have problems. (If there is no problem, I will delete it without seeing it.)

I trust you totally with the content of my e-mail; you can safely view it after Apr 25th, when my account will have expired, to see the actual pw that was causing my issue (and further tailor your code, if it's needed).

Absolutely, thank you for your testing.

Thank you for believing in me thus far, many thanks for the actual fix!

Now, with two out of three issues (reported by me) resolved, you'll have to improve iPuTTY so it's able to save sshhostkeys to the filesystem also, not only in the registry; perhaps a user selected setting could be introduced inside the GUI or something more automated

  1. When a registry session is exported to the filesystem, also export associated sshhostkeys (from reg to file)
  2. When a session is loaded from the file system, also load from there the associated sshhostkeys if present, else store obtained sshhostkeys for that session to local file system (./sshhostkeys/*), too...
    This is similar to how "kitty_portable" and "PuTTYPortable" do it...

Cheers and best regards 😃

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 20, 2018

you have fixed the issue!!!!

Okay, then this ticket will close. And I plan to release it at 0.70.1 this weekend.

Now, with two out of three issues (reported by me) resolved, you'll have to improve iPuTTY so it's able to save sshhostkeys to the filesystem also, not only in the registry; perhaps a user selected setting could be introduced inside the GUI or something more automated

This problem is somewhat confusing. Is this the case other than the test I've done?
If you continue to have comments on this issue, I would like to proceed to another ticket.

My tests and results are:

All of the tests below are for connection using file session.

Case 1. If the key is in the registry and not in the file system (sshhostkeys/):

A pop-up window appears for the next process.

  1. Move registry key to file system
  2. Copy registry key to file system
  3. Do not do anything.

Case 2. If key does not have both registry and file system (sshhostkeys/):

  1. key does not exist. Ask if you want to save it.
  2. When save, it is saved in the file system (sshhostkeys/).
  3. When reconnect, there is no message associated with the key.

Case 3. If the key is not in the registry and is in the file system (sshhostkeys/):

The connection succeeds without any message.

@Joungkyun Joungkyun closed this in 948c251 Apr 20, 2018

@Joungkyun

This comment has been minimized.

Member

Joungkyun commented Apr 20, 2018

Whether the release is needed a little concern.
First, attach the snapshot build of today.

iPuTTY-201804210208.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment