Bugzilla – Bug 839965
VUL-1: CVE-2013-4343: kernel: use-after-free in TUNSETIFF
Last modified: 2016-04-27 19:07:42 UTC
Public via Linux Network Development list. http://www.spinics.net/lists/netdev/msg250066.html -------- 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
CVE-2013-4343 was assigned for this issue.
bugbot adjusting priority
http://www.spinics.net/lists/netdev/msg250068.html apparently introduced in Linux 3.8, so SLE11 and older are likely not affected.
(In reply to Marcus Meissner from comment #3) I'm going through old bugs. Can you please check that SLE 12 is not affected?
this seems to be the fix: commit 662ca437e714caaab855b12415d6ffd815985bc0 Author: Jason Wang <jasowang@redhat.com> Date: Wed Sep 11 18:09:48 2013 +0800 tuntap: correctly handle error in tun_set_iff() Commit c8d68e6be1c3b242f1c598595830890b65cea64a (tuntap: multiqueue support) only call free_netdev() on error in tun_set_iff(). This causes several issues: - memory of tun security were leaked - use after free since the flow gc timer was not deleted and the tfile were not detached This patch solves the above issues. Reported-by: Wannes Rombouts <wannes.rombouts@epitech.eu> Cc: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
was fixed before 3.12, so SLE12 is also not affected.