I don't think I've mentioned this publically before, but I found a security hole in OpenBSD in 1999. Ok, so it wasn't in the security-focused OS, but just in their infrastructure. And it wasn't a very bad hole; it just allowed doing things like IRCing with a openbsd.org address.

The hole was in their CVS over SSH setup. They had forgotten to turn off port forwarding. I have a clear memory of contacting them, probably on irc, and getting back a dismissive response, but assuming they'd fix it.

So I was really suprised when, checking as I write this article, I found the same hole still exists in one of their main CVS servers, as well as more than one of their CVS mirrors. What this says about OpenBSD and security is left to the reader. And if the reader is in China -- hey, this is a great way to get around the Great Firewall ...

But I hadn't planned to poke at OpenBSD here. What I really want to think about is why ssh, which is very security focused, has in one area had an insecure default for over a decade. By default, if you can connect to a ssh server, you can forward ports to and from that server (with the -L and -R options). The sshd_config(5) man page says:

AllowTcpForwarding
        Specifies whether TCP forwarding is permitted.
        The default is “yes”.  Note that disabling TCP
        forwarding does not improve security unless users
        are also denied shell access, as they can always
        install their own forwarders.

Which is a pretty silly justification -- have you ever tried to install a forwarder on some random shell account? Without pissing off the admin? ssh provides a much less obvious way to do it, one the admin will probably never notice.

Anyway, the assumption is that if a user connects via ssh, they get an unrestricted unix shell. But in many ssh setups, from OpenBSD's CVS, to the Pro Git book's ssh setup, to innumerable limited purpose ssh accounts, that's not true. The user lacks a shell, but unless the administrator remembers to turn off port forwarding, they retain the ability to bounce through the ssh server to google, or an intranet, or whatever.

I wonder that percentage of people setting up restricted ssh accounts forget to add "no-port-forwarding" to authorized_keys? It's hard to tell because most such accounts are limited to a few people. You can't scan the whole net for them. Still I've seen enough people get this wrong that I wouldn't be suprised if it affects between 10% and 50% of restricted ssh accounts.

Why did this feature get into ssh in the first place? I'm sure it was inherited into the current OpenSSH from the original, proprietary ssh. Which turns out to have been one of those programs where the "secure" in the name has a certian amount to do with marketing. Note that the more recent PermitTunnel option defaults to off. I doubt that AllowTcpForwarding would be accepted into OpenSSH today with its current default.

Why does ssh still have this increasingly bad default? Well, partly because it has indeed become increasingly bad over the years as ssh use for special purpose things like git push has spread. (OpenBSD were fairly far ahead of the curve using ssh for anonymous CVS in the 90's.) The frog has been heating up for a while. In 2004 there was CVE-2004-1653 about this, and today books are being published documenting insecure configurations for legions of DVCS fans to copy. Boiling yet?

Another reason might be that any ssh admin you ask about this will swear that they always remember to disable it. And a lot of them do, and that makes them feel smart & superior, so why complain about it. And another reason, of course, is that changing the default would break untold amounts of weird stuff.