5 ms·
It just sounds like a big code-base fuckup. They more or less admit it: "Server side was disabled/gutted for years already, but this aspect was surprisingly fo
by drzaiusapelord 11y ago
It just sounds like a big code-base fuckup. They more or less admit it: "Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten."
Sounds like this was put in at one time, forgotten about, and the code lingered for a long time until someone pointed it out. SSH as a protocol is pretty crazy. Everyone loves it, but its a lot of things in one, which ironically goes against the unix philosophy. Its a remote terminal, a file transfer server, a network tunnel server, a socks server, etc. There's a lot of stuff in there and I imagine difficult to work with sometimes.
No word if this is enabled in Putty, but I imagine it is if its using openssh libraries.
- jlgaddis 11y agoPretty sure this is OpenSSH only. PuTTY and SecureCRT, at least, are reported not to be affected.
- alanpost 11y agoGiven that this exploit happens during capability negotiation (or whatever SSH calls that part of the protocol), it also cannot be mitigated via pledge[2], which is where OpenBSD has been focusing a lot of attention. This is an unusual stumble for the OpenBSD team. Client-side privsep support, if such a thing existed, might mitigate attacks like this. As it stands protecting against exploits of this type wasn't even on the hardening roadmap. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/...
- mkj 11y agoPuTTY is completely different code.
- _yy 11y agoSCP/SFTP is actually a separate binary. PuTTY is definitely not affected since it has its own SSH implementation.
- icebraining 11y agoRelated: "Protecting sshd using spiped" by cperciva http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-spiped.html http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...