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:

        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.

ssh is not ssl, even though it conveniently acts as it

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

ssh user@host nc $HOST $POST

to emulate -L.

Comment by ni-x-ar [blogspot.com]

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.

Comment by mirabilos [launchpad.net]
is X11forwarding more useful?
Is X11Forwarding more useful than generic TCP forwarding? You could, in principle, implement X11 forwarding on top of a forwarded TCP port, I think it would be harder to implement generic TCP forwarding on top of X11 or other application specific protocol forwarding.
Comment by jmtd [livejournal.com]
Re: ssh is not ssl, even though it conveniently acts as it

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

Comment by joey [kitenet.net]
comment 6

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.

Comment by blog [ottodestruct.com]
comment 7

Not all ssh access is shell access.

Not all shell access allows running arbitrary commands like nc or even cat.

Comment by joey [kitenet.net]