PuTTY semi-bug winnet-if2lo

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 · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

summary: PuTTY refuses connections to 127.0.0.1 from interface IP addresses
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: tricky: Needs many tuits.
priority: high: This should be fixed in the next release.
fixed-in: 2003-10-13 4d76ca6658d4d557f1525e791cdb8910b5af4177 (0.54)

There are persistent reports of PuTTY's port forwarding not working with SMB connections, although there are just as many reports of it working fine. Thanks to Chip Killian's report of this bug and some detective work with netstat, I think I've tracked down the cause of this problem.

When PuTTY's network layer is asked to open a listening socket for connections from localhost only, it actively refuses any connections that don't come from a loopback source address. This was because I was told that at least some Windows systems implement "the weak end system model", in which any packet coming in to the system with a destination address the machine believes it has will be accepted. In other words, if I construct a packet with my own source address (say 10.1.2.3) and destination 127.0.0.1, and if I convince my IP layer to send it to your machine's Ethernet MAC address, then your machine might actually accept the connection, send back responses to my MAC address with 127.0.0.1 as the source address, and then I've managed to make a connection to one of your machine's internal services from outside. PuTTY's deliberate check that loopback connections come from an actual loopback address largely defeats this attack: if I put 127.0.0.1 as the source address of your packets, I might still get your machine to believe the first SYN, but all its replies will be sent internally and won't come back to me.

Unfortunately, at least some versions of Windows connect to a SMB share on 127.0.0.1 in such a way that the source of the connection appears to be one of the machine's other IP addresses - and hence PuTTY will reject the connection and refuse to forward it.

To fix this, I suppose PuTTY will need to find out what IP addresses the machine believes it owns, so that it can accept connections from any of those. If anyone wants to save me some manual-grubbing by letting me know how to do that conveniently, it would be helpful.

Update: we have implemented a fix as of the 2003-10-13 snapshot. It would be helpful if someone could tell us whether it makes SMB forwarding work.


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2016-12-27 11:40:22 +0000)