Date: Thu, 12 Sep 2013 12:04:02 +0200 From: Petr Matousek <pmatouse@...hat.com> To: oss-security@...ts.openwall.com Cc: Kees Cook <keescook@...omium.org>, linux-distros@...openwall.org, Kurt Seifried <kseifrie@...hat.com>, Michael Tsirkin <mtsirkin@...hat.com>, Jason Wang <jasowang@...hat.com> Subject: Fwd: Use-after-free in TUNSETIFF 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@...hat.com> ----- Date: Thu, 12 Sep 2013 09:39:08 +0200 To: Kees Cook <keescook@...omium.org> From: Petr Matousek <pmatouse@...hat.com> Subject: Re: [vs-plain] Fwd: Use-after-free in TUNSETIFF CC: linux-distros@...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@...ux-foundation.org> > Date: Tue, Sep 10, 2013 at 4:42 PM > Subject: Re: Use-after-free in TUNSETIFF > To: Wannes Rombouts <wannes.rombouts@...tech.eu> > Cc: security@...nel.org, Kevin Soules <kevin.soules@...tech.eu>, David > Miller <davem@...emloft.net>, Maxim Krasnyansky > <maxk@....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@...tech.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ