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.
Ssh's main function is, as you mention, to connect to a shell. That it also can be configured to served to secure other protocols is secondary; and when you use it in that function it's your problem to secure it. With this in mind, it's obvious why port forwarding is enabled by default: all you have to do is
to emulate -L.
Haha, so it’s not just Theo who IRCs from cvs.openbsd.org… Great one.
I notice that X11Forwarding – much more useful – is off by default as well.
Might disable port forwarding in MirBSD, but I’ll run it through our mailing list just to be sure noone complains too loudly.
Note that the recent default/suggested AnonCVS setup DOES in fact disable port forwarding for that user.
Yes, that's the lame excuse the man page gives for supporting forwarding by default.
However, I can conveniently view any file on a host by running "ssh host cat $FILE". By your reasoning, it would be acceptable for ssh to get an option that cats a file on the host at connect time, and enable it by default. Anyone using ssh for "another protocol" (or just with a restricted shell) would then have to remember to disable that "feature".
How exactly is that "insecure"? It just allows somebody with shell access to be able to bounce from there to elsewhere in the network... But if they have shell access, they're already capable of getting in the network. Why make it a step more difficult to run some program on the shell to do the same thing?
It defaults to "yes" because it's incredibly convenient, and because it is not an actual threat to "security", since it doesn't allow anything that can't be allowed through some other means.
Your analogy to the 'cat' command makes no sense. It's not something that is often done. If it was, then yeah, it should be built in for performance reasons.
Not all ssh access is shell access.
Not all shell access allows running arbitrary commands like nc or even cat.