OpenWRT: swconfig infrastructure fails to check permissions Jun 10 2016 08:23PM
Elliott Mitchell ehem+bugtraq (at) m5p (dot) com [email concealed] (ehem+bugtraq m5p com)
Hash: SHA512

Sometimes trying silly things produces interesting results. I thought
this was a silly thing to try, but I tried it and got a result that is
troubling. This is on a device with a heavily modified setup and kernel,
but the kernel is still ultimately based off of OpenWRT's kernel patches.

$ id -a
uid=1000(user) gid=100(users) groups=100(users),0(root)
$ ifconfig eth0
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
$ ls -l `which swconfig`
- -rwxr-xr-x 1 root root 10048 Nov 20 2015 /sbin/swconfig
$ swconfig dev eth0 set reset
$ swconfig dev eth0 set enable_vlan 0
$ swconfig dev eth0 set apply

OpenWRT is targeted at embedded devices that generally aren't too likely
to have many users (or any non-admin users), but `swconfig` still
shouldn't be able to change a switch chip's settings without
CAP_NET_ADMIN permission. Notably this means unprivileged portions of
daemons will retain the ability to play with switch chip settings, so
this is more likely to be an issue for multi-function devices.

Examination of the code suggests all switch chips using OpenWRT's
`swconfig` infrastructure are vulnerable to this issue. Systems with
switch chips which do not utilize this infrastructure are not effected by
this vulnerability.

Assuming I've got my brains together and press the right key, I've
attached a patch (also assuming it didn't get broken by newer code) which
fixed the issue. After adding the patch and building a new kernel:

$ swconfig dev eth0 set reset
$ swconfig dev eth0 set enable_vlan 0
$ swconfig dev eth0 set apply

"Permission denied" would be better (hinting you're at the wrong prompt),
but the security issue is fixed. Meanwhile, at a root shell:

# swconfig dev eth0 set reset
# swconfig dev eth0 set enable_vlan 0
# swconfig dev eth0 set apply

So looks like the patch works.

Good news is the damage potential of this bug is pretty mild. The
ability to execute code on the device is needed before one can take
advantage of this. One can have a switch chip merge all VLANs together,
completely disabling all firewall functionality. Some or all VLANs could
be disconnected from one or more ports causing a DoS on selected ports.

Unfortunately, my efforts to contact people behind various router
distributions have met with only modest success. Imre Kaloz of OpenWRT
seemed interested in security issues, but others at OpenWRT apparently
aren't and messages to the contact address went unanswered. Robert Call
of LibreCMC was the only fully successful contact. No one from any other
Linux router distribution responded, this is rather disappointing and a
Bad Sign(tm) for security of Linux routers.

The initial attempt at contacting OpenWRT was on December 14th, 2015. I
still do not see any attempt at a fix in OpenWRT's repository.

- --
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM+sigmsg (at) m5p (dot) com [email concealed] PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Version: GnuPG v2


(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM+sigmsg (at) m5p (dot) com [email concealed] PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Check for capability CAP_NET_ADMIN before allowing changing switch device configuration

Signed-off-by: Elliott Mitchell <ehem+openwrt (at) m5p (dot) com [email concealed]>

--- a/target/linux/generic/files/drivers/net/phy/swconfig.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig.c
@@ -635,6 +635,10 @@ swconfig_set_attr(struct sk_buff *skb, struct genl_info *info)
struct switch_val val;
int err = -EINVAL;

+ /* check for appropriate permission before allowing setting changes */
+ if(!capable(CAP_NET_ADMIN))
+ return -EPERM;
dev = swconfig_get_dev(info);
if (!dev)
return -EINVAL;
Version: GnuPG v2


[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus