Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
In PuTTY 0.78, we changed the Windows installer's install scope, in an attempt to work around a Windows security vulnerability, which has since been addressed by Microsoft.
This change broke a lot of things. We've reverted it.
You can avoid these problems by invoking the 0.78 installer specially from the command-line, something like this:
msiexec.exe /i path\to\putty-64bit-0.78-installer.msi ALLUSERS=1This effectively reverts the change we made, making the 0.78 installer behave just like other versions.
If you installed 0.78 (or any development snapshot or pre-release build from 2022-10-13 to 2023-03-22 inclusive) in the conventional manner, we recommend you fully uninstall it before installing any other version.
Trouble we've heard of includes:
The gory details:
We were contacted by security researchers Doyensec in the run-up to the 0.78 release, who told us that the 'Repair' function on several installer packages, including PuTTY's, could be triggered by unprivileged users (despite the package having been installed systemwide), and could be tricked into deleting an arbitrary file with elevated privileges on some versions of Windows (at the time, this was demonstrated with the latest Windows 10 and Windows 11 public releases).
We pointed out that this combination of behaviours was surely a bug in Windows (probably msiexec.exe). However, we were initially told that while Doyensec were in contact with Microsoft, Microsoft did not consider it a vulnerability.
Given this unsatisfactory situation, after some experimentation, we removed InstallScope="perMachine" from our WiX installer setup script, which had the effect of removing the property which set ALLUSERS to 1 in the MSI database. In our initial testing, this hid the vulnerability (by putting up a UAC prompt for 'Repair'), and despite Microsoft's documentation implying that this would give a per-user installation, it did in our initial testing give a UAC prompt and appear to install systemwide. At first glance, this seemed to have no downsides.
We did notice the duplicate Add/Remove Programs records shortly before release. We nonetheless released 0.78 with the installer change and a caveat in the announcement that you should uninstall previous versions first.
However, the other shortcomings listed above quickly became evident from user reports.
It looks like the modified installer tried to put shortcuts and registry keys somewhere unhelpful, such as the installing user's roaming profile (or discarded them if that user didn't have one), explaining many of the observed symptoms.
At the point the deficiencies of the 0.78 installer became evident, it was still unclear to us whether Microsoft were even considering this a vulnerability, so we were left in limbo; we couldn't give a satisfactory explanation to our users of why we'd inflicted this on them, nor revert it without leaving an undisclosed vulnerability unmitigated. Apologies to everyone who wrote to us about this.
Some users figured out that they could install with ALLUSERS=1 (e.g.), effectively reverting our change. In light of how this turned out, that's now also our recommendation (see above).
Some months later, we heard back (via Doyensec – we were not in direct contact with Microsoft at any point) that Microsoft had deemed this a vulnerability after all, and had released a fix. The Windows vulnerability has been assigned the ID CVE-2023-21800, and Microsoft's page about that is here (although it doesn't say very much at the time of writing).
In particular, that CVE page only declares a fix (released 2023-02-14) for Windows 2008 Server and 2008 Server R2, and not (for instance) Windows 10 or 11 where this was originally reported to us. From discussion with Doyensec and according to their write-up, we infer that the vulnerability on those versions of Windows was addressed at the same time by the much broader mitigation of Microsoft enabling their 'Redirection Guard' feature for msiexec in the 2023-02-14 Windows updates (which plugs the junction/symlink-related hole that was used to trick msiexec into deleting arbitrary files).
This is all rather unsatisfactory, and has left many of our users with long-term damage to their systems. Ideally we wouldn't have even been contacted about it, and MS would have just quietly pushed out a Windows patch, and everything would have been fine and less painful.
Timeline: