PuTTY vulnerability vuln-indirect-dll-hijack-2

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Further potential malicious code execution via indirect DLL hijacking
class: vulnerability: This is a security vulnerability.
difficulty: fun: Just needs tuits, and not many of them.
priority: high: This should be fixed in the next release.
fixed-in: f77ee39e8cae2eaaea3a8fdd1eaffaf484cada08 (0.69)

On some versions of Windows, all versions of the PuTTY tools up to and including 0.68 can end up loading DLLs from the local directory which contains the PuTTY executables.

We believed we had fixed this class of problem in 0.68 itself; see vuln-indirect-dll-hijack. However, it turned out we hadn't caught all cases of it.

The special DLL names to which PuTTY 0.68 was still vulnerable (that we know of) are:

The first three of those are unconditional vulnerabilities as far as we know: vulnerable versions of PuTTY will load them at startup time no matter what it's doing. The last one, SSPICLI.DLL, only seems to be loaded as a side effect of initialising GSSAPI, so if you don't use GSSAPI then PuTTY might not be vulnerable to that one.

All of the remaining Windows API DLLs that PuTTY loads at startup time are included, at least on Windows 10, in the Windows registry location for 'known DLLs', at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs. (See SANS's writeup which explains this.) After PuTTY starts up, it locks down its DLL search path as the very first thing it does, so that further DLLs it loads at run time should not be vulnerable.

We hope that the fact that the only DLLs we load before locking down the search path are on the known-DLLs list means that none of them is vulnerable to further attacks along these lines. But, unfortunately, we can't be sure; the fact that Microsoft's own advice on DLL security doesn't even mention the known DLLs list, and certainly doesn't mention that pieces of the Win32 API itself can put you at risk if they are in DLLs not on that list (e.g. simply using the Win32 printing API turned out to be what caused WINSPOOL.DRV to be loaded) suggests that even MS probably do not have a full picture of what the risks in this area are, so we can't guarantee that further problems might not turn up later.

As described in the previous bug entry, 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 'Zaeek' and Christopher Odenbach for reporting these additional vulnerabilities to us.


If you want to comment on this web site, see the Feedback page.
Audit trail for this vulnerability.
(last revision of this bug record was at 2017-04-28 17:49:37 +0100)