Bug 22572 - Xlib: display handling buffer overflow (XFree86 3.3.x)
Xlib: display handling buffer overflow (XFree86 3.3.x)
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: Security
Depends On:
  Show dependency treegraph
Reported: 2000-12-20 03:23 EST by Pekka Savola
Modified: 2007-03-26 23:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-24 12:28:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pekka Savola 2000-12-20 03:23:06 EST
I thought this had been added here (and it came up again on bugtraq), and 
couldn't find it so..

This only affects XFree86 3.x, 4.x is fine.

Thankfully, only setgid/setuid Xapp I could find in the base distro was Xwrapper.

Date: Fri Oct 13 2000 03:42:47 
Author: Michal Zalewski < lcamtuf@tpi.pl > 
Message-ID: <Pine.LNX.4.10.10010130218180.942-100000@localhost> 

< 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.
Comment 1 Mike A. Harris 2001-01-28 17:32:58 EST
I am hunting down a fix for this..
Comment 2 Jarno Huuskonen 2001-01-29 02:11:57 EST
I think the XServers that come with RH 7.0 have some patches for this.
Also check:

Also XFree86 3.3.6 has various DoS bugs. I hope you're going fix those as well.
Comment 3 Pekka Savola 2001-02-12 17:00:37 EST
Debian has released a huge amount of updates for XFree86 3.3.6:


No use duplicating work.
Comment 4 Mike A. Harris 2001-03-31 08:30:45 EST
Thanks, I'm going to be focusing on 3.3.6 errata's very soon.  I will indeed
check out all the info you've provided.  Thanks.
Comment 5 Mike A. Harris 2001-05-15 05:31:10 EDT
Fixed in pending errata release.  Should be out shortly.

Note You need to log in before you can comment on or make changes to this bug.