Isn't this "DLL hijacking" thing a bit overblown? The directory an application runs from on Windows has always been considered part of the security perimeter of the application.

If you can drop a malicious DLL where putty.exe lives, can't you just drop a malicious putty.exe?

It's bad if you use an insecure browser like Chrome. Chrome allows any website you visit to download DLLs directly to your Downloads directory without user interaction. Then, any installer you download and run will use the infected DLLs unless specifically keyed to look in system32 for them.

Additionally, something can infect your PC and alter your PATH. Then PuTTY might pick up a fake Windows DLL from elsewhere on your machine. But if your machine is infected and something is messing with the Windows path, you have bigger problems.

Thankfully Chrome has fixed this issue. I just tried this and Chrome actually warns you about downloading DLLs and requires further user interaction to actually download DLL to the downloads folder:

Screenshot: https://i.imgur.com/MvRwZBi.png

All DLLs or just specific ones? I'd heard a while ago they were going to blacklist specific ones instead of just making it so a user has to purposely decide to download a file.

I'm surprised they finally did something since we've been warning people not to use Chrome because of this issue for years.

>blacklist specific ones

Enumerating badness has always been a very bad idea.

I'll add that to my list of bad ideas.

Not a windows person, so I can't speak to how the directory is treated, but I've watched enough people run applications from the Downloads directory to wonder about it.

That's an interesting point, otherwise I'd say it's basically the Windows equivalent of LD_PRELOAD. Running executables from the "downloads" directory is certainly a thing though, never realized the security implication there (beyond trusting the download natch)

with putty i would be surprised if most didn't run it straight from the desktop. i would be a dirty liar if i said i haven't, countless times.

This. Without an installer that puts a link into the start menu, everyone I've ever worked with just dumps it on the desktop. I used to throw a symlink into the start menu, but when other devs used my machine they expected it to be on the desktop. Just one of those quirks of using PUTTY

But why not just use the installer?

For a long time, there wasn't an installer for putty, so a lot of us became accustomed to just dropping the binary on our desktop or "bin" folder", but there is an installer now. Also, certain corporate environments that preclude the installer from working correctly, but won't mind you "installing" a program to your desktop/local app data.

I find the corporate environment thing suspicious. I could imagine that if you don't have admin access, you can't install to Program Files, but couldn't you still install to your home directory, and still get those lovely start menu shortcuts?

Not really.

Windows, by default requests elevated rights from the user (the UAC dialog) if you run any exe that has 'setup' or 'install' in the name, or if the manifest inside/alongside the exe defines a requirement for elevated rights.

You can spot these files as they have a little Windows 'shield' overlay on their icons (Windows overlays that itself if it detects a file needing elevated rights).

So, unless you can elevate your rights (i.e. be admin, or type in admin credentials), you can't run most installers.

However, prior to Windows 7 your personal start menu folder wasn't locked down - and as a non-admin you could easily add/remove shortcuts from it. Since Windows 7 onwards it's now protected, so you need to elevate to be able to write to it.

Windows allows you to run (by default) software from ANY folder you like, but you can only (by default, again) write to some of your user folders and the the %TEMP% location.

So downloading the PuTTY exe and running it from the downloads folder or desktop is perfectly legitimate, although not good practice.

As an aside: I'm not sure if Chrome still does it, but I recall that if you try to install it and you don't have admin rights, it just puts an icon on your desktop, and installs all the chrome files into a folder under ProgramData which resides in your user hierarchy, instead of the locked down Program Files area. Which is one way of getting around the lack of admin-rights.

Huh. I think that's a poor design choice on the part of the Windows folks, but they probably know things I don't.

You know in order to secure an old house, you just nail boards over all the openings? Well, yeah, that's the Windows security model that is. :)

ouch

I was going to say putty does not have an installer, but TIL putty now has an installer..

Can't say anything definitive about “overblown”, but I like the change.

Windows security model is inadequate, but it's good to work around it anyway.

How is Window's security model inadequate?

You can download/put different modules into the same folder and they will interact without any checks because of name clashes. Programs should be complete packages that depend only on known, protected system32-like locations.

Thank so much for posting this. Perchance, could you remove the quote formatting as it makes it nearly impossible to read on mobile?

Security fix: an integer overflow bug in the agent forwarding code. See vuln-agent-fwd-overflow.

Security fix: the Windows PuTTY binaries should no longer be vulnerable to hijacking by specially named DLLs in the same directory (on versions of Windows where they previously were). See vuln-indirect-dll-hijack.

Windows PuTTY no longer sets a restrictive process ACL by default, because this turned out to inconvenience too many legitimate applications such as NVDA and TortoiseGit. You can still manually request a restricted ACL using the command-line option -restrict-acl.

The Windows PuTTY tools now come in a 64-bit version.

The Windows PuTTY tools now have Windows's ASLR and DEP security features turned on.

Support for elliptic-curve cryptography (the NIST curves and 25519), for host keys, user authentication keys, and key exchange.

Support for importing and exporting OpenSSH's new private key format.

Host key preference policy change: PuTTY prefers host key formats for which it already knows the key.

Run-time option (from the system menu / Ctrl-right-click menu) to retrieve other host keys from the same server (which cross-certifies them using the session key established using an already-known key) and add them to the known host-keys database.

The Unix GUI PuTTY tools can now be built against GTK 3.

There is now a Unix version of Pageant.

Cheers. A couple of nice features here, might even start using the 64 bit version though I doubt it will have much impact.

Or visit the source: http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.ht...

Thanks, this is probably a better landing page for HN than the linked release page!

I had a quick hunt for it but couldn't see it on the release page.

This release also adds support for the ChaCha20 AEAD cipher and encrypt-then-MAC modes for non-AEAD ciphers. Not sure why those aren't included in the release notes.

> Support for importing and exporting OpenSSH's new private key format

What new private key format is that?

Buried in the FAQ and not in the changelog for some reason:-

As of 0.68, PuTTY will no longer fall back to SSH-1 if the server doesn't appear to support SSH-2; you must explicitly ask for SSH-1.

This is the information I came to find. Thanks!

Why would such a small, simple program need to be 64 bit? Exactly what changes when moving puTTY from 32 bit to 64 bit? It now takes up more memory?

We are well beyond moving to 64bit on a needs-only basis. At this point it's about dropping legacy and future proofing. There's also no reason 64bit apps should have a larger memory footprint; the ISA and addressing modes are actually much tidier.

Here are the reasons they now provide a 64bit version: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/w...

The most likely reason is ASLR support, since you have more address space available for randomisation. Other than that, you can probably get a slight boost in performance from the differences between x64 and x86, but lose out if the code is particularly pointer-heavy.