+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery 13-May-2004 | | Published by Onsight, Inc. Edition | | | | http://www.hackinglinuxexposed.com/articles/20040513.html | +------------------------------------------------------------------+ This issue sponsored by ... you. Intrested in sponsoring the Linux Security: Tips, Tricks, and Hackery newsletter? Just drop us a line. Special low low rates ($0) are available for worthy Open Source projects and companies that stand up to the DMCA, IP abuses, and fight for our online freedoms. -------------------------------------------------------------------- The ease of (ab)using X11, Part 1 By Brian Hatch Summary: X11 is the protocol that underlies your graphical desktop environment, and you need to be aware of it's security model. ------ A friend of mine decided to finally get a computer recently. He's one of those people who is very bright, he just didn't have the need for one before.[1] Being a very intelligent and worldly guy, he naturally wanted a Linux box. After a few months of hardware problems[2] we installed Knoppix to the hard drive. Knoppix is a bootable CD distribution based on Debian and has the best hardware auto configuration out there. Plus, it's based on Debian, a huge plus in my book. After getting everything set up for him, configuring Mozilla, twiddling his desktop, etc, he took it home. Naturally, being a new user, some mistakes were made, and the technical support desk (read: me) was called in. So here's the first problem: they turn their computer off at night, making it much harder for me to troubleshoot it at 3am. I wanted a quick way to leave them a note to tell them I'm planning on working on it that evening. Since email was the thing that was broken, I didn't want to send email, and I didn't want to wake up their kid by calling. Seemed the easiest thing to do would be to just plop a message up on their screen. Here's where we get into the X11 security model.[3] X11 is the engine of whatever graphical user environment you have. For example, Gnome, KDE, IceWM, fluxbox, sawfish, are all window managers that live on top of X11, and help decide what the boarders of windows look like, how they're iconified, and the like. Your applications, like Mozilla, terminals, the Gimp, are all X11 applications - they create windows and get input from user keys and mouse movements by interacting with the underlying X11 library routines. The X11 server has an amazingly simplistic and abusable security model. In modern installations, there are only two things you need to know to be able to connect to the X11 server: DISPLAY The Display number is typically something like :0 or :1, which mean "the first X11 display on the local machine" and "the second X11 display on the local machine" respectively. The display is stored in the environment variable DISPLAY, and any X11 application uses this variable to determine how to contact the X11 server and show it's windows when it starts up. If your X11 server is listening on the network, then people can contact it from outside your computer. The first display :0 lives on port 6000, the second on 6001, etc: $ netstat -natp |grep :600 tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 1029/X11 Here we see that X11 (process 1029) is listening on port 6000. A remote machine can attempt to connect and use this server. Not all X11 servers listen on the network by default any more -- this is a very good thing. The server also will listen on a unix socket, which is equivalent to a TCP port except it's available via a file on the local machine. Processes can connect to it only if they are on this machine, which makes this avenue unavailable from outside machines. If my DISPLAY variable is set to :0, then the underlying X11 calls in my applications will find the appropriate socket on their own. For example on this Knoppix box, it keeps the socket in the /tmp directory: $ ls -l /tmp/.X11-unix/ srwxrwxrwx 1 root root 0 Jan 21 11:51 /tmp/.X11-unix/X0 X11 Magic Cookie Once a client (be it local or remote) is able to connect to an X11 server, any modern X11 server will require that the client application prove it's authorized to connect. When the server is started, it has a list of xauth(1) cookies (random strings) that are authorized -- if the client can provide one of them, then the connection is allowed, else it's dropped. These cookies are stored in your home directory, and can be viewed using the xauth(1) program: $ cd $HOME $ ls -l .Xauthority -rw------- 1 fernando twins 152 Jan 21 11:52 /home/fernando/.Xauthority $ xauth list dingo/unix:10 MIT-MAGIC-COOKIE-1 566e1128ce92a0126587cf30f4e19815 dingo/unix:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132 dingo:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132 So remember, the goal is to put something on his screen, even though I'm sitting across the city connected via SSH. After logging in and becoming root (I'll need that later), let's set my DISPLAY variable. Using ls in /tmp/.X11-unix, or netstat I can easily determine that he's running on screen #0, which is not a surprise at all. # DISPLAY=:0 # export DISPLAY Now I need to get access to his magic cookies. Since I'm root, I can read all files on the filesystem, so I just need to let the underlying X11 calls know where "my" .Xauthority file lives: # xauth list xauth: creating new authority file /root/.Xauthority # XAUTHORITY=/home/fernando/.Xauthority # export XAUTHORITY # xauth list dingo/unix:10 MIT-MAGIC-COOKIE-1 566e1128ce92a0126587cf30f4e19815 dingo/unix:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132 dingo:0 MIT-MAGIC-COOKIE-1 d506c80eb23511a2c28ce9242810c132 Bingo! Now xauth, and by extension all X11 applications, will use that .Xauthority file. I should now have access to his X11 server. Indeed, if I run xclock from the command line, it just sits there, rather than complaining about being unable to connect to the screen and exiting, so I assume it's working. So, I whip up a quick shell script to let me show a file to him on an xterm so I can leave him notes on the screen. I'm sure there's a good program for this sort of thing already, so if anyone knows what it is let me know. Here's my terribly boring shell script. # cat shownote #!/bin/sh if [ "$#" -gt "2" ] ; then echo "Usage: $0 filename" >&2 exit 1 fi if [ -z "$2" ] ; then nohup xterm -e $0 $1 blah >/dev/null 2>&1 & exit; fi if [ -z "$1" ] ; then echo "Usage: $0 filename" >&2 exit 1 fi cat $1 sleep +1d # shownote /tmp/dont_turn_machine_off.txt & It takes a filename, and then opens an xterm that shows that file in it via cat. Simplistic but easy. The key here is that I should not be allowed to show things on his X11 server -- if I can, I can do other nastier things. Next time, we'll see some of the more interesting things that are possible. If you have favourites in your arsenal, let me know and I'll try to include them! NOTES: [1] To some of us, having a computer is a need, just like breathing. Sometimes breathing is run at a higher nice(1)ness level, for that matter. [2] Damned be to Microtel! [3] You didn't think I was going to just ramble on the whole time, did you? ------------- Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He looks back on his college days of playing xtank at 3am and wonders "Did anyone steal my passwords when we all ran 'xhost +' " ? Brian can be reached at brian@private -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-request@private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2004, Brian Hatch. _________________________________________ ISN mailing list Sponsored by: OSVDB.org
This archive was generated by hypermail 2b30 : Fri May 14 2004 - 02:12:36 PDT