Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

Does it strike anyone else as bizarre / poor form for an experimental feature to be enabled by default in OpenSSH, which is normally very conservative with option defaults?

View on HN

What's more, it was not documented in the ssh_config(5) man page. If it had been, I probably would have disabled it long ago when hardening my SSH config.

Time to head to the source to look for other undocumented options...

Update: my findings are here (scroll to bottom for the upshot): https://gist.github.com/AGWA/e92d4f5343be1f7a941d

UseRoaming is the only one to be concerned about. There are many other undocumented options, but they're all aliases for a documented option or are deprecated/unsupported.

https://github.com/openssh/openssh-portable/blob/e6c85f8889c... Here you go

Actually, I quickly generated a list of undocumented config options: http://sprunge.us/QDSE

Edit: Fixed version http://sprunge.us/LVYB

most of those seem to be documented: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/...

I did a quick comparison between the OpCodes enum and the latest man page, and `UseRoaming` is the only real undocumented option.

Weird, my manpages didn't get updated despite man claiming they did. Fixing that now.

Edit: fixed, http://sprunge.us/LVYB

I believe "kerberosauthentication" and "rhostsauthentication" are documented as well. I'd check the "official" OpenBSD man page instead of whatever you have on your system. Regardless, thanks.

In the latest OpenSSH-portable source, those are considered "unsupported" and "deprecated," respectively (which means they're ignored, essentially). See https://gist.github.com/AGWA/e92d4f5343be1f7a941d#file-undoc... as well as the source https://github.com/openssh/openssh-portable/blob/e6c85f8889c...

Neither of those are mentioned on the latest manpage from git.

Please report back what you find!

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.

Given 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/...

Related: "Protecting sshd using spiped" by cperciva

http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...

SCP/SFTP is actually a separate binary.

PuTTY is definitely not affected since it has its own SSH implementation.

PuTTY is completely different code.

Pretty sure this is OpenSSH only. PuTTY and SecureCRT, at least, are reported not to be affected.

We use WinSCP also, a file copying utility; it would be useful to know whether that's affected if anybody has that info.

Last time I looked WinSCP used PuTTY components or a fork. Would appreciate additional verification of this, though.

Server-side you can see the "full config" sshd uses:

  $ /usr/sbin/sshd -T -f /etc/ssh/sshd_config

Modify, if necessary, to point to the location of your `sshd` and configuration file.

I came here to ask exactly this, and also why this feature isn't documented. Sounds like a nice little exploit.

Reply on news.ycombinator.com