So many to choose from…

Michael Messner has been looking at wireless routers, which turn out to be pretty insecure. To take one random example, the Netgear DGN2200B has an OS command injection vulnerability:

The vulnerability is caused by missing input validation in the pppoe_username parameter and can be exploited to inject and execute arbitrary shell commands. It is possible to upload and execute a backdoor to compromise the device.

He goes on to show how setting pppoe_username to

    %26%20telnetd -p 1337%20%26

in an HTTP POST request will start up a telnet daemon on the router. The %20 is an (escaped) space character and the %26 is an (escaped) ampersand. What seems to be happening is that the pppoe_username parameter is being used in the construction of a shell command, and in the shell, the ampersand can be used to delimit shell sub-commands. So the router is executing a shell command (presumably for administrative purposes) that mistakenly contains a malicious sub-command. Once in place, the attacker can log in to the router and do whatever he likes.

Is it fair to call this “missing input validation” a parser bug? It would seem that the fix is simply to verify that pppoe_username is just a user name, which presumably cannot contain ampersands.

Of course, verifying that an input string matches a syntax specification is the essence of parsing. So this is a parsing bug, even though it seems at first too simple to call it “parsing”.

If you consider the problem more closely, you will see that in fact there are complications. What exactly is the allowed syntax for a pppoe_username? Different systems allow different characters in user names; some are case sensitive, some are case insensitive; some allow spaces and some don’t. Where does one find the syntax specification for user names in PPPOE? And does this particular implementation obey that syntax specification, or something else? There’s a lot of room for mistakes.

Similarly, what exactly is the syntax of a shell command? This is quite a bit more complicated than the rules for pppoe_username, and yet it is essential for understanding the attack and for building a defense. The key insight is that the constructed shell command parses unexpectedly. Once you understand this, you know how to build a defense. Su and Wasserman explain this nicely in their paper, The Essence of Command Injection Attacks in Web Applications.

Stepping back, it’s unfortunate that you need to understand shell command parsing to implement a web application for administering a home router; but that’s where we are.