Subject: security/9528: xterm vulnerable to root exploit
To: None <gnats-bugs@gnats.netbsd.org>
From: Bill Squier <groo@old-ones.com>
List: netbsd-bugs
Date: 03/03/2000 18:03:36
>Number: 9528
>Category: security
>Synopsis: xterm vulnerable to root exploit
>Confidential: yes
>Severity: critical
>Priority: high
>Responsible: security-officer (NetBSD Security Officer)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Mar 3 18:03:00 2000
>Last-Modified:
>Originator: Bill Squier
>Organization:
Bill Squier (groo@cs.stevens-tech.edu)
http://www.cs.stevens-tech.edu/~groo
>Release: <NetBSD-current source date>
>Environment:
System: NetBSD nyarlathotep 1.4 NetBSD 1.4 (NYARLATHOTEP) #10: Wed Dec 15 20:43:55 EST 1999 groo@nyarlathotep:/sysn/arch/i386/compile/NYARLATHOTEP i386
>Description:
Forwarded message, from BUGTRAQ:
---------- Forwarded message ----------
Date: Tue, 29 Feb 2000 17:39:25 +0100
From: Morten Welinder <terra@DIKU.DK>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: xterm log file vulnerability
It used to be Well Known that xterm's way of opening a log file
was insecure. Well, that was 5+ years ago so I decided to take
a look at the current state of affairs. Things have changed,
but mostly to "different" rather than "better".
Problem: when log files are enabled, they are created in the
following way (checking in XFree86 3.3.6 source; matches Solaris
binaries) and are subject to race conditions:
1. File is checked for existance using access.
2. If file does not exist, it is created in a subprocess using user's
real uid/gid. [ok]
3. File is checked for existance using access.
4. File is checked for write permission using access.
5. File is opened O_WRONLY | O_APPEND. [plonk]
A little symlink magic between 4 and 5 and you have write access to
any file if your xterm is setuid/setgid.
General attack idea:
ls -lL `which xterm`
# If not setuid/setgid, you are safe
touch dummy
symlink-flipflop link dummy /.rhosts
xterm -l -lf link -e echo + +
Moral: access() is totally useless for security purposes. Use it
only as a means of providing better error messages (as it might not
be easy to get an error message out from a subprocess).
Morten
----- End forwarded message -----
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted: