rob@cwruecmp.UUCP (rob robertson) (07/26/85)
A friend of mine noticed this, but the way at&t ships the Unix Pc software, the set uid bit on /bin/mv is set, and it is owned by root. He seems to think that this is a "back door" for the telephone support people, but it's a giant security breach, especially to those people at&t is trying to market to, business people who know little or nothing about Unix. With this, all a user need do is copy the passwd file to their own directory edit, and remove the passwd field, and then mv it back and then su to root. To remove this "feature" just chmod -s /bin/mv and it will be taken care of. william robertson usenet: decvax!cwruecmp!rob 1615 hazel arpa: rob.case@csnet-relay cleveland, ohio 44106 csnet, bitnet: rob@case (216) 791-0922
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/28/85)
> A friend of mine noticed this, but the way at&t ships the Unix Pc software, > the set uid bit on /bin/mv is set, and it is owned by root. He seems to > think that this is a "back door" for the telephone support people, but it's > a giant security breach, especially to those people at&t is trying to market > to, business people who know little or nothing about Unix. > > With this, all a user need do is copy the passwd file to their own directory > edit, and remove the passwd field, and then mv it back and then su to root. > > To remove this "feature" just chmod -s /bin/mv and it will be taken care of. Foo! If this is the version of "mv" that I suspect it is (pre-mvdir), the above scenario is entirely wrong. "mv" is set-UID so that it can move directories (done by relinking, which requires root privilege). Just because a program is set-UID root does not mean that it is stupid.
guy@sun.uucp (Guy Harris) (07/28/85)
> A friend of mine noticed this, but the way at&t ships the Unix Pc software, > the set uid bit on /bin/mv is set, and it is owned by root. He seems to > think that this is a "back door" for the telephone support people, but it's > a giant security breach, especially to those people at&t is trying to market > to, business people who know little or nothing about Unix. I got news for you guys; "/bin/mv" is set-UID root on V7, System III, 4.1BSD, and System V Release 1. This is necessary because, except on 4.2BSD where you can use the non-privileged "rename" system call, you must rename directories by doing a "link" of the new name to the old name and an "unlink" of the old name, and "link"s to and "unlink"s of directories are privileged operations. S5R2 has a separate set-UID program to do moving of directories. "mv" in all the non-4.2BSD/non-S5R2 systems gives up its set-UID privileges as soon as it figures out that it's not moving a directory; if it *is* moving a directory, it does all the requisite permissions checking itself. I don't know how much of the System V in the 7300's UNIX is S5R2 (where they have a separate-UID program to move directories), but it may not have the S5R2 "mv". > With this, all a user need do is copy the passwd file to their own directory > edit, and remove the passwd field, and then mv it back and then su to root. If it's the S5R1 "mv", you can *try* to "mv" the passwd file back - but you'll fail. > To remove this "feature" just chmod -s /bin/mv and it will be taken care of. And (if it's the S5R1 "mv") discover that you can't rename directories any more. Guy Harris
mark@laidbak.UUCP (Mark Brukhartz) (07/28/85)
System V Release 1 /bin/mv *should* be setuid to root. This is not a security breach; it allows mortal users to rename directories. On System V Release 2, /bin/mv invokes /usr/lib/mv_dir for directory operations; only the latter is setuid to root. Both of these setuid-root commands make the usual "can this user really do this" checks on their arguments. I know of no security bugs in "mv". Unfortunately, while a setuid command may have no obvious bugs, it is not always safe to say that it obviously has no bugs (...interesting how language works). Besides, an unethical system vendor might just as well put a trojan horse into the kernel or compiler. It could be well-hidden (at least if source was unavailable) and quite difficult to remove. Mark Brukhartz ..!ihnp4!laidbak!mark
mats@dual.UUCP (Mats Wichmann) (07/28/85)
> > A friend of mine noticed this, but the way at&t ships the Unix Pc software, > the set uid bit on /bin/mv is set, and it is owned by root. He seems to > think that this is a "back door" for the telephone support people, but it's > a giant security breach, especially to those people at&t is trying to market > to, business people who know little or nothing about Unix. > Ahem, this is true of all Sys releases, and is not a back-door unless someone left something else unprotected. The setuid bit stays effective for a very short while - long enough to determine whether the requested operation is renaming directories, which has to be done by root. As soon as it has been found that this is not the operation requested, the effective user ID is changed back to the real user ID, and superuser privelge goes away. Of course, if someone left /etc read/write by everyone, the above mentioned moving of the password file can be done. But that is certainly not the fault of the setuid-bit on mv!!! (By the way, one of the most common problems I have found in people building systesm from scratch it that the root directory is left read-write for everyone. Try an `ls -ld /' on your machine.....should be mode 755 or maybe 775.....if it is 777, someone can easily break in to your system....) Mats Wichmann Dual Systems ...{ucbvax,ihnp4,cbosgd,decwrl,fortune}!dual!mats
reeds@alice.UUCP (Jim Reeds) (07/29/85)
>> A friend of mine noticed this, but the way at&t ships the Unix Pc software, >> the set uid bit on /bin/mv is set, and it is owned by root. He seems to ... >> With this, all a user need do is copy the passwd file to their own directory >> edit, and remove the passwd field, and then mv it back and then su to root. ... >> To remove this "feature" just chmod -s /bin/mv and it will be taken care of. > >Foo! If this is the version of "mv" that I suspect it is (pre-mvdir), >the above scenario is entirely wrong. "mv" is set-UID so that it can >move directories (done by relinking, which requires root privilege). >Just because a program is set-UID root does not mean that it is stupid. Ah, I just tried it and it works. Very cute!
fred@mot.UUCP (Fred Christiansen) (07/29/85)
this oddity (setuid-to-root on /bin/mv) was in System V Rel 1, but has
disappeared with Rel 2. mv/cp/ln are now all linked together (which
has been historic, i believe).
i suspect CT passed on the oddity in Rel 1 (as did we, in
System V/M68000) because that's what the makefile made happen.
--
<< Generic disclaimer >>
Fred Christiansen ("Canajun, eh?") @ Motorola Microsystems, Tempe, AZ
UUCP: ihnp4!{attunix, btlunix, drivax, sftig, ut-sally!oakhill}!mot!fred
ARPA: oakhill!mot!fred@ut-sally.ARPA AT&T: 602-438-3472heiby@cuae2.UUCP (Ron Heiby) (07/31/85)
In article <1284@cwruecmp.UUCP> rob@cwruecmp.UUCP (rob robertson) writes: > >A friend of mine noticed this, but the way at&t ships the Unix Pc software, >the set uid bit on /bin/mv is set, and it is owned by root. He seems to >think that this is a "back door" for the telephone support people, but it's >a giant security breach, especially to those people at&t is trying to market >to, business people who know little or nothing about Unix. I can't explain why /bin/mv is suid to root. I don't know why it should be necessary. But, I did try to use it to move something in a directory to which I didn't have write access and it refused, saying that I didn't have write access to the directory. There is another situation that allows the /etc/passwd forgery, though. That is the permissions on the /etc directory. They are 777. The root directory permissions on my system are also 777. This has been reported and will likely be fixed in the next release. In the mean time, it would be a good idea to take a look at various critical directories and make sure that they are protected. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
rob@cwruecmp.UUCP (rob robertson) (08/01/85)
gwyn@brl-trg.ARPA (Doug Gwyn): >> A friend of mine noticed this, but the way at&t ships the Unix Pc software, >> the set uid bit on /bin/mv is set, and it is owned by root. >> >> With this, all a user need do is copy the passwd file to their own directory >> edit, and remove the passwd field, and then mv it back and then su to root. > >Foo! If this is the version of "mv" that I suspect it is (pre-mvdir), >the above scenario is entirely wrong. "mv" is set-UID so that it can >move directories (done by relinking, which requires root privilege). >Just because a program is set-UID root does not mean that it is stupid. fooey to you too, because the way it is on other systems doesn't mean it's the same on the Unix Pc. Unix ain't Unix.... See the following flame. guy@sun.UUCP(Guy Harris): >> A friend of mine noticed this, but the way at&t ships the Unix Pc software, >> the set uid bit on /bin/mv is set, and it is owned by root. > >I got news for you guys; "/bin/mv" is set-UID root on V7, System III, >4.1BSD, and System V Release 1. This is necessary because, except on 4.2BSD >where you can use the non-privileged "rename" system call, you must rename >directories by doing a "link" of the new name to the old name and an >"unlink" of the old name, and "link"s to and "unlink"s of directories are >privileged operations. S5R2 has a separate set-UID program to do moving of >directories. "mv" in all the non-4.2BSD/non-S5R2 systems gives up its >set-UID privileges as soon as it figures out that it's not moving a >directory; if it *is* moving a directory, it does all the requisite >permissions checking itself. I got news for you Guy: The current O/S of the Unix PC, you know the one mentioned in the header line is SYSTEMV 2.0. Try uname -a on your nearest Upc. >I don't know how much of the System V in the 7300's UNIX is S5R2 (where they >have a separate-UID program to move directories), but it may not have the >S5R2 "mv". I don't know either but one thing is true: with our version of /bin/mv I as an ordinary user can mv ANYTHING ANYWHERE I want it. For you non- believers try moving passwd to you directory then have everyone log out. >> With this, all a user need do is copy the passwd file to their own directory >> edit, and remove the passwd field, and then mv it back and then su to root. > >If it's the S5R1 "mv", you can *try* to "mv" the passwd file back - but >you'll fail. One question: Do you think I wrote this without trying it out? IT WORKS. >> To remove this "feature" just chmod -s /bin/mv and it will be taken care of. > >And (if it's the S5R1 "mv") discover that you can't rename directories any >more. And users will never pester the system manager for mounting disks again, they'll be able to do it themselves. I apologize to Guy if I'm a little perturbed, but evidently he doesn't have access to a Unix pc which my letter was about, not diffs in S5R1, BSD, S5R2 or V7. It was about what I could do on a Unix Pc with no privileges except login. If you have tried this on a Unix Pc, with the unmodified software and it doen't work then post articles And send me letters making me look like a fool. william robertson usenet: decvax!cwruecmp!rob 1615 hazel arpa: rob.case@csnet-relay cleveland, ohio 44106 csnet, bitnet: rob@case (216) 791-0922
guy@sun.uucp (Guy Harris) (08/02/85)
Unless you knew about the S5R1/S5R2 change before you posted your complain, you had no grounds for assuming that the setUID bit on "mv" was the problem. From other postings, it seems that the problem may have been that "/etc" was wide-open to the world. "Never ascribe to malice that which can be adequately explained by error." Guy Harris
mjs@eagle.UUCP (M.J.Shannon) (08/02/85)
> I don't know either but one thing is true: with our version of /bin/mv > I as an ordinary user can mv ANYTHING ANYWHERE I want it. For you non- > believers try moving passwd to you directory then have everyone log out. > > >> With this, all a user need do is copy the passwd file to their own directory > >> edit, and remove the passwd field, and then mv it back and then su to root. > > > >If it's the S5R1 "mv", you can *try* to "mv" the passwd file back - but > >you'll fail. > > One question: Do you think I wrote this without trying it out? IT WORKS. > > >> To remove this "feature" just chmod -s /bin/mv and it will be taken care of. > > > >And (if it's the S5R1 "mv") discover that you can't rename directories any > >more. > > And users will never pester the system manager for mounting disks again, > they'll be able to do it themselves. > > I apologize to Guy if I'm a little perturbed, but evidently he doesn't > have access to a Unix pc which my letter was about, not diffs in S5R1, BSD, > S5R2 or V7. It was about what I could do on a Unix Pc with no privileges > except login. If you have tried this on a Unix Pc, with the unmodified > software and it doen't work then post articles And send me letters making > me look like a fool. > > william robertson usenet: decvax!cwruecmp!rob Yes, you are inordinately perterbed, and your flame (er, um, article) shows this extremely well. As has been pointed out before (in at least 3 articles that I've seen), the reason J.Random User can use mv to diddle the passwd file is that, as shipped, the directory /etc (and several others as well, including / itself) have read, write, and execute permission for anyone. Since /etc is writable, any file may be removed from there and replaced by any user. To put things right on your machine, you must "chmod go-w /etc" as root (and restore the setuid bit on /bin/mv, if you've unset it). I have done this on my UNIX PC, and random users can no longer nuke the precious files in /etc at whim. To reiterate: the setuid bit on /bin/mv is necessary to allow users to rename directories. There are several directories on the UNIX PC which, as shipped, are disastrous for secure machines (not that you can have security on a machine that has a data line enabled). Before you flame again, please perform the exercise I indicate in this article, and mail me the results. You should then make a public apology to the net. -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063 Warped people are throwbacks from the days of the United Federation of Planets.
david@ukma.UUCP (David Herron, NPR Lover) (08/03/85)
So, what's the problem. the Unix PC is a single user machine.
--
--- David Herron
--- ARPA-> ukma!david@ANL-MCS.ARPA
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
--- {ihnp4,decvax,ucbvax}!cbosgd!ukma!davidlarry@kitty.UUCP (Larry Lippman) (08/07/85)
> So, what's the problem. the Unix PC is a single user machine. > -- > --- David Herron Huh? Where have you been since April? Larry Lippman Recognition Research Corp. Clarence, New York UUCP {decvax,dual,rocksanne,rocksvax,watmath}!sunybcs!kitty!larry {rice,shell}!baylor!/ syr!buf!/ VOICE 716/741-9185 TELEX {via WUI} 69-71461 answerback: ELGECOMCLR "Have you hugged your cat today?"
revc@gwsd.UUCP (Bob Van Cleef) (08/07/85)
In article <2013@ukma.UUCP>, david@ukma.UUCP (David Herron, NPR Lover) writes: > So, what's the problem. the Unix PC is a single user machine. > -- > --- David Herron Even if there was no physical way for more than one user to log on to a Unix PC at the same time, there is nothing to forbid more than one individual in the same office/home/... from sharing the machine. As it is, you can easily have 3 individuals using the machine at the same time ( Console, Serial Port, Modem Port). In any environment it is very easy to imagine: ( one technical user - more than one non-technical user) ( me - my wife and children ) The non-technical users need to be protected from themselves. More damage is done out of ignorance than out of maliciousness. Bob -- Bob Van Cleef {ihnp4|akgua|decvax|dcdwest|ucbvax} (619) 457-1986 ...sdcsvax!gwsd!revc Gateway Computer Systems CompuServe - 71565,533 4980 Carroll Canyon Road San Diego, CA 92121
sullivan@harvard.ARPA (John M. Sullivan) (08/08/85)
1. mv is setuid so that it can move directories. 2. It is not stupid, and won't let you do things you shouldn't be allowed to, probably because it does setuid(getuid()). 3. The version number 2.0 on Upc Unix has nothing to do with V7, SV, etc. Last fall there were versions x1.?,...,x5.?, then 1.0 and finally the released version 2.0. These numbers all refer to versions of the Unix PC system, and are all derived from System V with demand paging added by CT. 4. Any user can move files into or out of /etc (or /) because the directory is publically writable. 5. My favorite security hole is letting any user mount a floppy. John Sullivan -- John M. Sullivan sullivan@harvard