Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Privacy
|
Changes
|
Wishlist
On some versions of Windows, all versions of the PuTTY tools up to and including 0.69 can end up loading a DLL from the local directory which contains the PuTTY executables.
We believed we had fixed this class of problem in 0.68 (see vuln-indirect-dll-hijack), and when that turned out not to be true, we believed we'd fixed all the remaining instances in 0.69 (vuln-indirect-dll-hijack-2). However, it turned out that even in 0.69 we still hadn't caught all cases of it.
We know of one special DLL name to which PuTTY 0.69 was still vulnerable:
CRYPTBASE.DLL
We believed we had finished fixing these problems in 0.69 because all the remaining DLLs that PuTTY's makefile explicitly told the linker to refer to at load time were on the default 'known DLLs' list, which seems to accord those DLL names special load-time treatment which prevents this kind of hijacking attack. However, the remaining problem involved a system function not explicitly used in PuTTY's code – the reference to it apparently came from an internal module in Visual Studio's standard library. Updating our build environment to use Visual Studio 2015 update 3 instead of the original 2015 RTM build made the rogue function reference go away and appears to have closed this hole.
(The API name of the system function in question is RtlGenRandom(),
but physically, it's imported from ADVAPI32.DLL by the
name SystemFunction036.)
As described in the previous related bug entries, the most likely way in which this vulnerability could be used in an attack is via a web browser's download directory – an attacker contrives to deliver a malicious DLL into your download directory under one of the special names that an application is vulnerable to, and when you later download and run PuTTY, it loads that DLL from alongside itself and is taken over. Whereas if PuTTY is installed on the system via the MSI installer, then there is no issue, because the installer will put the executable files in a dedicated directory, and an attacker with enough file access permissions to drop malicious DLLs into that directory would probably be able to overwrite the executable files themselves in any case.
Thanks to Walter Thyselius for reporting this additional vulnerability to us.