stevesu@copper.UUCP (Steve Summit) (11/02/86)
In article <8616@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > > Anyway, if a setuid program overwrites itself, it is no longer setuid! > > It says this *in the 4BSD manual page for write(2)*; this is a Berkeleyism. > I consider it to be an airbag; I'm not sure it's worth putting in a hack > like this to protect people who don't remember to make set-UID programs > writable only by the owner. I think this airbag solves a significant class of potential security problems, such as the following: once I was snooping around looking for setuid programs (never mind why :-), and I discovered that, to my astonishment, /usr/bin/uniq was setuid root! (My guess is that somebody wanted to make uusend, uulog, etc. setuid uucp, and accidentally typed chmod +s u* instead of uu*.) This wasn't a general security hole, yet, since being root doesn't do you much good if all you can do is report repeated lines in a file. But since uniq happens to take an output filename argument, I could have parlayed that hole into a general one, by using the incongrously setuid uniq to scribble a genuinely useful program (like /bin/sh) onto a previously setuid program (like /bin/passwd). It's true that limited write ability could still be used to scribble on /etc/passwd (which is less desirable for a hacker's purpose due to console log messages for su's), and to do a few more subtle tricks (which I think I won't mention). Steve Summit tektronix!copper!stevesu
guy@sun.uucp (Guy Harris) (11/03/86)
> I think this airbag solves a significant class of potential > security problems, such as the following: once I was snooping > around looking for setuid programs (never mind why :-), and I > discovered that, to my astonishment, /usr/bin/uniq was setuid > root! This class of "passive restraint", like the automotive kind, seems to be intended to protect people who would not otherwise protect themselves. As you point out, even with that particular sodium-azide-bag, a would-be system cracker can do a fair bit of damage with an inappropriately-set-UID program. The added protection provided by turning off the set-UID bit when writing to a file is pretty minimal in this case. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)