Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Changes
|
Wishlist
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:
WINMM.DLL
WINSPOOL.DRV
BCRYPT.DLL
SSPICLI.DLL
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\. (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.