Bug 22572 - Xlib: display handling buffer overflow (XFree86 3.3.x)
Summary: Xlib: display handling buffer overflow (XFree86 3.3.x)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.2
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-20 08:23 UTC by Pekka Savola
Modified: 2007-03-27 03:38 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-04-24 16:28:19 UTC
Embargoed:


Attachments (Terms of Use)

Description Pekka Savola 2000-12-20 08:23:06 UTC
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 > 
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 22:32:58 UTC
I am hunting down a fix for this..

Comment 2 Jarno Huuskonen 2001-01-29 07:11:57 UTC
I think the XServers that come with RH 7.0 have some patches for this.
Also check:
http://www.openbsd.org/errata27.html#xtrans

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 22:00:37 UTC
Debian has released a huge amount of updates for XFree86 3.3.6:

http://lwn.net/daily/deb-xfree86.php3

No use duplicating work.


Comment 4 Mike A. Harris 2001-03-31 13:30:45 UTC
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 09:31:10 UTC
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.