Christopher B. Browne's Home Page
cbbrowne@acm.org

6. A Good News Article Summarizing Linux Security Vulnerabilities

 

Linux commercial viability (was Re: Intel kicks Microsoft out ...)

"Jason" == Jason V Robertson~ writes:

" I'd have no problem breaking into your Solaris filesystem if you gave me an account on the machine. Getting root on a Unix machine is about as difficult as waiting for the next CERT advisory or looking through some suid programs for buffer overflows."

CERT advisories are not the right place to be looking for security vulnerabilities. Security fixes for most Linux versions, for example, arrive before the CERT advisories, usually weeks before. Read BUGTRAQ instead.

" What I'm talking about is the richness of the security subsystem in each OS. And NT beats Unix in this are hands down - there is no argument about it. "

It's a design issue. One person's "richness" is another's "complex design". " Whether overall security benefits from this is another question, but I think it does. "

I think it's too early to say, myself. " Of course it will. suid programs are an invitation unless they're written extremely carefully. Look at sendmail for hell's sake. There's a well written (security-wise) program! "

Not according to its author. " I give it two weeks after each new version until it's defeated. (Though I guess they're finally getting closer to a secure program.) "

Well, it takes one command to search a Unix system for all points of vulnerability of which you are speaking. dirs="/bin /sbin /usr/sbin /usr/bin" find $dirs -perm +6000 -print

...finds all set-UID or set-GID executables. For a slower but possibly more thorough search, use dirs="/". On the system I'm using here this returns 40 unique files out of a possible 142000. All the set-GID binaries were set-GID "lp" (for the printing subsystem) or mail (for the mail subsystem). This leaves 33 setuid-root binaries.

Most of these 40 setuid/gid programs are only setuid in order to control access to resources that are otherwise not accessible to users:

Changing user/group:

su newgrp login

Password admin:

chfn chsh passwd pwdb_chkpwd

Device access:

wall minicom cu write

Bind to reserved ports:

rcp rlogin rsh

Writing to /var

man

Raw net access:

ping traceroute usernetctl

Filesystem admin:

mount umount

UUCP:

uucp uuname uustat uux

Email:

elm sendmail procmail filter mutt lockfile

Cron:

at crontab

Perl:

suidperl

DOSEMU :

dos

News:

inndstart

All these programs are dynamically linked against the C library, 7 against the math library, 7 (of which 5 link to the Pluggable Authentication Module utilities) against the dynamic-linkling library, 5 against the PAM libraries themselves, 6 against libgdbm or libdb, 4 against libtermcap/slang, and one ( DOSEMU ) against libX11.

Hence all these nine libraries are potential areas for security problems, a total of 49 items of code to examine, including the C library.

This may sound quite dire, but 49 items is a fairly manageable number. OpenBSD, for example, purports to have managed it.

Also, few of these are mandatory. As far as I know, I could remove all but two of these programs, and remove the set-UID bit from those two, and still have a working system with fewer features (for example non-root users would not be able to mount floppies or read mail locally). On the other hand there are six programs run as root from /etc/inetd.conf as root, all of which are also optional. It's possible, then, to dramatically reduce the number of points of vulnerability, especially if you're happy to go without the corresponding functionality.

How sure are you of the all the possible points of vulnerability (here, root or other privilege compromise) in your system? For those you are sure about, how many of them can you eliminate?

" The subjective statement is that NT is more scalable than Unix. This is unproven. Implementations of higher scaling Unix-based OS's does not prove that NT is inherently more scalable. "

Both NT and the many Unix systems are moving targets. Supposing 4 (or 1 or 25, whatever) out of the dozens of Unix variants can be shown to "scale better" than NT this year, no doubt Microsoft will fix this for the next release. Presumably by that time NT-knockers will latch onto something else that N Unix implementations do better than NT, and "scalability" will no longer be such an issue.

If NT has to be better at everything than everything else, then that's a pretty hard target to make, and (IMHO) it isn't possible. Is it desirable? Or is it just that it has to be better at "scalability" and "security"? What about next year? My thesis here is that Unix is too diverse for NT to beat "Unix" on all fronts.

 
--James Youngman 
Google
Contact me at cbbrowne@acm.org