OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1998: ALERT: Tiresome security hole in "xosview", RedHat5.1?

ALERT: Tiresome security hole in "xosview", RedHat5.1?

Chris Evans (chrisFERRET.LMH.OX.AC.UK)
Thu, 28 May 1998 04:49:17 +0100 

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.