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