dan@gacvx2.gac.edu (03/19/91)
Greetings, Is there anything inherently evil giving world write access to the "root" (aka "/") directory on a BSD 4.3 UNIX system? The exact permission with the command "ls -ld /" is "drwxrwxrwt". I have been thinking about it for a few hours now and the worst thing I have come up with is writing "rc" files that the unsuspecting "root" user could execute and the .rhosts file could be created if it didn't already exist. For readers who are about to write back and tell it it is a bad idea, I have already figured that out. However the operating system I am dealing with ships with the protection set this way. Setting the protection correctly would disable a major feature of this vendors OS. Feel free to use e-mail or phone to respond. This information is to be used in a bug report to the vendor which they will hopefully forward to CERT if necessary. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
mjr@hussar.dco.dec.com (Marcus J. Ranum) (03/19/91)
In article <1991Mar18.200957.166@gacvx2.gac.edu> dan@gacvx2.gac.edu writes: >Greetings, > >Is there anything inherently evil giving world write access to the "root" (aka >"/") directory on a BSD 4.3 UNIX system? The exact permission with the command >"ls -ld /" is "drwxrwxrwt". mv /bin /... mkdir /bin ln /.../* /bin mv ~/myloginthatmailsmeallloginpasswords /bin/login unsubtle, but you get the idea. it's not "inherently evil" it's inherently brain-dead. mjr. -- The world is just backing store for virtual reality.
sef@kithrup.COM (Sean Eric Fagan) (03/20/91)
In article <1991Mar19.151145.11208@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >>"ls -ld /" is "drwxrwxrwt". > mv /bin /... Won't work. Notice the sticky-bit is set on /. That means you cannot delete or rename files that you do not own. You can create new files and directories in /, but that's about it. So it's less insecure than it appears. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
ric@optima.UUCP (Ric Anderson,GS-746,6214048,) (03/20/91)
From article <1991Mar19.194216.5763@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): > In article <1991Mar19.151145.11208@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >>>"ls -ld /" is "drwxrwxrwt". >> mv /bin /... > > Won't work. Notice the sticky-bit is set on /. That means you cannot delete > or rename files that you do not own. You can create new files and > directories in /, but that's about it. So it's less insecure than it > appears. > Sean Eric Fagan sef@kithrup.COM The sticky bit is NOT (repeat NOT) implemented on all systems. If the sticky bit is implemented CORRECTLY, then the worst I can do is create a file in /, and make it grow till "/" fills up. This is good for a crash on some systems :-) However, if the sticky bit is unimplemented, or is implemented half heartedly, then you can move files you own on top of files someone else owns (even though you may not be able to rm files owned by others). Ric Ric Anderson Member of the Technical Staff University of Arizona Internet: ric@cs.arizona.edu Department of Computer Science UUCP: uunet!arizona!ric Gould-Simpson Room 721 Bitnet: ric%cs.arizona.edu@arizona.bitnet Tucson, Arizona 85721 AT&T: (602) 621-4048
dan@gacvx2.gac.edu (03/20/91)
In article <1991Mar18.200957.166@gacvx2.gac.edu>, dan@gacvx2.gac.edu writes: > Greetings, > > Is there anything inherently evil giving world write access to the "root" (aka > "/") directory on a BSD 4.3 UNIX system? The exact permission with the command > "ls -ld /" is "drwxrwxrwt". I have been thinking about it for a few hours now > and the worst thing I have come up with is writing "rc" files that the > unsuspecting "root" user could execute and the .rhosts file could be created if > it didn't already exist. For readers who are about to write back and tell it > it is a bad idea, I have already figured that out. However the operating > system I am dealing with ships with the protection set this way. Setting the > protection correctly would disable a major feature of this vendors OS. Feel > free to use e-mail or phone to respond. This information is to be used in a > bug report to the vendor which they will hopefully forward to CERT if > necessary. Thanks to everyone who replied to my posting. I was able to take the information sent to me to the vendor. It turns out that I had an old copy of the sys admin. The new version of the manual contains everything needed to fix this hole. Part of the fix is to "chmod 755 /". The new manual is great! I received a great deal of wisdom today on security from both the readers of this group and the vendor. The vendor wishes to state that they are very security minded and do give the instruction in their manual on making the system secure. Another case of RTFM... -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
navarra@casbah.acns.nwu.edu (The MaD ScIeNTiSt) (03/20/91)
>However, if the sticky bit is unimplemented, or is implemented half >heartedly, then you can move files you own on top of files someone else >owns (even though you may not be able to rm files owned by others). Wonder what would happen if you did something like moving core on top of /.cshrc or /.login? how bout ln core .cshrc? how bout: cp /dev/zero / (is that possible i wonder?) ln zero .cshrc Sounds particulary nasty. This is only a speculation, not an exhibition so please please -- no wagering! -- From the Lab of the MAd ScIenTisT.... navarra@casbah.acns.nwu.edu
debra@wsinis03.info.win.tue.nl (Paul de Bra) (03/20/91)
In article <1991Mar18.200957.166@gacvx2.gac.edu> dan@gacvx2.gac.edu writes: >Is there anything inherently evil giving world write access to the "root" (aka >"/") directory on a BSD 4.3 UNIX system? The exact permission with the command >"ls -ld /" is "drwxrwxrwt". Let's see, a user could: - remove the kernel (/vmunix or /unix) so you cannot reboot after a crash - mv /dev /somethingelse so all devices are unknown (inluding the tty's so noone can log on...) - mv /etc /somethingelse and then mkdir /etc, create your own /etc/passwd... Need any more hints? Paul. (debra@win.tue.nl, debra@research.att.com)
edotto@ux1.cso.uiuc.edu (Ed Otto) (03/21/91)
dan@gacvx2.gac.edu writes: >Greetings, > >Is there anything inherently evil giving world write access to the "root" (aka >"/") directory on a BSD 4.3 UNIX system? The exact permission with the command >"ls -ld /" is "drwxrwxrwt". I have been thinking about it for a few hours now >and the worst thing I have come up with is writing "rc" files that the >unsuspecting "root" user could execute and the .rhosts file could be created if >it didn't already exist. For readers who are about to write back and tell it >it is a bad idea, I have already figured that out. However the operating >system I am dealing with ships with the protection set this way. Setting the >protection correctly would disable a major feature of this vendors OS. Feel >free to use e-mail or phone to respond. This information is to be used in a >bug report to the vendor which they will hopefully forward to CERT if >necessary. What machine is this? I want to overwrite their operating system with one of myown... But seriously,I think that this is not a problem as mine is the same way. I think that world MUST have write access to the root fs, because otherwise I don't think that you could write ANYTHING on the entire file system unless you were logged in as 'root'... If not, will someone please tell ME so I can change mine, too?
rickert@mp.cs.niu.edu (Neil Rickert) (03/21/91)
In article <1991Mar20.165442.7210@ux1.cso.uiuc.edu> edotto@ux1.cso.uiuc.edu (Ed Otto) writes: > >But seriously,I think that this is not a problem as mine is the same way. Don't assume that just because your system comes standardly set up in a certain way, there are no problems with that setup. Vendors are notorious for providing systems which are highly secure when set up on a private network with only one user, but in which security breaks down in more practical environments. As an example, at least one has made a practice of supplying systems with a default setup such that if you connect the system to Internet and make a DNS resolver function available in the recommended way, just about anyone with root access on any Internet machine can quickly break in. For all I know they are still supplying systems with this setup. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
dan@gacvx2.gac.edu (03/21/91)
> The sticky bit is NOT (repeat NOT) implemented on all systems. If the > sticky bit is implemented CORRECTLY, then the worst I can do is create > a file in /, and make it grow till "/" fills up. This is good for a > crash on some systems :-) > > However, if the sticky bit is unimplemented, or is implemented half > heartedly, then you can move files you own on top of files someone else > owns (even though you may not be able to rm files owned by others). The sticky bit works quite well on the system with the problem. Even with the protection set to 1777 the system was hard to break. I had to use holes in programs that were supplied by third parties to break into the system. The version of Emacs that I have and a communications program with a "rc" script were to of the ways I found to break in. Emacs didn't check the owner of .emacsrc. In both cases "root" had to be tricked into running the scripts. I still think that leaving the root set to 1777 is a bad idea, and I have been given instructions by the vendor that will allow me to set the root set to 755. The vendor did a good job fixing the hole opened up by the protection, however they cannot fix things they have no control over. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
henk@cs.vu.nl (Henk Smit) (03/21/91)
debra@wsinis03.info.win.tue.nl (Paul de Bra) writes: >In article <1991Mar18.200957.166@gacvx2.gac.edu> dan@gacvx2.gac.edu writes: >>Is there anything inherently evil giving world write access to the "root" (aka >>"/") directory on a BSD 4.3 UNIX system? The exact permission with the command >>"ls -ld /" is "drwxrwxrwt". >Let's see, a user could: >- remove the kernel (/vmunix or /unix) so you cannot reboot after a crash >- mv /dev /somethingelse so all devices are unknown (inluding the tty's > so noone can log on...) >- mv /etc /somethingelse and then mkdir /etc, create your own /etc/passwd... This would be possible if the permission on / was "drwxrwxrwx", but it is not ! The "t" (sticky bit) on directories means that you must not only have write permission on the directory, but also be the owner of the file (or directory) that you want to (re)move. The only problem I can see sofar, is if /etc/rc.local contains some lines like if [ -f /somepackage/bin/daemon ] then /somepackage/bin/daemon; echo "somepackage started" fi If "somepackage" is not installed, JoeUser can make his own /somepackage/bin/daemon and wait untill the machine reboots. But most software I have seen lives in "/usr/somepackage", so I guess this will not be a problem. How strange it seems, I can't see an obvious security gap in "drwxrwxrwt" on /. Henk. -- Henk Smit Vrije Universiteit Amsterdam Internet: henk@cs.vu.nl Faculteit Informatica kamer S4.10 Phone: +31 20 548 6218
jik@athena.mit.edu (Jonathan I. Kamens) (03/21/91)
In article <1991Mar20.165442.7210@ux1.cso.uiuc.edu>, edotto@ux1.cso.uiuc.edu (Ed Otto) writes: |> But seriously,I think that this is not a problem as mine is the same way. |> I think that world MUST have write access to the root fs, because otherwise |> I don't think that you could write ANYTHING on the entire file system unless |> you were logged in as 'root'... What exactly do you mean by this? % pwd /site/tmp % ls -ldg / /site /site/tmp drwxr-xr-x 18 root wheel 512 Mar 20 18:19 // drwxr-xr-x 5 root wheel 512 Mar 20 15:39 /site/ drwxrwxrwt 3 root wheel 4096 Mar 20 18:47 /site/tmp/ % touch foobar % whoami jik To write to a directory, you only need *execute* permission on all the directories above it, and *write* permission to the directory itself. A Unix that required write access to all parent directories would be a strange kind of Unix indeed, and nothing like any I've ever come across. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
pfalstad@phoenix.Princeton.EDU (Paul Falstad) (03/21/91)
jik@athena.mit.edu (Jonathan I. Kamens) wrote: >To write to a directory, you only need *execute* permission on all the >directories above it... % cd /tmp % mkdir -p foo/bar % cd foo/bar % chmod 000 /tmp/foo % touch fubar % It's hard to get to a directory if you don't have execute permission on all its parents, but once you're there, it doesn't matter. I'm sure jik knows this, probably just a slip of the finger... (I suppressed the urge to say WRONG! WRONG! WRONG! :-) -- Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD To boost the economy, I'd tax all foreigners living abroad. Well, at least it's *FRESH* puke! -Basil Fawlty
barnett@grymoire.crd.ge.com (Bruce Barnett) (03/22/91)
In article <9385@star.cs.vu.nl> henk@cs.vu.nl (Henk Smit) writes: > How strange it seems, I can't see an obvious security > gap in "drwxrwxrwt" on /. I think the greatest danger is adding a new file to / that didn't exist before. Sure the .cshrc, .profile, and .login files might be there. But what about: .forward .emacs .rhosts .mailrc .kshrc .Xdefaults .suntools .logout .twmrc .history .sh_history .dbxinit .xinitrc .cm.rc .xrdb .rnmac .mailcf .textswrc .indent etc., etc., The problem is - how do you know which .mumble files have to be protected, and how do you know if you found them all. Some programs don't document the .mumble files they use, and some of these files might allow someone to break into a root account. I am not saying that every one of these files, if world writable, would allow someone to break intro a root account, but some definately could. I bet there are a dozen more I left out. Do you REALLY feel save because of a sticky bit? Not me. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
src@scuzzy.in-berlin.de (Heiko Blume) (03/22/91)
ric@optima.UUCP (Ric Anderson,GS-746,6214048,) writes: >The sticky bit is NOT (repeat NOT) implemented on all systems. If the >sticky bit is implemented CORRECTLY, then the worst I can do is create >a file in /, and make it grow till "/" fills up. This is good for a >crash on some systems :-) >However, if the sticky bit is unimplemented, or is implemented half >heartedly, then you can move files you own on top of files someone else >owns (even though you may not be able to rm files owned by others). i tried this on isc 2.2.1 as user src: # [ls] drwxrwxrwt 15 root root 880 Mar 22 00:44 /tmp -rw-r--r-- 1 root other 4 Mar 22 00:39 /tmp/test -rw-r--r-- 1 src src 5 Mar 22 00:39 /tmp/test2 # mv test2 test mv: test: 644 mode?y mv: cannot unlink . mv: permission denied so the sticky bit works (i tried cp test2 test, echo bla>>test etc too), but what does the 'mv: cannot unlink .' mean???? ain't got no clue... -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
jik@athena.mit.edu (Jonathan I. Kamens) (03/23/91)
In article <1991Mar22.000333.22597@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes: |> # [ls] |> drwxrwxrwt 15 root root 880 Mar 22 00:44 /tmp |> -rw-r--r-- 1 root other 4 Mar 22 00:39 /tmp/test |> -rw-r--r-- 1 src src 5 Mar 22 00:39 /tmp/test2 |> # mv test2 test |> mv: test: 644 mode?y |> mv: cannot unlink . |> mv: permission denied |> |> so the sticky bit works (i tried cp test2 test, echo bla>>test etc too), |> but what does the 'mv: cannot unlink .' mean???? ain't got no clue... My guess is that you're working on a system that does not have a rename system call, so mv works by unlinking the target name, if it exists, then creating a hard link from the old source name to the target name, then unlinking the old source name. Since /tmp/test is owned by root, mv can't unlink it. Although there appears to be a bug in your version of mv, because it tried to print the filename and failed. Probably a missing argument to fprintf or something. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
src@scuzzy.in-berlin.de (Heiko Blume) (03/24/91)
jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <1991Mar22.000333.22597@scuzzy.in-berlin.de>, src@scuzzy.in-berlin.de (Heiko Blume) writes: >|> # mv test2 test >|> mv: test: 644 mode?y >|> mv: cannot unlink . >|> mv: permission denied >|> >|> but what does the 'mv: cannot unlink .' mean???? ain't got no clue... > My guess is that you're working on a system that does not have a rename >system call, so mv works by unlinking the target name, if it exists, then >creating a hard link from the old source name to the target name, then >unlinking the old source name. ISC 2.2.1 does have rename(2) [btw: it even passed the POSIX compliance test suite (PCTS 1.0) of NIST], but who knows if mv uses it? > Since /tmp/test is owned by root, mv can't unlink it. sure, i just wondered why it said '.' instead of 'test'. > Although there appears to be a bug in your version of mv, because it tried >to print the filename and failed. Probably a missing argument to fprintf or >something. that's what i guess/hope now, too. wouldn't be too nice if it really tried to unlink(".") .... -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
jc@minya.UUCP (John Chambers) (03/26/91)
In article <9385@star.cs.vu.nl>, henk@cs.vu.nl (Henk Smit) writes: > The "t" (sticky bit) on directories means that you must not only have write > permission on the directory, but also be the owner of the file (or directory) > that you want to (re)move. > ... > How strange it seems, I can't see an obvious security > gap in "drwxrwxrwt" on /. Some time back, when I had a security related job (and eventually got fired for "breaking into" some of the computers on which they game me test accounts ;-), I found a root directory like this. I noticed that there was no /.profile, so I graciously provided one. Then I sat back and waited for root to run a Bourne-shell script. It didn't take long. One of the commands I included was: echo "Gotcha!" | mail root This caused some consternation, since of course it came from "root". There seem to be some shells around now that only read their .profile (or .login or .whatever) if it is owned by their real or effective user. This would have blocked my ruse, since of course /.profile was owned by my id, not root. But this is a sophistication that probably hasn't yet reached many vendors' shells. In general, there is a potential problem with missing files which may be created by users who understand how an application uses them. This can get subtle. For instance, many versions of Ingres look for files in the root directory (as well as in several other directories). You can have fun with your database users by creating these files for them if they don't exist. It's especially amusing to create them before the package is installed, with yourself as owner. When the package's users complain about your file messing up their package, you complain right back that you had the filename first, and they are just trying to harass you by coming along later and demanding that you change your filename because they want the name. Of course, they don't have the source to the package, and they can't change its behavior, so... -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc