OpenWRT: swconfig infrastructure fails to check permissions

[Elliott Mitchell <ehem+bugtraq () m5p com>]

-----BEGIN PGP SIGNED MESSAGE-----
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 1.2.3.4
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
failed
$ swconfig dev eth0 set enable_vlan 0
failed
$ swconfig dev eth0 set apply
failed
$

"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 () m5p com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREKAAYFAldbIKAACgkQs3U30IcUVEUobwD/UPk9wfVJe3laCYnzJ1+jT1p3
yJ8AqgcbziANchO0g0YBAINRD5VyxscEk0oqTH8ppQzrzsV9J+P+NAMGULvR0J2p
=Drio
-----END PGP SIGNATURE-----


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

Attachment: phy_swconfig.c_SECURITY.patch
Description:

Attachment: phy_swconfig.c_SECURITY.patch.asc
Description: