Use-after-free in TUNSETIFF

DISCUSSION Wannes Rombouts 5 participants 5 messages Sep 11, 2013 1 message not in the archive

Subsystems (3)

Networking Network drivers TUN/TAP driver

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Wannes Rombouts

author

2013-09-11 00:00 UTC #1 lore raw

(I sent this email to [email protected] but they told me I should send it to you guys, so here you go.)

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

Stephen Hemminger

2013-09-11 00:33 UTC #2 lore raw

Quoted 58 lines · On Wed, 11 Sep 2013 01:59:47 +0200 Wannes Rombouts…

(I sent this email to [email protected] but they told me I should send it to you guys, so here you go.)
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.

Quoted 7 lines

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.

Thank you for the bug report.

I wouldn't go all security crazy, if you want to spend hours making an exploit have fun, but it is a waste of time[1]. It is a simple bug introduced in 3.8

commit c8d68e6be1c3b242f1c598595830890b65cea64a

Author: Jason Wang <[email protected]>
Date:   Wed Oct 31 19:46:00 2012 +0000

tuntap: multiqueue support

The fix isn't that hard, why don't you make a patch.

[1] A user with CAP_NET_ADMIN can basically hose the system many other ways. Capabilities are a failed security model.
Almost all distro's limit CAP_NET_ADMIN to root anyway.

Ben Hutchings

2013-09-11 14:44 UTC #3 lore raw

On Tue, 2013-09-10 at 17:32 -0700, Stephen Hemminger wrote:
[...]

Quoted 3 lines

[1] A user with CAP_NET_ADMIN can basically hose the system many other ways. Capabilities are a failed security model.
Almost all distro's limit CAP_NET_ADMIN to root anyway.

tun uses ns_capable(), not capable(). If user namespaces are enabled then I think any user can create their own user & net namespaces, be 'root' in those namespaces and then invoke TUNSETIFF successfully.

Ben.

Signature · 3 lines

Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Michael S. Tsirkin

2013-09-11 04:42 UTC #4 lore raw

In reply to Wannes Rombouts

Quoted 62 lines · Wannes Rombouts

(I sent this email to [email protected] but they told me I should send it to you guys, so here you go.)
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.

Quoted 11 lines

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

Thanks a lot for the report. So this one is easy to fix I think. Does the below patch help?
However, looking at the error handling in that function, it looks like it could leak resources in many other ways. We probably need more patches on top to fix it properly.

-->

tun: cleanup flow on set_iff error path

Signed-off-by Michael S. Tsirkin <[email protected]>

---

drivers/net/tun.c +5 -3

index b7c457a..c0470c1 100644
@@ -1660,11 +1660,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
 		INIT_LIST_HEAD(&tun->disabled);
 		err = tun_attach(tun, file);
 		if (err < 0)
-			goto err_free_dev;
+			goto err_free_flow;
 
 		err = register_netdevice(tun->dev);
 		if (err < 0)
-			goto err_free_dev;
+			goto err_free_flow;
 
 		if (device_create_file(&tun->dev->dev, &dev_attr_tun_flags) ||
 		    device_create_file(&tun->dev->dev, &dev_attr_owner) ||

@@ -1708,7 +1708,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
 	strcpy(ifr->ifr_name, tun->dev->name);
 	return 0;
 
- err_free_dev:
+err_free_flow:
+	tun_flow_uninit(dev);
+err_free_dev:
 	free_netdev(dev);
 	return err;
 }

Jason Wang

2013-09-11 04:45 UTC #5 lore raw

----- Original Message -----

Quoted 75 lines · Wannes Rombouts

Quoted 62 lines
(I sent this email to [email protected] but they told me I should send it to you guys, so here you go.)
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.
Quoted 11 lines
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

Quoted 6 lines

Thanks a lot for the report. So this one is easy to fix I think. Does the below patch help?
However, looking at the error handling in that function, it looks like it could leak resources in many other ways. We probably need more patches on top to fix it properly.

True, I'm working on a patch to solve all of them. Will post soon