[667] in linux-security and linux-alert archive
[linux-security] Security problems in RedHat 3.0.3...
daemon@ATHENA.MIT.EDU (Zygo Blaxell)
Fri Apr 12 14:22:46 1996
From: Zygo Blaxell <zblaxell@myrus.com>
To: linux-security@tarsier.cv.nrao.edu
Date: Wed, 10 Apr 1996 14:46:16 -0400 (EDT)
Hmmm...after running 'ftp-install' on RedHat 3.0.3, I find two
disturbing things--neither of which is an exploitable security hole per
se, but they can be combined with bugs that would otherwise be harmless
to become vulnerabilities. The first problem regards file permissions
and the contents of the default /etc/group file, which can be used to
turn harmless bugs into root access.
Problem 1. 'root' is a member of several groups in /etc/group, and
there are lots of files like this:
-rw-rw-r-- 1 root root 357544 Feb 27 05:02 /usr/bin/...
This means that if any program run as root fails to do initgroups()
properly when running an unprivileged child, it will give away write
access to these files.
The initgroups() bug has been a problem in the past with several
programs like cfingerd (.fingerrc files were run with the right
e?[ug]id, but the group list was root's), cron (configure failed to
detect initgroups() for some reason, and just never called it), xdm, and
so on.
Now, arguably, the correct solution is to fix all these programs and
educate developers about good code design and testing; however, this
hasn't worked very well in the past and certainly won't get any better
in the future. Many (though not enough) developers understand and test
for obvious problems like child processes running as root when they
shouldn't be; fewer check for problems with group access; and even fewer
bother with initgroups() and all of its less-portable clones and
operating system idiosyncrasies.
If someone compromises an NFS client with write access, they can often have
any group ID they want to use on any file they can access on the NFS
server. Also, if you can get access to 'bin' or 'daemon' (both in group
'root' in RedHat), then you can modify files in group root as well, if
you have write permission.
Since there are so many of these programs, and the new ones have this
sort of problem all the time, I suggest the following additional
measures:
Fix 1: delete the word 'root' every time it appears to the right of a
colon in /etc/group. Think about it: the root user doesn't *need*
group access to *anything*. The supplementary groups list for daemons
run as root should really be empty, because less-privileged child
processes might accidentally inherit it.
Fix 2: Remove group write permissions from anything (files and
directories) that doesn't *need* them. This includes just about
everything under /usr.
Fix 1 and fix 2 combined would be even better.
I use a policy for files in /usr/bin similar to "all files in /usr/bin
are owned by root, group root, mode 555, unless they must be setuid
and/or setgid, in which case they become one of 6555, 4555, or 2555 and
owner or group changes accordingly". This makes it easy to spot files
that don't fit the pattern.
<PEEVE>
Giving binaries default permissions like 4111 (as opposed to 4555, i.e.
denying read permission) is not even marginally effective as a security
measure--if you installed a FooBar 4.5.6 distribution, then someone else
can get one and read the files in their copy of the same distribution.
It is probably effective as a copy-protection measure, but
copy-protection is inappropriate for freely available software
(which most of RedHat is).
</PEEVE>
It might be effective if one made *all* files mode 4111 *and* made local
modifications to the system, since any vulnerabilities created or
removed by these modifications would be harder to discover. This
is security through obscurity: no vulnerabilities are fixed by the
permission change, they merely take a few minutes longer to find, and
the attacker must find them through active experimentation. For the
security-conscious even measures that delay rather than prevent are
useful.
Problem 2: I typed 'man 8 somefile' (program name changed to protect
the innocent ;-) and found this in /var/catman/cat8:
-r--rw-r-- 1 zblaxell man 11252 Apr 10 10:47 somefile.8.gz
This is a little disturbing; it means that any user can rewrite man
pages if they read them before any other user did. This can lead to all
sorts of entertaining social engineering attacks against neophyte users
(or worse, sysadmins). Imagine: "To restart the news server after
modifying the configuration file, be sure to remove any state files and
purge the news database. You can do this by typing
'rm -rf /var/spool/news/../../../ &' as root--the news server daemon will
rebuild its state files automatically when it is next started. This can
take a long time (several hours) on busy news servers."
Fix 1: make the man program operate setuid instead of setgid. This
will prevent users from having access to the cat files. This also
brings up a number of runtime environment issues: has the user set an
alarm() before execve()ing man? What happens to the catman page if the
user kills the man process half-way through? What if the man page
formatting program (which runs under the user's own privileges) is
subverted through environment variables (which aren't stripped out
whatever RedHat's using as /usr/bin/man) or process tracing?
Fix 2: rm -rf /var/catman, chmod ug-s /usr/bin/man, and do without a
man page cache. Linux on a P133 can format the perl4 man page in less
than five seconds, and computers only get faster.
Fix 3: implement a remote man page daemon from inetd:
rman stream tcp nowait man:man /usr/sbin/tcpd in.rmand
in.rmand can be a simple perl script that allows /(\d\w*? )\w[\w.+-]*/
as a query (optional digits followed by letters followed by space, then
an alphanumeric character, then more alphanumeric characters, dots,
dashes, and + characters), runs 'man' as user 'man' (or other non-root
alternative) group 'man', with no pager.
Access control to 'rmand' can be provided by 'tcpd', by firewall
configuration, by implementing it instead with a Unix-domain socket, or
by adding support for an access list to rmand itself. Once this is
set up, then 'man' can be stripped of set[ug]id bits (and should refuse
to run when given them, explaining its sordid past and what to do instead).
The 'man' program would then contact 'rmand' for all simple queries
(e.g. 'man 3 syslog') and bypass the page cache in /var/catman by itself
for all other queries (i.e. ones that request troff formatting or
preprocessors).
More ambitious implementations should allow for a remote man page server
with system type and language queries. For example, a query might look like
'Linux 1.3.84 de_DE.88591,ja_JP.jis,en_US 1x color-xterm 2.3' for the
'color-xterm' man page in Germany, Japanese, or English, for Linux
version 1.3.84, color xterm version 2.3. The client should be able to
handle multi-part responses in case more than one man page shows up.
Since HTTP implements all this anyway, it might be even smarter to
just make the 'man' command transparently access a CGI script using a
minimal subset of HTTP. This has these advantages:
- Rapid implementation of minimal servers. If you only have one
OS, version, language, encoding, and man page to choose from, you can
just ignore these fields in the queries and hard-code them in the
responses, and use a small subset of HTTP to simplify implementation.
Thus the 'man' command becomes a simple HTTP client (<25 lines) with
pager. It isn't necessary to support HTML, since the catman pages are
text/plain anyway.
- Use of standard tools and protocols. You don't have to
implement an HTTP server if you can use an existing one. Plus,
you can take advantage of HTTP/MIME features like language and
character-encoding support if you do have an international-aware HTTP
server.
- Somehow, we lost the original problem. HTTP already has
support for caching, possibly eliminating the need for a separate man
page cache.
There are also disadvantages:
- IP/DNS spoofing and the usual HTTP cache consistency issues.
Is asking a network host for your system documentation (even if it is
localhost) more secure than reading a file on the local filesystem, even
if that file can be rewritten at will by its creator?
- Complexity/reliability issues. This means you *need* to run
a network server of some sort if you want to cache man pages. This
probably isn't an issue for distribution maintainers, since they can
just add the server to the "base" system when man pages and the 'man'
program are installed.
--
Zygo Blaxell. Former Unix/soft/hardware guru, U of Waterloo Computer Science
Club. Current sysadmin for Myrus Design, Inc. 10th place, ACM Intl Collegiate
Programming Contest Finals, 1994. Administer Linux nets for food, clothing,
and anime. "I gave up $1000 to avoid working on windoze... *sigh*" - Amy Fong
