Bash Command Injection Vulnerability

[Electromaster232]

Hi,

I've found a bug that allows me to inject any bash command I want into the system running the script. My tests used the BIRD router, I don't know if this is possible on other systems. If the user configuring the router used a user with no permissions, this may not be an issue, but if they didn't, you could wreak havoc on systems:

To reproduce it: Open your looking glass Select "show route as-path-regex" as the command Enter "test =]' && echo '" You will see that the closing character of the command (=]) has been printed.

You can then modify the command to do things like list the directory of / (replace the "echo" part with any bash command, and it will be executed, but the =] will be printed after, so this is technically limited to commands that can have that extra bit thrown out, but I was able to find a few including rm that this could cause major issues with) Heres an example of how I was able to use "curl" with this. It could be used to download a shell-backdoor and execute it

[sanelkukic]

Just to add some details here as I was the person who originally found this, but I'm perfectly fine with Electro submitting this report, you can fix any issues with the ending =] bit by adding another echo right before it.

Such as: test =]' && ls /root && echo ' which would list the contents of /root

You could also theoretically replace test with a valid string to get the show route as-path-regex command to succeed as well. I haven't personally tried this myself but it should work.

[sanelkukic]

I've also found a related issue, #13 which references a commit 308173b which adds some checks to see if there are any ; or " characters present, but not ' (single quotes).

Since I noticed that this is in PHP, you could use escapeshellarg() to escape the input and use it safely in a shell command.

[gmazoyer]

Did you manage to reproduce this even in a restricted shell (setup mentioned here)?

[sanelkukic]

I haven't tested it in a restricted shell yet, however I would assume the vulnerability in and of itself would still exist, however the capability of it would be somewhat limited (no cd) but assuming the script is still running as root or some other highly privileged user, then you could still do stuff like accomplish information disclosure and run commands such as cat /etc/passwd or add contents into /etc/passwd or other files.

Now you could theoretically limit the capability of the vulnerability even further by using a chroot jail in combination with a restricted shell however that doesn't address the vulnerability at hand, and would require the system administrators to implement these features on their installations, instead of simply updating the Looking Glass software.

In addition, nothing is stopping me from possibly escaping the restricted shell by creating a new instance of bash, or writing to a script file test.sh and running it, even in a restricted shell.

I could then make this script file add a new user to the system (assuming the script is running as root or some other user with higher privileges on the system) and allow me to SSH into it, or do other things.

Once again though, I haven't personally tested this in a restricted shell, these are all assumptions I am making, and I welcome any corrections if I am wrong.

[gmazoyer]

We definitely have to fix the issue by sanitizing the user input or forbidding him to use some harmful characters. That is what was done to fix issue #13.

In addition to that fix I strongly suggest users to not use this script as root and with a standard shell.