1. 11
  1.  

  2. 6

    While not an urgent upgrade for most due to X11Forwarding being disabled by default, apparently RedHat distributions change it to be enabled by default.

    1. 1

      Ubuntu apparently enables it by default. I had it set on a Debian server running Wheezy and unset on one running Jessie, so that may be version-based; it’s worth checking.

      1. 1

        Debian enabled it by default in 2005 on the server side, but has it disabled by default on the client side, with the rationale that X11 forwarding is primarily a risk to the client. Changelog message:

        Set X11Forwarding to yes in the default sshd_config (new installs only). At least when X11UseLocalhost is turned on, which is the default, the security risks of using X11 forwarding are risks to the client, not to the server (closes: #320104).

    2. 3

      Would someone mind explaining how this could be exploited? I’ve read the description twice now and I can’t quite figure it out.

      From my understanding, the issue is that if a server allows X11 forwarding, a user can authenticate and provide a crafted credential to inject commands into xauth, which is running under that user’s priviledges. So how is that different from just logging on to the box and running commands via the shell? Does this only apply to servers configured to run certain X11 programs on behalf of the user, but restrict them from using an actual shell?

      Thanks in advance!

      1. 6

        Does this only apply to servers configured to run certain X11 programs on behalf of the user, but restrict them from using an actual shell?

        Pretty much, like fetching a CVS or git repo over SSH, where the server is not supposed to give you an open shell but run a specific command, though it does not need to be an X11 command (just have X11Forwarding enabled in the server).

        1. 1

          Ah, ok. Thanks for clarifying!