Fwd: Use-after-free in TUNSETIFF

[Petr Matousek <pmatouse () redhat com>]

Upon agreement Kurt assigned CVE and was supposed to forward the message
below to oss-sec. Didn't arrive yet, so forwarding too.

The CVE for this issue is CVE-2013-4343.

Thanks,
Petr

----- Forwarded message from Petr Matousek <pmatouse () redhat com> -----

Date: Thu, 12 Sep 2013 09:39:08 +0200
To: Kees Cook <keescook () chromium org>
From: Petr Matousek <pmatouse () redhat com>
Subject: Re: [vs-plain] Fwd: Use-after-free in TUNSETIFF
CC: linux-distros () vs openwall org

On Wed, Sep 11, 2013 at 01:28:57PM -0700, Kees Cook wrote:
> CAP_NET_ADMIN to ring-0 use-after-free. This may end up getting taken
> public to the netdev list, but here's a heads-up anyway.

This is public already --
http://www.spinics.net/lists/netdev/msg250066.html.

Patch is at http://permalink.gmane.org/gmane.linux.kernel/1559873.

I'm going to request CVE on oss-sec shortly.

Petr

> -Kees
>
> ---------- Forwarded message ----------
> From: Andrew Morton <akpm () linux-foundation org>
> Date: Tue, Sep 10, 2013 at 4:42 PM
> Subject: Re: Use-after-free in TUNSETIFF
> To: Wannes Rombouts <wannes.rombouts () epitech eu>
> Cc: security () kernel org, Kevin Soules <kevin.soules () epitech eu>, David
> Miller <davem () davemloft net>, Maxim Krasnyansky
> <maxk () qti qualcomm com>
>
>
> (cc's added)
>
> (tun_set_iff->tun_flow_init leaves a timer running after tun_set_iff()
> failure)
>
> On Wed, 11 Sep 2013 01:35:39 +0200 Wannes Rombouts
> <wannes.rombouts () epitech eu> wrote:
>
> > Hi,
> >
> > I would like to report what I believe could be a potential CAP_NET_ADMIN
> > to ring0 privilege escalation.
> >
> > The bug is in the way tuntap interfaces are initialized, when given an
> > invalid name they cause a use after free. Also software like vmware
> > allows for at least a freeze or kernel panic by a simple user but might
> > also allow privilege escalation.
> >
> > Very simple to test, this causes a crash:
> > # ip tuntap add dev %% mode tap
> > If it doesn't crash immediately wait a few seconds and try again.
> >
> >
> > We haven't managed to exploit the use after free yet, but we are still
> > working on it. At least it crashes even with the latest kernel 3.11 and
> > on different distros. (tested on Debian, Ubuntu and Arch) Looking at the
> > source the bug seems quite old.
> >
> >
> > Here is our analysis:
> >
> > A user with CAP_NET_ADMIN calls ioctl with TUNSETIFF and an invalid name
> > for example "%d%d".
> >
> > tun_set_iff starts to initialize the tun_struct.
> > http://lxr.free-electrons.com/source/drivers/net/tun.c#L1589
> >
> > It calls tun_flow_init which starts a timer with tun_flow_cleanup as
> > callback. http://lxr.free-electrons.com/source/drivers/net/tun.c#L852
> >
> > After this tun_set_iff calls register_netdevice which returns an error
> > because of the invalid name.
> >
> > This error causes the goto err_free_dev and the call to free_netdev.
> > This will free the tun_struct.
> >
> > Later, once the callback gets called it uses bad memory. Sometimes it
> > doesn___t get called because the timer_list has been compromised and we
> > get a kernel panic at:
> > http://lxr.free-electrons.com/source/kernel/timer.c?v=2.6.33#L949
> >
> > But it is possible to get some memory from userland that overlaps only
> > the beginning of the tun_struct without overwriting the timer_list
> > because there is a big array before it. Then it might be possible to
> > exploit tun_flow_cleanup when it is called, but we didn't succeed yet.
> >
> > ------------------------------------------------------------------------
> >
> >
> > This is the first time we try to exploit the kernel so we basically suck
> > at this. I don't know if someone more skilled could do this easily or
> > not, but we'll keep trying and I'll let you know if we manage it.
> >
> > In the mean time please let us know what you think of this and of course
> > we are very interested in the way this is patched. Please keep us in the
> > loop.
> >
> > Of course we will be happy to assist in any way we can, feel free to
> > ask! Also we would like to know when you think it would be reasonable to
> > disclose and talk about this bug.
> >
> > Regards,
> >
> > Wannes 'wapiflapi' Rombouts
> > Kevin 'eax64' Soules
>
> -- 
> Kees Cook
> Chrome OS Security


-- 
Petr Matousek / Red Hat Security Response Team


----- End forwarded message -----

-- 
Petr Matousek / Red Hat Security Response Team