(fwd) HP-UX 9.x: /usr/lib/expreserve creates files anywhere (fwd)

[ccshag () cclabs missouri edu (Paul 'Shag' Walmsley)]

This was recently posted on comp.security.unix.


- Paul "Shag" Walmsley <ccshag () cclabs missouri edu>
  "The only difference between myself and a madman is that I am not mad."
       - Salvador Dali

---------- Forwarded message ----------
Path: 
golf!zombie.ncsc.mil!paladin.american.edu!gatech!howland.reston.ans.net!pipex!uunet!zib-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!news.informatik.uni-muenchen.de!malaka!lopatic
From: lopatic () malaka dbs informatik uni-muenchen de (Thomas Lopatic)
Newsgroups: comp.security.unix
Subject: HP-UX 9.x: /usr/lib/expreserve creates files anywhere
Date: 19 Dec 94 13:17:22 GMT
Organization: Institut fuer Informatik der Universitaet Muenchen
Lines: 40
Message-ID: <lopatic.787843042@malaka>
NNTP-Posting-Host: malaka.dbs.informatik.uni-muenchen.de
X-Newsreader: NN version 6.5.0 (NOV)

Hello everyone,

I've found this bug to exist on HP-UX 9.01 and 9.05. By creating a symlink
in /usr/preserve which points to a non-existing file, /usr/lib/expreserve
can be tricked into creating a file anywhere on a local file system. The
file will be owned by the invoking user.

As far as I can judge, this is because expreserve uses stat() to check,
whether the file already exists. Since stat() follows links, a stat on a
symlink pointing to a non-existing file will fail. Thus, expreserve happily
creates the file the symlink points to. Existing files cannot be written
over with this method.

But there's another thing. The expreserve program uses chown() after the
file has been creat()ed. This opens a small window for a race-condition. You
have to manage to remove the newly created file before it is chown()ed and
replace it by a link to something you'd like to chown(). I haven't managed
yet to exploit this race condition. (I've used something along the lines of
'while (unlink (...) < 0); symlink (...);' in a short C program.)

I'm told that the expreserve bug mentioned in the CERT advisories was caused
by a wrong file name argument being passed to stat(). So this new bug
might also be present on different platforms which have already been patched
to correct the old bug. Since we only run HPs, I don't have any means of
verifying this.

These bugs can be exploited because /usr/preserve is writeable for
everyone. I can't see why it has to be mode 0777, since expreserve is suid
to root, as is exrecover. So I've changed the mode of /usr/preserve to
0755. Does this restrict the functionality in any way? If not, I recommend
everyone to change the mode of /usr/preserve to 0755 until patches are
available.

I notified HP and CERT to weeks ago, so patches should be out 'real soon
now'.:)

-Thomas

-- 
Thomas Lopatic                               lopatic () informatik uni-muenchen de

--

- Paul "Shag" Walmsley <ccshag () cclabs missouri edu>
  "The only difference between myself and a madman is that I am not mad."
       - Salvador Dali