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.
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:
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.
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)
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
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?
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.
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.
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.
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.
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.
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.
Long time user of Putty, like many here. I liked this quote from their FAQ (A.3.3 What's the point of the Unix port? Unix has OpenSSH):
"There were development advantages as well; porting PuTTY to Unix was a valuable path-finding effort for other future ports, and also allowed us to use the excellent Linux tool Valgrind to help with debugging, which has already improved PuTTY's stability on all platforms."
This sort of development is often illuminating. I develop on *BSD, Linux, Solaris (SPARC), and MacOS X when I can, and even though they're "all UNIX", interesting insights abound, and dealing w different endianess (SPARC == big, Intel == small), and library differences, etc is rarely more trouble than it's worth.
Are you using an insider build or a different shell than Windows' cmd? I find myself using Putty to connect to a Linux subsystem ssh server just to get a decent terminal emulator with full colour support!
I did try conemu when bash for windows was first released, but ran into some problems. Will definitely try again, thanks! Though the wsltty linked below looks promising as well
Same here, but I can't figure out how to fix my main annoyance with the WSL: deactivating the bell!!! There is no reason for my computer to be making noises when I'm using tab completion!!!!!!!!!!
To disable beep of the bash you need to uncomment/add set bell-style none in your /etc/inputrc file
To disable beep of programs like vim (I've tested only with that) you need to create - if it's not already there - a .bash_profile and add setterm -blength 0
I don't use PuTTY either for the same reasons as you, but I do continue to use Pageant. I use a mix of Windows and Linux tools and I only really want to enter my SSH cert credentials at start-up. So I still end up installing it.
I also use Bitvise for tunneling on the Windows side as well.
Sort of... the Bitvise SSH client I use for tunneling, it comes out of box understanding that Pageant is an available agent and will reference it; a lot of tools know that PuTTY is common and therefore expect the tools to be present.
With git and tools that use Git, PuTTY distributes plink.exe, which acts as a helper. So you set something like...
GIT_SSH=c:\Program Files\Putty\plink.exe
To make that happen. So PuTTY is not my shell, but is still pretty important for its good set of overall tools.
the problem is that putty's terminal window (as far as I know) doesn't work in local, so if you are doing local terminal-based work (vagrant git etc) and then you need to ssh, you can't do everything with putty's terminal, but you can do all of the above with git bash.
Or cygwin that has easy to use gui package manager, iirc. Msys2 is a mess, but for non-development uses it should be ok, once you learn how to win in pacman.
This is a possibility. But downloads have been served out of "the.earth.li/~sgtatham/putty/" for years. Yes, it's owned by someone else and exploding turtles all the way down [1], but now that "the.earth.li/~sgtatham/putty/" is HTTPS, the checksums are properly authentic as attested by the same operator as the one who has supplied PuTTY downloads for years.
I've mirrored the most important checksums here, another HTTPS site, so that if any of them ever differ you know to distrust the files.
This requires custom knowledge. If an attacker swaps out the page and serves the links from some other unusual site (or even the.earht.li), who is going to notice? Only old-school people with that custom knowledge who also check the source of the download link.
I find it bizarre that the server is managed by the guy who wrote dpkg (which involves GPG), yet still doesn't have https on it...
How is that supposed to help? Even if the legitimate binaries are Authenticode-signed now, a malicious non-Authenticode-signed binary substituted by an attacker MITMing the insecure HTTP connection will appear to the downloader to look just like the legitimate non-Authenticode-signed binaries of previous versions that they’ve been downloading for years.
Because you can add the signing cert to your AppLocker whitelist, and now it will be checked every time it runs. Then you push that out by GPO, and now everyone has that same whitelist protection.
Also, as mentioned other places on the thread, the downloads are over HTTPS.
When I started my career nearly 20 years ago, back before one could convince a Fortune-100 company to let its peons use Linux on our desktops and Apple hadn't yet had its renascence, PuTTY was a veritable godsend: it did what was needed, and did it remarkably well.
It's been years since I was allowed to add a Linux box, and years since I switched to Linux full-time, and now I honestly think that I'd reject a job offer which required Windows (and maybe even one which required macOS) — but for all those years of Just Working™, thanks PuTTY!
I use PuTTY and connect to a tmux server afterwards.. tabs / sessions / programmable interactions with the terminal are a life saver that tmux provides. Give it a try.
I just wanted to recommend ZOC (Which may some people still know from the good old Amiga times). It's available for Windows and MacOS. ZOC does have some really incredible features (integrated file transfer, multi-execution, team-directories). It's similar prices as MobaXterm, but doesn't have XWindows support.
If you don't need X-Window support, but rich terminal/ssh features, it may be a ($70) try.
It's definitely very good and has a lot to offer, but I still can't justify $70 for some reason. The free version offers enough functionality to be a very good PuTTY alternative though.
I was about to, until I read the fine print and realized it's $70 to buy, but you'll only get updates for a year; after that you buy again or stick with your current version - no bug fixes. Were there a more reasonable price for non-commercial use, I would have no problem buying sooner.
On the other hand, its has the only windows Mosh implementation...the best thing since sliced bread and tmux!
Since I switched to cygwin for ssh on windows I haven't looked back, putty is awful for someone coming from Linux normally and only forced to use Windows for certain things.
I used to use PuTTY as my go-to windows SSH client. After some time I decided to integrate a piece of software with Pageant and I decided to open up the source to PuTTY. The poor quality of the source code terrified me, it seemed sort of "all over the place" and there seemed to be little to no concern for security and defensive programming.
Secure software design and development is what I do for a living, so perhaps I am a bit more paranoid than the casual user - but this is one of the most widely deployed security tools in an enterprise, this shouldn't be "okay". Some defensive efforts are just common sense and are recommended by your compiler (eg. don't use sprintf and strcpy when you can snprintf and strncpy). Also, it doesn't hurt to check error conditions consistently.
PS. To echo what a lot of folks have already said, how on earth can the author implement cryptographic algorithms and simultaneously think there is any value in publishing a hash of the binary "for security". Using a hash as a means of integrity validation in the context of security raises huge red flags about the authors mindset.
I've stopped using PuTTY and now use MinTTY with the Ubuntu subsystem and the regular old Ubuntu SSH client. Specifically this thing: https://github.com/mintty/wsltty
It's real nice and even supports 24bit colour if you're into that.
I tried that briefly too, and I couldn't launch screen. It seems to trigger some old bug in screen. How far is the WSL terminal from the usual fanfare (screen, tmux, proper colors in the terminal and text editors, and other edge cases for scrollback etc.) ?
Loved putty for years, but these days I've been using mosh over ssh. Having persistent sessions and text prediction means no more dropped connections, no more waiting a couple seconds if the wifi is buggy for whatever reason. Personally I use chrome's mosh extension: https://chrome.google.com/webstore/detail/mosh/ooiklbnjmhbcg...
Works great and I can pin it to my taskbar.
Yes, and unfortunately you have to use the version in there (you can't upgrade nor use another client). Otherwise I love mobaxterm and bought a few licenses.
I wish they would finally implement file transfers via copy/paste mechanism inside an active terminal window. As far as I know this feature would be unique across platforms.
If someone does know of an SSH terminal client that does this, please reply.
Reminds me of the bad old days of kermit and x/y/zmodem. http://www.extraputty.com/features/xmodem.html looks like a throwback to those days, over an ssh session. I wonder what you have to run on the server side for it to work?
Does uuencode or base64 work for you? I use it a lot to move stuff (aka my toolkit) to systems where I'm connected via citrix -> rdp -> ssh -> ssh. Amazingly, it works fine, though it can be slow.
$uuencode sheet1.xml sheet1.xml | pbcopy
(switch to remote session)
$uudecode (paste, which varies depending on how I'm connected)
$ls -l sheet1.xml
There is another throwback for me here when one of our clients had disabled Citrix file transfers and only allowed text based clipboard (due to imposed security policies).
So we had to:
- zip a directory hierarchy or a single file uuencode
- copy to shared clipboard
- paste into a terminal on the other end using a here document
- uudecode the output
- checksum the source/destination copy for file integrity purposes
This worked on Windows too (using Notepad and saving the file as .uu for use with WinZip). Luckily file transfers were not a frequent use case.
Years ago, when I worked on Windows, putty was a great soft. Since that time I switched to MacOS/Linux with Fish shell at work and running just a simple ssh command from terminal is a bliss. I still have Windows machine at home and I am missing terminal every time I must click though to login to my remote machine. Putty is no fun anymore... User interface has not been improved for years and, sadly, it's not working for me anymore.
Putty is actually quite slow, due to not implementing AES with the Intel intrinsics. Trying to transfer files using pscp, or WinSCP (which uses putty) over a local network link runs into a CPU bottleneck.
I'd like the putty download to be over https and the installer to be signed.
Or, at least, sha512 hashes available on the https download site.
As it is, the download source for putty is one of the weakest chains in internet security!
When is PuTTY going to support URL highlighting? Even plain old xterm can do it. Someone made a patch for it once but I'd rather have the support built in.
The default colour scheme on Putty is not very good in my opinion. know I can change it manually but it would be nice if the default for new connections was better.
