On a system where X11R6-based Xserver (R5 is probably affected too) is
installed setuid or setgid (e.g. typical XFree86 installation has XF86_*
setuid root), local users can exploit a buffer overrun in its code and
gain extra privileges (e.g. root privileges when Xserver is setuid root).
Quick vulnerability check:
X :00000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000009
(add -nolock for XFree86, change X to whatever name your Xserver has)
Vulnerable Xserver will crash (Segmentation fault).
(Note: machines immunized against stack smashing--e.g. Linux boxes with
Solar Designer's kernel patch--are probably not vulnerable.)
Quick fix:
* remove setuid/setgid bit from all installed Xservers
* use xdm or a safe setuid wrapper to start Xserver
Details:
X11R6.x Xserver recognizes a runtime argument specifying the desired
display (e.g. X :1). It accepts ANY value regardless of its length
and contents (save from the initial colon).
Excerpt from xc/programs/Xserver/os/access.c (X11R6.3)
/* Reset access control list to initial hosts */
void
ResetHosts (display)
char *display;
{
register HOST *host;
char lhostname[120], ohostname[120];
char *hostname = ohostname;
char fname[100];
[snip]
strcpy (fname, "/etc/X");
strcat (fname, display);
strcat (fname, ".hosts");
if (fd = fopen (fname, "r"))
[snip]
}
Xserver calls ResetHosts() during its startup. A very long value of
"display" (100 + 2*120 + delta bytes) overflows "fname" and corrupts
the stack.
An actual exploit is left as an exercise for the reader. :)
There are probably other vulnerable places in Xserver code. (I have
spotted another buffer overrun in LockServer() (os/utils.c, XFree86
specific) but this one seems to be benign.) Anyone willing to pay me
big bucks for an exhaustive audit is welcome. :)
--Pavel Kankovsky aka Peak (troja.mff.cuni.cz network administration)
[ Boycott Microsoft -- http://www.vcnet.com/bms ]