[6847] in bugtraq
ALERT: Tiresome security hole in "xosview", RedHat5.1?
daemon@ATHENA.MIT.EDU (Chris Evans)
Thu May 28 15:34:44 1998
Date: Thu, 28 May 1998 04:49:17 +0100
Reply-To: Chris Evans <chris@FERRET.LMH.OX.AC.UK>
From: Chris Evans <chris@FERRET.LMH.OX.AC.UK>
X-To: bugs@redhat.com, security@redhat.com, linux-security@redhat.com,
Alan Cox <alan@lxorguk.ukuu.org.uk>, ewt@redhat.com
To: BUGTRAQ@NETSPACE.ORG
Hi,
I am bemused.
After some security auditing on RH5.0, I was curious as to what new suid
binaries and daemons shipped with RH5.1. The first one I noticed was
"xosview". God knows why it needs to be SUID; it probably doesn't but the
makefile just makes the binary suid by default. Linux has /proc which has
enough information that ferreting around in /dev/kmem using root privs
isn't required.
Or perhaps it needs to be suid root for the network load? By the way this
didn't work regardless.
Anyway. I ran the following highly complicated and time-consuming command
on the xosview sources:
grep strcpy *.cc
Tricky one eh? Perhaps vaguely sensible when shipping a new SUID binary,
i.e. REDHAT THINK!!!!!!
Results of grep include, in Xrm.cc
char userrfilename[1024];
strcpy(userrfilename, getenv("HOME"));
Ohhh that's nice. Hey but wait that can't be dangerous. The author clearly
knew what he/she was doing:
char className[256];
strncpy(className, name, 255); // Avoid evil people out there...
Appears later. I found this amusing.
Anyway I hope it's apparent this is exploitable. xosview doesn't appear to
drop privs.
Also, that is _by no means the only vulnerable section of code_, just the
stupidest bit.
Temp. (and probably permanent) solution: "chmod u-s `which xosview`.
Anyway well done RedHat for "blunder of the week".
Still fuming,
Chris
PS. Whilst you're at it RedHat, fix the X libraries (new security holes
just found) as well as dhcpd (remote root, well documented), glibc env
vars (linux-security documented), and upgrade samba to 1.9.18p7 in an
update rpm.
