drw@fibonacci.math.mit.edu (Dale R. Worley) (10/26/89)
As quoted from <15018@bloom-beacon.MIT.EDU> by drw@math.mit.edu (Dale R. Worley): +--------------- | I may be naieve, but I would think that between running sh from a | non-root account, and use of chroot(), one would be able to confine | the damage from a dangerous archive to just one part of the directory | tree. Why doesn't this work? +--------------- To break security with chroot(): 1. Invoke whatever setuid root thingy establishes the directory that it will chroot into. 2. Have your shar script sleep a good long while at the beginning. 3. While it's sleeping, in another shell, cd to that fake root directory. "ln /bin/su ./bin/su" to install su in the fake /bin directory. Also, "cat ~/xyz ./etc/passwd" to install a fake /etc/passwd file, one whose root password you know. 4. Now your script wakes up, "su root"s with the password you know, and "chmod u+s /bin/sh". Then it sleeps a while longer. 5. In the other shell, "mv ./bin/sh ~". Voila! Sigh, Dale drw@math.mit.edu
sean@ms.uky.edu (Sean Casey) (10/26/89)
drw@fibonacci.math.mit.edu (Dale R. Worley) writes: |1. Invoke whatever setuid root thingy establishes the directory that |it will chroot into. |2. Have your shar script sleep a good long while at the beginning. |3. While it's sleeping, in another shell, cd to that fake root |directory. "ln /bin/su ./bin/su" to install su in the fake /bin |directory. Also, "cat ~/xyz ./etc/passwd" to install a fake |/etc/passwd file, one whose root password you know. You've already lost on step 3, because you made a false assumption about step 1. Step 1 would do the chroot *before* any lines of the shell archive get executed. The ln /bin/su ./bin/su would fail because after the chroot there is no /bin/su to be found. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** ``So if you weight long enough, you'll get your packets, right?''
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/26/89)
In article <DRW.89Oct25234218@fibonacci.math.mit.edu>, drw@fibonacci.math.mit.edu (Dale R. Worley) writes: | 3. While it's sleeping, in another shell, cd to that fake root | directory. "ln /bin/su ./bin/su" to install su in the fake /bin | directory. Also, "cat ~/xyz ./etc/passwd" to install a fake | /etc/passwd file, one whose root password you know. In *what* other shell? This is a shar file, right? There is no other shell to startup, and if you start one shar the shar file it, too, is running under the chroot. This would barely work if someone was on the same machine trying to break security (assuming that the chroot was to an insecure directory). The technique doesn't work from a shar file, because you can't get out of the chroot to link in all the stuff you want (mainly su). -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
jfh@rpp386.cactus.org (John F. Haugh II) (10/27/89)
In article <DRW.89Oct25234218@fibonacci.math.mit.edu> drw@fibonacci.math.mit.edu (Dale R. Worley) writes: >To break security with chroot(): > [ And then gives several steps for breaking into a chroot()'d tree. ] If you can do all of that then you can just slide right in without even needing a shell script. The permission restrictions on ~/, ~/bin, and ~/etc are NO LESS SERIOUS than on the real /, /bin, and /etc. >Voila! Not quite so easy as you claim. >Sigh, Yes, Sigh. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of EMACS is ... InterNet: jfh@rpp386.cactus.org | ... EMACS makes a computer slow. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--<><---
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/28/89)
In article <1491@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <DRW.89Oct25234218@fibonacci.math.mit.edu>, drw@fibonacci.math.mit.edu (Dale R. Worley) writes: > >| 3. While it's sleeping, in another shell, cd to that fake root >| directory. "ln /bin/su ./bin/su" to install su in the fake /bin >| directory. Also, "cat ~/xyz ./etc/passwd" to install a fake >| /etc/passwd file, one whose root password you know. > > In *what* other shell? In the shell you're running from the terminal beside you, or another xterm, or a different window under screen, or ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA The Connector is the Notwork.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/28/89)
In article <13053@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) writes: | You've already lost on step 3, because you made a false assumption about | step 1. Well, he loses, but not just that way. The scenario assumes that (a) you allow sleep, and (b) that the user can write the directory. The program I use unshars into a protected directory (r/w root only), and after the unshar it scans the directory for any writable directories or setuid programs. If the unshar has not created anything evil it uses the 'p' option of cpio to copy the new stuff back to the users directory, where it will be owned by the user. And yes I have a lockfile to prevent two unshars at once. I'm not paranoid, I'm *very* paranoid. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
pwolfe@kailand.kai.com (10/28/89)
> To break security with chroot(): > > 3. While it's sleeping, in another shell, cd to that fake root > directory. "ln /bin/su ./bin/su" to install su in the fake /bin > directory. Also, "cat ~/xyz ./etc/passwd" to install a fake > /etc/passwd file, one whose root password you know. > > Dale drw@math.mit.edu To re-inforce security with chroot, place the same protections in the chroot file system that you would in the real file system. System files are owned and writable only by root. Your method of breaking chroot works only if someone has an account in both the real and chroot file systems, and can copy files between the two. If users have access to the root account or password file in the chroot filesystem, then, yes, they can gain access to the root (or any other) account in the real filesystem. I have built a "chroot" file system that I would defy you to break out of. We use it to provide guest accounts (for email and games) to employee's family members. Nobody who has an account in this file system has an account in the real one, and visa versa. It is a partial clone of the real file system (/dev, /etc, /usr, /bin), containing only the files and programs that are neccessary for it's operation. It resides in it's own 7 Mb partition, so guests can't fill up any real user partitions. The person you responded to only wanted to make sure the shar that comes from offsite doesn't do anything destructive. I think using chroot is going a little overboard. One safer (and easier) method would be to write a program to interpret the shar file, executing only commands you deem neccessary (if, wc, cat, sed, etc). Shouldn't be too hard, in fact aren't such things already available? Patrick Wolfe (pat@kai.com, kailand!pat) System Manager, Kuck & Associates, Inc.