Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 6 Mar 2008 22:05:14 +0100
From: "Bernhard R. Link" <>
Subject: Attack vector exploiting rxvt defaulting to :0

This text is aimed to describe a possible attack vektor to show
how an malicious user can gain privileges by this.

- This is all limited to an user issuing rxvt directly or indirectly
  on some host without the DISPLAY environment variable set.
  While one could claim that people should not do this, it can easily
   - issuing the command in the wrong shell happens easily[1],
   - forgetting to give ssh an -X
   - sshd being reinstalled or config changed to now disabling
     X forwarding in the server. (In this setting the only fault of the
     user is not to have checked $DISPLAY if nothing changed).

  While there is a fault of the user, running an rxvt in error should
  not cause giving other people access to your account, especially not
  in a stealth way.

- The not-very-dangerous attack-vector:

  Assume above user logs in to another machine, on which an X server :0
  is running and mistakenly runs rxvt. The user sitting before the
  machine gets an rxvt and can do arbitrary things.
  While this is bad, it is usually not that dangerous, as the user will
  notice not getting any window and typing Ctrl-C before the local user
  noticed his opportunities to do anything and the terminal vanishes.
  It might be dangerous if someone realizes a change in sshd allowing
  forwarded X sessions and being able to log in locally and many people
  log in remotely, so the attacker can wait for some and issue an
  prepared command. Or the user must issue rxvt & and then forget it.
  Quite unlikely.

- The more dangerous attack.

  Now imagine an shell-server used by many people. With enough people
  and some graphical stuff installed, it is not that unlikely there
  might be at least one person issuing a rxvt in mistake once a week
  or even once a day.

  Shell server usually have no local X server running, so local :0
  i.e. the unix domain socket /tmp/.X11-unix/X0 is not yet bound by
  anyone else. That means anyone having an account[2] or even only
  anyone being able to get enough code executed locally - be it as
  user nobody, daemon or www-data - can bind on that socket and
  accept connections.

  When receiving a connection, this code simply has to speak the X
  protocol, closing everything that does not look like an rxvt early
  enough that people have to actually read the error message closely and
  understand the specifics of the X protocoll to suspect something.
  If an rxvt connects, this 'fake' X server just sends some keyboard
  presses (it is a X server, so those keys are genuine to the terminal
  emulator, not ditinguishable from real ones, except perhaps a bit
  fast) issuing a command to have code running as the unsuspecting
  user running rxvt without checking DISPLAY.

  Being tricky enough the attacker can then even output the normal
  errormessage rxvt would give about not being able to reach an X server
  and terminate the X term, so the user sees nothing but that he run
  rxvt on the wrong host and not suspecting someone else is now running
  code under his uid and thus controling his account.

	Bernhard R. Link

[1] Who has never shutdown'ed the wrong computer?
[2] You would only need root to run a classic X server, accessing
    the hardward like a graphic card or a keyboard. Which are
    especially not needed here.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.