OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: another Xlib buffer overflow
From: Michal Zalewski (lcamtufTPI.PL)
Date: Thu Oct 12 2000 - 20:42:47 CDT

< I'm still looking for a good job: http://lcamtuf.hack.pl/job.html >

[ Aleph, I have strange deja-vu I have seen similar hole reported to ]
[ BUGTRAQ some time ago - but I've searched the archives and mailbox ]
[ for anything related, and could not find it... so if I am blind, ]
[ please bounce this message... :) ]

Vulnerable object: XFree 3.3.x Xlib (no data on 4.0.x); no mention of fix
in "security issues" page at www.xfree86.org.

The problem is simple - you can invoke any executable linked against Xlib
with -display command-line parameter or DISPLAY environment variable in
the way which causes trivial stack overflow. This could happen, as before
establishing unix socket connection, socket path containing user-supplied
data is sprintf()ed to small buffer.

You can overwrite both local variables and return address with limited set
of characters (well, limited to digits ;), but I strongly believe it could
be exploited with no difficulties by affecting only less significant bytes
- partial address overwriting, partial variable overwriting - known
techniques. Examining the stack and code shows us at least little endian
machines are very likely to be vulnerable to successful exploitation.

So, the impact is:

DISPLAY=:`perl -e '{print "0"x128}'` any_privledged_X_application
(or: any_privledged_X_application -display :...)

Common X client applications are *term, games and several other programs
that are setuid and linked against Xlib, whenever willing to access X
server display.

_______________________________________________________
Michal Zalewski [lcamtuftpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=