OpenBSD Journal

OpenSSH / AnonCVS port bouncing advisory

Contributed by grey on from the still secure by default, but check your configurations dept.

Thanks to Dragos Ruiu who puts on the excellent CanSecWest and PacSec security conferences (that I make a point of attending) for bringing our attention to the following:

Though this doesn't affect OpenBSD users by default, for those using OpenSSH with the "AllowTcpForwarding" option enabled, and who are using AnonCVS you should read this advisory.

If you check /etc/ssh/sshd_config you'll see that the line reading: #AllowTcpForwarding yes while defaulted to yes is actually commented out, however, I have been corrected by mjc & Brad Smith that this only reflects that the default is that this option is enabled, this is clarified in the sshd_config file:

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.
However, a CVS server isn't running by default with OpenBSD, but this warning is still worth reading for those who may be using these tools in such an environment. You'll note from reading the advisory that OpenBSD's CVS servers have been reconfigured so as to avoid this issue since being notified.

(Comments are closed)

  1. By Mooch ( on

    HUH! It is my poor english or it does not clarify if the problem is when you have a server with public accounts (or just uncontroled accounts) or just a publicly available OpenSSH service (non-iptables/pf protected)?

    1. By sthen ( on

      Just public/uncontrolled accounts.

      Normally, when you connect by SSH, it's with a password to a shell. So, 1. only people with a password could connect, and 2. they would be able to make a connection from their shell anyway. So in this case, being able to port-forward makes little or no difference.

      The thing that some people might not have realised is that even a public login is allowed to port-forward.

      Some people use public logins for anonymous CVS servers - others might have anonymous sftp or rsync-over-ssh, or even something simple like setting up an account which doesn't login to a shell but instead shows traffic statistics or a mail queue or a menu system.

      All of these cases would allow port forwarding (usually only for the duration of the program run: possibly very long for CVS, or quite short if it's just displaying a few lines of statistics).

      I'd like to think that this won't affect too many OpenBSD admins, but anyone allowing ssh connections to their machines that didn't know about port forwarding might want to look into their setup. The article gives an example of anonymous spamming; obviously another possible problem is that it might allow somebody to bypass access-restrictions or firewalls.

  2. By Christian Jones ( on

    I've done quite a little googling, but have been unable to find a good explanation of "port bouncing". Is it as obvious as I think, connecting to a machine (say, through one of a small number of ports allowed through a firewall), and then tunnelling through that connection any other traffic you want? How does this differ from what's intended by AllowTcpForwarding---are they just flip sides of the same coin?

    Sorry for the naivete, just curious....

    1. By Brad ( brad at comstyle dot com on

      You sound really confused, "port bouncing" is what is provided by the AllowTcpForwarding option. The whole point is that if you had a public account like say an anoncvs account or something similar and the option was enabled then someone could use that to say connect to an IRC server via your AnonCVS server, send SPAM or anything you could possibly imagine that could be done via this feature.

      1. By Christian Jones ( on

        Yeah, I can tell from the article that's what the risk is, and from man sshd_config a tiny amount of what it allows; what I'm wondering is *how*. Is this any different than ssh tunnelling? Could you enlighten me about where I sound confused?


        1. By JB ( jan[AT] on

          Simply put, it is basic ssh port forwarding. The trick is that you've bypassed the the first layer (the assumed firewall) protecting the host, without even trying and with the victims help.

          An example: you forward your local port 8080 to an anoncvs server inside the DMZ of $COMPANY or $PROVIDER. since it's anonymous, there's no password prompt - and no password - and if you're using the -N (no remote command executed), you suddenly have an encrypted connection behind the DMZ - without anything timing out your connection. Combine this with another handy tool, and you can scan and look at the machines behind the given firewall. Nothing's blocking you, right?

          Clear now?

          1. By Christian Jones ( on

            Crystal. Thanks, JB.


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]