Hi, your question is interresting, I've a good response for you I'm speeking on the linux kernel, on a X86 box, but could be usable in most archs. The chroot limitations breaks you only the accesses to the local filesystem. In most cases, you don't have an access to /proc ,/dev/*, nor to /bin/sh. But If you are able to run code as root, a few syscalls are still available to you : inserting modules and ptrace(). Both can be used to own the entire system, I coded two weeks ago a shellcode which uses ptrace to get out of the chroot, tracing his ppid (usualy inetd in the case of a chrooted ftp server), inserting a shellcode and leaving. The case of inserting modules is more complex. You have to do a lkm who breaks the chroot only for your own process, and of course you must insmod it. It used to have a wuftpd exploit who did compile staticaly insmod, compiled a such lkm and uploaded them on the remote ftp. Of course, lkm support have to be enabled. I think I responded to your question .. On Wed, 22 May 2002 15:48:16 +1200 Jason Haar <Jason.Haarat_private> wrote: > [note: my question is WRT non-root chrooted jails - we all know about > chroot'ing root processes!] > > Most buffer overflows I've seen attempt to infiltrate the system enough to > run /bin/sh. In chroot'ed environments, /bin/sh doesn't (shouldn't!) exist - > so they fail. > > Is it as simple as that? As 99.999% of the system binaries aren't available > in the jail, can a buffer overflow ever work? > > -- > Cheers > > Jason Haar > > Information Security Manager > Trimble Navigation Ltd. > Phone: +64 3 9635 377 Fax: +64 3 9635 417
This archive was generated by hypermail 2b30 : Wed May 22 2002 - 09:41:35 PDT