lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 25 Sep 2007 11:53:41 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Miloslav Semler <majkls@...pere.com>
Cc:	Jan Engelhardt <jengelh@...putergmbh.de>, serge@...lyn.com,
	davidsen@....com, philipp@...ek.priv.at, 7eggert@....de,
	alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: Chroot bug

Quoting Miloslav Semler (majkls@...pere.com):
>
>>>> So what? Just do this: chdir into the root after chroot.
>>>>       
>>> I don't think so.  His exploit just got me all the way out of a chroot 
>>> within a
>>> chroot within a chroot, inclusive of lots of chdirs.
>>>     
>>
>> Close all fds that point to directories outside the root ;-)
>>
>>   
> This  does not help.  Let's try:
> chroot somewhere
> mkdir foo
> fd = open /
> chroot foo
> fchdir fd
> chdir ".."
> ....
> chdir ".."
> chroot "."
> so you are in root.
>

Yes, to understand why that doesn't work it helps to understand why
pivot_root *does* work.  Pivot_root takes the new_root, which must be
a mount, and detaches it from it's mountpoint.  So it's not that we
try to intercept a chdir(root_dir/..), but rather we remove root_dir
from it's parent dir so that root_dir/.. must always return root_dir.

I'm sorry but I really don't see where hacking chroot to try and
detect and prevent chroot escapes is going to be acceptable to
anyone so long as pivot_root does the trick anyway.  If you want
portable, then write a little linux-only safe_chroot() library call
which does unshare();pivot_root() on linux and just chroot on a
system that does try to stop chroot escapes.

Besides as others have alluded to, if you have root privs, you can
always mknod /dev/hda1, mount that under /mnt, and then chroot or
pivot_root to there.

The containers work will, in fact, be intended to be a *safe*
jail.  That'll happen through pivot_root, capability masking,
perhaps device namespaces, etc.  But a secure container is still
a ways off.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ