Date: Fri, 13 Oct 2000 03:42:47 +0200 From: Michal Zalewski <lcamtuf@TPI.PL> Subject: another Xlib buffer overflow To: BUGTRAQ@SECURITYFOCUS.COM < 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 [lcamtuf@tpi.pl] [tp.internet/security] [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};: =-----=> God is real, unless declared integer. <=-----=