[1524] in linux-security and linux-alert archive
[linux-security] Re: Buffer Overflows: A Summary
daemon@ATHENA.MIT.EDU (Martin Pool)
Sat May 3 03:41:20 1997
Date: 3 May 1997 03:28:49 -0000
From: Martin Pool <m.pool@pharos.com.au>
To: linux-security@redhat.com
In-reply-to: <199705021733.MAA06939@enteract.com> (tqbf@ENTERACT.COM)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
-----BEGIN PGP SIGNED MESSAGE-----
> Date: Fri, 2 May 1997 12:33:00 -0500
> From: "Thomas H. Ptacek" <tqbf@ENTERACT.COM>
> On almost all Unix operating systems, having superuser access in a
> chroot() jail is still dangerous. In some recent revisions of 4.4BSD
> operating systems, root can trivially escape chroot(), as well.
I was thinking about possible attacks of this nature last night. For
example, suppose somebody gets root inside a chroot'd jail. Then
- the attacker can use a device file to access other parts of the
physical disk
+ but the admin has ensured there are no device files in the jail
- but the attacker can create one using mknod
+ but the sysadmin has mounted the partition containing the jail
with the nodev option
- but the attacker can create and mount a loopback filesystem inside
the jail allowing devices to be created
and I have no real solution to this, other than, of course, making
sure that nobody _does_ get into the machine, even inside a chroot
jail. I think a well-thought-out 'ratchet' security-level system is
needed.
Yours,
- --
Martin Pool, Pharos Business Solutions <m.pool@pharos.com.au>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: http://www.pharos.com.au/mbp/public_key.txt
iQB1AwUBM2qwojr8By6pblTZAQF6igMAjHBF9JIr82Dpb6COfV0Cs0YST/xFEoA1
kFVog0ifUbR0/wXOyo159ItqqYxRhSq7Kz+abtA2tlogAQwUWsmdEWdQp5ALgCTR
gcaZi/+TX/SCGB1OqkkdIKYBGprTheBl
=4Dxi
-----END PGP SIGNATURE-----
[mod: There was a discussion between the (ex-) Linux-security
moderators, Linus and a few others quite a while ago. The conclusion
was that there were enough unpluggable holes in a chrooted environment
that it didn't pay to try to make it root-safe. If you want to find
more of these holes, just look for the "suser()" call in your
kernel sources, and try to think of a way to exploit that to get
out of the "jail". A jail is not root-proof. Make it such that you
cannot break root from a normat uid. i.e. all of the above + no
setuid programs at all.... -- REW]
