[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20130912100402.GO11152@dhcp-25-225.brq.redhat.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
