PuTTY vulnerability vuln-win-exclusiveaddruse

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 | Changes | Wishlist

summary: Vulnerability: Windows local forwarded ports rebindable by another application
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.
present-in: 0.52 0.53 0.53b 0.54 0.55 0.56 0.57 0.58 0.59 0.60 0.61 0.62 0.63 0.64 0.65 0.66 0.67 0.68 0.69 0.70 0.71 0.72
fixed-in: 0.73 15653f67e8559787d021dda415d93696e98d1804

In all versions of PuTTY between 0.52 (when port forwarding was introduced) and 0.72 inclusive, when PuTTY listens on a local TCP/IP port for port-forwarding purposes, it does not set the SO_EXCLUSIVEADDRUSE flag which tells Windows to prevent another application from binding a listening socket to the same port.

As a result, a malicious process running on the same machine would be able to bind to the same port, and intercept some of the incoming connections for its own purposes. Those purposes might include performing a MITM attack on the connection, forwarding the modified data back to the same port.

(To confuse matters further, PuTTY was setting the SO_REUSEADDR socket option, meaning that it behaved somewhat like such a malicious process itself – it could take over a listening port from another process. This article describes the behaviour of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE on Windows. The probable reason for PuTTY setting SO_REUSEADDR was that we knew that it's necessary with Unix-derived IP stacks, to avoid trouble re-binding ports involved in TIME_WAIT connections, and assumed it was necessary everywhere; but on Windows, it's not needed for that, and turns out to be actively harmful. So PuTTY no longer sets SO_REUSEADDR on Windows. This didn't itself cause a vulnerability.)

This bug was first reported by Patrick Stekovic. It has been assigned CVE-2019-17067.


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 2020-01-11 15:06:43 +0000)