Hi Al and Marcelo,
while I was trying to get maximum restrictions on a chroot on 2.4.21-pre,
I found that it's always possible to mount a ramfs or a tmpfs on "..",
and then upload whatever I wanted in it. It's a shame because I was
trying to isolate network daemons inside empty, read-only file-systems,
and I discovered that this effort was worthless. To resume, imagine a
network daemon which does :
chroot("/var/empty") (read-only directory or file-system)
chdir("/")
listen(), accept(), fork(), whatever...
-> external code injection from a cracker :
mount("none", "..", "ramfs")
mkdir("../mydir")
chdir("../mydir")
the cracker now installs whatever he wants here.
The worst is that the new directory can even become invisible from all
other processes, so that the intruder has nothing to fear :-(
So I read fs/namei.c and fs/namespace.c, and found a way to prevent
this. Basically, the only case where it's still possible to mount
something on the current->fs->root now, is when the process wants to
remount the root fs, but no other mounts are allowed.
Since I'm really clueless about VFS code, I might have done it wrong,
or broken something, so I post this patch for comments. If everyone
agrees, I would really appreciate it if it was accepted in mainstream,
because it's a security problem IMHO.
It still applies to 2.5.66 with offset BTW.
Cheers,
Willy
--- linux-2.4.22-pre2/fs/namespace.c Sat May 10 11:36:02 2003
+++ linux-2.4.22-pre2-dotdot-mount/fs/namespace.c Sun Jun 29 14:38:16 2003
@@ -732,6 +732,10 @@
if (flags & MS_REMOUNT)
retval = do_remount(&nd, flags & ~MS_REMOUNT, mnt_flags,
data_page);
+ else if (nd.dentry == current->fs->root &&
+ nd.mnt == current->fs->rootmnt)
+ /* prevents someone from mounting on . or .. */
+ retval = -EINVAL;
else if (flags & MS_BIND)
retval = do_loopback(&nd, dev_name, flags & MS_REC);
else if (flags & MS_MOVE)
On Sun, 2003-06-29 at 15:09, Willy TARREAU wrote:
> Hi Al and Marcelo,
>
> while I was trying to get maximum restrictions on a chroot on 2.4.21-pre,
> I found that it's always possible to mount a ramfs or a tmpfs on "..",
> and then upload whatever I wanted in it. It's a shame because I was
> trying to isolate network daemons inside empty, read-only file-systems,
> and I discovered that this effort was worthless. To resume, imagine a
> network daemon which does :
well...
you need to be root to mount. If you're root you can break out of a
chroot anyway....
On Sun, Jun 29, 2003 at 03:09:52PM +0200, Willy TARREAU wrote:
> chroot("/var/empty") (read-only directory or file-system)
> chdir("/")
> listen(), accept(), fork(), whatever...
> -> external code injection from a cracker :
> mount("none", "..", "ramfs")
> mkdir("../mydir")
> chdir("../mydir")
> the cracker now installs whatever he wants here.
That's a BS. Same effect would be achieved by replacing ".." with ".".
Or mounting on any existing subdirectory.
If attacker can mount of chroot - you've LOST. Already. End of story.
On Sun, Jun 29, 2003 at 03:11:03PM +0100, [email protected] wrote:
> On Sun, Jun 29, 2003 at 03:09:52PM +0200, Willy TARREAU wrote:
> > chroot("/var/empty") (read-only directory or file-system)
> > chdir("/")
> > listen(), accept(), fork(), whatever...
> > -> external code injection from a cracker :
> > mount("none", "..", "ramfs")
> > mkdir("../mydir")
> > chdir("../mydir")
> > the cracker now installs whatever he wants here.
>
> That's a BS. Same effect would be achieved by replacing ".." with ".".
> Or mounting on any existing subdirectory.
No, it works only with "..", and not with "." ! I don't know why, I believe
it's because the process is still attached to the old FS when mounting on ".".
> If attacker can mount of chroot - you've LOST. Already. End of story.
To me, it seems this is the *only* remaining case in an *empty* read-only
directory. The fact is that the attacker needs at least a mount point to mount
something. Not providing him one is efficient, but here he can only exploit
"..".
Please reconsider the question, Al, because I really think that with this, we
can get reliable jails for network daemons which don't need file access at all.
Cheers,
Willy
On Sun, Jun 29, 2003 at 04:09:40PM +0200, Arjan van de Ven wrote:
> On Sun, 2003-06-29 at 15:09, Willy TARREAU wrote:
> > Hi Al and Marcelo,
> >
> > while I was trying to get maximum restrictions on a chroot on 2.4.21-pre,
> > I found that it's always possible to mount a ramfs or a tmpfs on "..",
> > and then upload whatever I wanted in it. It's a shame because I was
> > trying to isolate network daemons inside empty, read-only file-systems,
> > and I discovered that this effort was worthless. To resume, imagine a
> > network daemon which does :
>
> well...
> you need to be root to mount. If you're root you can break out of a
> chroot anyway....
not in all cases. for the classical "mkdir a; chroot a; chdir ..", you need a
writable directory to create "a" or an existing directory somewhere to serve
as a mount point. If neither of them is true, I don't see other means of
escaping the chroot. And here, ".." is the only one I could exploit, that's why
I proposed this patch which closes what is, to me, the only weakness in this
very particular case.
Cheers,
Willy
On Sun, Jun 29, 2003 at 04:20:47PM +0200, Willy TARREAU wrote:
> No, it works only with "..", and not with "." ! I don't know why, I believe
> it's because the process is still attached to the old FS when mounting on ".".
So? chdir around and you'll get to the covering directory.
> > If attacker can mount of chroot - you've LOST. Already. End of story.
>
> To me, it seems this is the *only* remaining case in an *empty* read-only
> directory. The fact is that the attacker needs at least a mount point to mount
> something. Not providing him one is efficient, but here he can only exploit
> "..".
>
> Please reconsider the question, Al, because I really think that with this, we
> can get reliable jails for network daemons which don't need file access at all.
Sigh... We _can't_ do that via chroot(). Please, stop fooling yourself -
if attacker gets control over root process, the fight is over. In particular,
attacker can chmod your read-only directory and/or remount the thing.
On Sun, Jun 29, 2003 at 03:27:25PM +0100, [email protected] wrote:
> Sigh... We _can't_ do that via chroot(). Please, stop fooling yourself -
> if attacker gets control over root process, the fight is over. In particular,
> attacker can chmod your read-only directory and/or remount the thing.
not if the file-system is read-only by design (eg: romfs or anything like that)
or a read-only directory in /proc. To be honnest, I have another patch which
allows any process to chroot to /proc/self/empty. I know that it's not good
when the root is compromized. The attacker could do other things and even halt
the system. That's not what I'm trying to fight against. I'm only trying to
stop proliferation, and isolate the attacker into a place where the only tools
he can use are the ones he codes himself on the heap or stack, which is rather
limitating.
Cheers,
Willy