[671] in linux-security and linux-alert archive
Re: [linux-security] Security problems in RedHat 3.0.3...
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Mon Apr 15 17:00:21 1996
From: Zygo Blaxell <zblaxell@myrus.com>
To: R.E.Wolff@et.tudelft.nl (Rogier Wolff)
Date: Mon, 15 Apr 1996 12:07:07 -0400 (EDT)
Cc: zblaxell@myrus.com, linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199604121837.AA126974273@erasmus.et.tudelft.nl> from "Rogier Wolff" at Apr 12, 96 08:37:53 pm
Quoted from Rogier Wolff:
> > Fix 1: make the man program operate setuid instead of setgid. This
>
> [Unverified rumor]
> Ehm.... while on the subject of "man" bugs, man and/or groff will run
> arbitrary programs under specification of the man-page-writer.......
>
> Do you still want "man" running setuid? (Yes I understand, you want
> man running as an upriviliged user. However in combination with
> the bug above, this will subvert your suggested fix)
Arbitrary programs? This sounds like a *really* bad problem no matter
what circumstances the 'man' program runs under. It means that we can
have man page trojans, among other things. Exactly how is this
mechanism invoked?
Can we fix vulnerabilities introduced by the man page writer? If
the man page writer is strictly limited in what commands can be invoked
and what parameters they can use, it should be relatively easy to
contain things. I thought that was the intent of the lines in
/etc/man.config that specify NROFF, etc.
Man pages in non-standard MANPATH locations should not be cached, or at
least not cached with 'man' group privileges. Unfortunately, in RedHat,
they are. ARGH! It's worse than I thought! Try this:
PATH=$HOME/bin:${PATH-/usr/bin:/bin}
mkdir -p $HOME/bin $HOME/man/man1 $HOME/man/cat1
cp /usr/man/man1/perl.1 $HOME/man/man1
man perl
ls -l $HOME/man/cat1/
I get:
total 6
6 -r--rw-r-- 1 zblaxell man 5129 Apr 15 10:42 perl.1.gz
This means that I can overwrite *any* man page (or at least its cached
copy) I like with *any* contents I like, since I control the contents of
all the paths involved, the man page formatting processes, the
search path for 'man', and I can win race conditions, and man doesn't
use O_EXCL when open()ing its output. D'oh!
Note that with the networked version of the man page cache I described,
this problem doesn't happen. The 'man' command is not set[ug]id, and
the network 'man daemon' can't be coerced into processing a man page
submitted by a user.
Back to the original problem...
We can divide man pages into 'trustworthy' and 'untrustworthy'
pages by using /etc/man.config. If a man page is found on a search path
in this file, it is trustworthy, otherwise it is not. Man directories
listed in /etc/man.config must be limited to directories that are
controlled by trustworthy users, such as root.
System man pages are written by someone trustworthy, and all other man
pages, such as those written by users and located on the MANPATH, are
not necessarily trustworthy. Then we simply never use 'man' privileges
on 'untrustworthy' man pages.
We can still cache 'untrustworthy' man pages if the userID invoking the
'man' program happens to have write permission to a nearby 'cat'
directory, but this doesn't give users any more privileges than they had
already. This would be useful for a user who for whatever reason has
installed a man hierarchy in their home directory, perhaps for some
privately installed programs.
There should be some way to specify untrusted directories in
/etc/man.config explicitly, so that users can find man pages by default
without invoking privileges to format them--unfortunately, that means
these man pages can never be cached as well, unless someone preformats
the pages and stores them in the cache as an already-trusted user.
Another nifty feature would be to allow user-specific man page caches
and get rid of the shared cache altogether. The man page cache would be
by default somewhere like $HOME/.catman, which may be a symlink
elsewhere, or an environment variable named 'MANCACHEPATH'. This way
nobody has to trust anyone but themselves, the system administrator, and
whoever wrote the man page. ** In fact, just this one feature would solve
almost all of the problems without adding very much complexity or
new design at all. **
You can also make the RedHat-supplied 'man' command do this:
umask 022
for n in 1 2 3 4 5 6 7 8 9 n; do
mkdir -p $HOME/man/{man,cat}$n
ln -fs /usr/{X11R6,local,}/man/man$n/* $HOME/man/man$n
done
mkdir $HOME/bin
cp /usr/bin/man $HOME/bin # look ma, no setgid!
chmod a-s $HOME/bin/man # just to be sure...
then set MANPATH to "$HOME/man" and PATH to
"$HOME/bin:${PATH-/usr/bin:/bin}".
Then, whenever 'man' is invoked, it will search and use a user's own
cache, without invoking or requiring special privileges.
--
Zygo Blaxell, Network admin, Linux system support, Windows '95 moral support
Myrus Design Inc. Tel: +1 613 233 2339
Suite 203, 275 Bank St. 93 Glebe Avenue
Ottawa, Ontario, Canada K2C 1E3 Ottawa, Ontario, Canada K1S 2C2
