scs@athena.mit.edu (Steve Summit) (11/20/88)
One of the disturbing things about Unix security is that bugs in
the protection mechanisms tend to be catastrophic: they don't
just let you do some little unintended thing; more often than not
they let you do anything, as root. For instance, Guy Harris
recently reminded us of
rlogin host -l ''
which (I assume) makes use of the
::0:0:::
lines which are, incredibly, still routinely left in the passwd
file by broken software. I find it rather astonishing that these
"turds" in the passwd file not only do not prevent the file's
being read (most bugs break things badly), but in fact happen to
introduce everybody's worst nightmare: a wide open, unrestricted
security hole.
Of course, in Computer Science, as in Mathematics, as in Nature,
everything drains towards 0, so the fact that uid 0 is both the
superuser and the most likely accidental value can be seen as an
invitation to disaster.
If only the kernel tested for superuser status neither with
if(!u.u_uid)
nor with
if(u.uid == 0)
but with
if(u.uid == SUPERUSER)
Then it would be a relatively simple matter to re#define
SUPERUSER to some really unlikely value. (I have seen kernel
code which uses if(suser()), which would also allow easy
remapping.)
I am quite aware of how well-entrenched is the notion that the
superuser is uid 0, and what a massive and error-prone
undertaking such a redefinition would consequently be.
This is a good example of why embedding "magic numbers" and other
assumptions in source code (rather than using #defines or other
modular practices) is almost never a good idea. (Ah, the acuity
of 20/20 hindsight.)
Steve Summit
scs@adam.pika.mit.edubzs@encore.com (Barry Shein) (11/20/88)
From: scs@athena.mit.edu (Steve Summit) >One of the disturbing things about Unix security is that bugs in >the protection mechanisms tend to be catastrophic: they don't >just let you do some little unintended thing; more often than not >they let you do anything, as root. I don't know why you imply that somehow unix is more susceptible to such security bugs than other systems, do you base this on anything or did it just sound good at the time? I can list various serious security bugs that have cropped up in other O/S's just as inherent to their design, or misfeatures. >Of course, in Computer Science, as in Mathematics, as in Nature, >everything drains towards 0, so the fact that uid 0 is both the >superuser and the most likely accidental value can be seen as an >invitation to disaster. > >If only the kernel tested for superuser status neither with > > if(!u.u_uid) > >nor with > > if(u.uid == 0) > >but with > > if(u.uid == SUPERUSER) I'm not sure I go along with your theory that zero is the most common random number or whatever it was you were postulating. Actually, modern kernels use an suser() boolean function, although I'll guarantee you a lot of utilities do assume the superuser id is 0. It can be done but someone will have to demonstrate the effectiveness of bothering. In the current panic/mob-mentality mode I see on this list tho it will hardly need justification, every stupid idea ever thought of will be implemented somewhere. The real "problem" with Unix is simple: Unix, for many years of its life, was a maverick system supported by basically no one although hacked on by many. Now suddenly in the last year or two everyone woke up (IMHO) and decided that Unix is was right all along. That's very nice, but the years of malice and neglect show at this point. It's too bad that people wasted billions and billions on brain-damaged upper-case operating systems for so many years (and still do) and sneered at Unix but that's history, you can't retrieve the money they wasted although some of those folks oughta be vilified for their myopia, most of them are probably too busy declaring themselves Unix gurus. Unix wasn't exactly ignored either, it was the victim over the years of many carefully constructed campaigns to destroy it, the most vicious of which involved vigorous vendor attempts to get people who brought Unix into shops fired. Most of them today take out full page ads declaring themselves to be *the* Unix vendor. Maybe folks are venting their anger at the wrong folks. Sun for example didn't screw you, they saved you by demonstrating to the world that Unix can be good business and legitimizing it. At least you're on a reasonable path now to get some work done and shop for the hardware you need rather than what's shoved down your throat. Give it a few years and maybe these problems will be solved, and most likely with it Unix will become expensive... -Barry Shein, ||Encore||
warren@wwd.UUCP (Warren Burstein) (11/22/88)
In article <8064@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: > ::0:0::: >lines which are, incredibly, still routinely left in the passwd >file by broken software. Just what does cause these? I haven't seen any for a while. Are there particular programs responsible? I once had passwd so full of them that ls -l ran noticably slow. -- /|/-\/-\ The entire world |__/__/_/ is a very strange carrot |warren@ But the farmer / wwd.UUCP is not worried at all.
prc@ERBE.SE (Robert Claeson) (11/23/88)
In article <4245@encore.UUCP>, bzs@encore.com (Barry Shein) writes: > Maybe folks are venting their anger at the wrong folks. Sun for > example didn't screw you, they saved you by demonstrating to the world > that Unix can be good business and legitimizing it. At least you're on > a reasonable path now to get some work done and shop for the hardware > you need rather than what's shoved down your throat. > > Give it a few years and maybe these problems will be solved, and most > likely with it Unix will become expensive... And then we'll have to look for another (non-uppercase, open and inexpensive) OS (that we can get for only the media cost)... -- Robert Claeson ERBE DATA AB rclaeson@ERBE.SE
gandalf@csli.STANFORD.EDU (Juergen Wagner) (11/23/88)
Empty lines or comments in /etc/passwd caused the ::0:0:: or #::0:0:: lines. Every time somebody changes his/her password, the passwd program would read /etc/passwd, taking the respective lines for entries with an empty user name, uid zero, etc., and later write them out. Since some entries would contain a newline char as username, the number of these phantom user entries would grow with each change made to any password on the system... I hope people aren't using the buggy version of passwd any more... -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
bzs@encore.com (Barry Shein) (11/25/88)
From: prc@ERBE.SE (Robert Claeson) >In article <4245@encore.UUCP>, bzs@encore.com (Barry Shein) writes: >> Give it a few years and maybe these problems will be solved, and most >> likely with it Unix will become expensive... > >And then we'll have to look for another (non-uppercase, open and >inexpensive) OS (that we can get for only the media cost)... Right, and then add all the features we always needed/wanted, get vendors to support it, complain about more missing "features" until it's big, fat and expensive. And then we'll have to look for another (non-uppercase, open and inexpensive) OS (that we can get for only the media cost)... I think we've just discovered another software wheel of reincarnation... -Barry Shein, ||Encore||