| |||||||||||||
The Savannah Compromise - what really happened?The Savannah Compromise - what really happened?Posted Jan 1, 2004 19:55 UTC (Thu) by rao (subscriber, #78)Parent article: The Savannah Compromise - what really happened? The Savannah codebase and infrastructure was audited after the compromise to find potential security holes that the cracker could have used. CVS 1.12.5 and 1.11.11 were released on 2003-12-18 as a direct result of that work. Futher details on CVS will be released in the coming days. Services are being brought back up on Savannah as they are secured. For instance, under the new Savannah setup, each software project's CVS repository resides in its own chroot, and other essential system services also reside in their own chroots. The FSF and Savannah volunteers have taken this compromise very seriously, and we've taken steps to limit the damage from any future compromises. Paul Fisher
(Log in to post comments)
The Savannah Compromise - what really happened? Posted Jan 1, 2004 20:17 UTC (Thu) by miah (subscriber, #639) [Link] What has been done to ensure its not possible for future attackers from breaking out of the chroot? Have you looked into propolice(ssp), grsecurity, some sort of mac/acl system?
The Savannah Compromise - what really happened? Posted Jan 2, 2004 0:16 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] chroot jails are useless against an attacker who manages to get root from within the jail, so if a local root exploit exists, chroot is no help.
The Savannah Compromise - what really happened? Posted Jan 2, 2004 4:53 UTC (Fri) by jonabbey (subscriber, #2736) [Link] Can you explain that? How does one get out of a chroot jail, even with root?
The Savannah Compromise - what really happened? Posted Jan 2, 2004 5:20 UTC (Fri) by spotter (subscriber, #12199) [Link] what does root mean? it means that when you do a ".." it goes to "." instead of the parent directory.now imagine you are able to call chroot, you can change your "root" to a directory below you. now, any directory you are in is not the root, so ".." will go to the parent of that directory instead of going to "." and therefore you have broken out of the chroot. I've looked at 2 simple ways around this. 1) every process should have a list of chroot/root points (instead of just one) and whene ever you hit one o those points ".."->"." I broached this idea to the l-k list a year or 2 ago, but people weren't really interested. probably have my code for it lying around somewhere. or 2) have a filesystem that is aware of chroots, and doesn't let a process walk past any chroot point. since file system's don't know about chroot(), would also need to wrap the chroot() syscall in code that set up the appropriate data structures for the fs. this works because even though ".." links to the parent directory, if the filesystem's permission() function prevents any process (even roots) from walking past a directory, the process is effectively chained in. somewhat of a hack, but it works fine, have code that implements this too.
The Savannah Compromise - what really happened? Posted Jan 2, 2004 8:07 UTC (Fri) by eru (subscriber, #2753) [Link] How does FreeBSD:s jail(2) do it? I suppose it fixed the chroot escaping problem.
The Savannah Compromise - what really happened? Posted Jan 2, 2004 16:03 UTC (Fri) by eru (subscriber, #2753) [Link] Suppose you just changed the kernel to disable the chroot call for every process (even ones with uid 0) whose current root directory differs from the real root? Would that cause problems to any legitimate applications?
The Savannah Compromise - what really happened? Posted Jan 4, 2004 6:43 UTC (Sun) by Ross (subscriber, #4065) [Link] What I wished for was that chroot() would be considered a capability andthat it could be disabled. In fact, capabilities in Linux aren't very useful because they can only restrict actions that are already reserved for the superuser. So I can't, for example, say that this process and its children can't call ptrace(), chroot(), etc.
The Savannah Compromise - what really happened? Posted Jan 15, 2004 11:51 UTC (Thu) by edmundo (guest, #616) [Link] Would it help for chroot to take no argument and only chroot to the current directory?
The Savannah Compromise - what really happened? Posted Jan 2, 2004 5:24 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] if you are root inside a chroot jail and the chroot has access to /proc, or anything in the chroot has access to file handles pointing outside the jail, or the system will honor raw access to a device from within that jail then the attacker has a way out of the jail.the biggest problem is that even if you don't put any software in the chroot the attacker can install their own so they can then issue the mount command (along with the correct device info) to the kernel and the kernel will allow the access becouse you are root. useing chroot can't prevent an attacker from getting into a system, but it is one more thing that they need to deal with to really get control of the system (and the more you strip down the chroot sandbox the more work it takes to break out and the less vunerable you are to automated attacks)
The Savannah Compromise - what really happened? Posted Jan 4, 2004 6:45 UTC (Sun) by Ross (subscriber, #4065) [Link] You are assuming the chroot() area is writable and that the compromizedprocess is running as root (non-root can not call mount(2)).
Breaking out of a chroot jail Posted Jan 2, 2004 15:36 UTC (Fri) by LogicG8 (guest, #11076) [Link] I just happened to be reading about thisso I have a really good url handy. http://www.bpfh.net/simes/computing/chroot-break.html
The Savannah Compromise - what really happened? Posted Jan 3, 2004 2:13 UTC (Sat) by iabervon (subscriber, #722) [Link] On the other hand, it'd be very difficult to get root in the jail ifthere's nothing setuid root or running as root in the jail. Anything kernel-level that will give you root in this situation would probably let you do arbitrary other things anyway, and anything userspace can't give you root. Tasks requiring root access can be done from outside the jail, so in-jail root doesn't actually need to be possible at all, which makes security auditting much simpler, because you can be sure that permissions will be followed by everything in the jail.
The Savannah Compromise - what really happened? Posted Jan 4, 2004 6:47 UTC (Sun) by Ross (subscriber, #4065) [Link] Yes, exactly. But one must be careful that anything running outside thechroot()ed area treats anything that is writable in the chroot()ed area as untrusted. This means being very careful opening files and validating inputs (it's a lot like handling /tmp correctly... i.e. almost impossible).
The Savannah Compromise - what really happened? Posted Jan 6, 2004 0:46 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] But we are talking about actions taken in response to the Debian and Savannah compromises. Given a kernel bug that allows a cleverly written program to get root, if you can execute a program from within the jail and such a flaw exists, you get a get-out-of-jail-free card. Another such bug was just discovered. So, I repeat: chroot jails are useless if a kernel bug provides a root exploit.
The Savannah Compromise - what really happened? Posted Jan 8, 2004 23:06 UTC (Thu) by Ross (subscriber, #4065) [Link] Oh, yes, I completely agree in that case. But people weren't careful tolimit their arguments to that case. In fact, with a root-exploitable kernel bug any attacker that can run arbitrary code can access the whole system, no matter what user they run the code as or what type of jail the code is put into. In short, having a secure kernel is a requirement for any other security on the system so long as untrusted users have access to run code.
|
|||||||||||||