| 2017-01-06 23:00:48 |
Jann Horn (corp account) |
description |
The documentation for lxc-user-nic claims:
It ensures that the calling
user is privileged over the network namespace to which the interface
will be attached.
Actually, the code only verifies that a process of the calling user is running in the network namespace to which the interface will be attached. To verify this:
- As root, create a new bridge "lxcbr0".
- As root, add an entry like "user veth lxcbr0 10" to /etc/lxc/lxc-usernet.
- As the user specified in /etc/lxc/lxc-usernet, run the following command:
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic foo bar $$ veth lxcbr0 foobar
- Run "ip link show foobar". The output shows that a network interface with the
name "foobar" was created in the init namespace (in which the user is not
privileged).
I suspect that it would also be possible to trick lxc-user-nic into operating on namespaces the caller can't access by reassigning the PID while lxc-user-nic is running, between the access check and the netlink calls - this is probably quite hard to fix, considering that the netlink interface just uses a PID to identify the target namespace.
I haven't found any way to actually exploit this; however, it seems interesting that this can e.g. be used to create network interfaces whose names contain special characters like dollar, semicolon and backtick. I'm not sure how dangerous that is - I'm reporting it as a security bug for now, but if you feel that this has no security impact, feel free to derestrict it.
One way to fix this might be to temporarily drop privileges (setresuid(ruid, ruid, 0)) in rename_in_ns() after the first setns() call. This way, the renaming could only succeed if the caller is actually privileged in the network namespace.
release: Ubuntu 16.10
version: lxc-common: 2.0.6-0ubuntu1~ubuntu16.10.1 |
The documentation for lxc-user-nic claims:
It ensures that the calling
user is privileged over the network namespace to which the interface
will be attached.
Actually, the code only verifies that a process of the calling user is running in the network namespace to which the interface will be attached. To verify this:
- As root, create a new bridge "lxcbr0".
- As root, add an entry like "user veth lxcbr0 10" to
/etc/lxc/lxc-usernet.
- As the user specified in /etc/lxc/lxc-usernet, run the following
command:
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic a b $$ veth lxcbr0 foobar
- Run "ip link show foobar". The output shows that a network interface
with the name "foobar" was created in the init namespace (in which the
user is not privileged).
I suspect that it would also be possible to trick lxc-user-nic into operating on namespaces the caller can't access by reassigning the PID while lxc-user-nic is running, between the access check and the netlink calls - this is probably quite hard to fix, considering that the netlink interface just uses a PID to identify the target namespace.
I haven't found any way to actually exploit this; however, it seems interesting that this can e.g. be used to create network interfaces whose names contain special characters like dollar, semicolon and backtick. I'm not sure how dangerous that is - I'm reporting it as a security bug for now, but if you feel that this has no security impact, feel free to derestrict it.
One way to fix this might be to temporarily drop privileges (setresuid(ruid, ruid, 0)) in rename_in_ns() after the first setns() call. This way, the renaming could only succeed if the caller is actually privileged in the network namespace.
release: Ubuntu 16.10
version: lxc-common: 2.0.6-0ubuntu1~ubuntu16.10.1 |
|
