Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!tektronix!teklds!copper!stevesu From: stevesu@copper.UUCP (Steve Summit) Newsgroups: net.unix-wizards Subject: Re: write clears setuid Message-ID: <700@copper.UUCP> Date: Sat, 1-Nov-86 21:19:02 EST Article-I.D.: copper.700 Posted: Sat Nov 1 21:19:02 1986 Date-Received: Tue, 4-Nov-86 00:29:44 EST References: <115@tijc02.UUCP> <735@hropus.UUCP> <1040@ho95e.UUCP> <8616@sun.uucp> Organization: Tektronix Inc., Beaverton, Or. Lines: 29 Summary: airbag maybe, but good for something... 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