Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bash Command Injection Vulnerability #81

Open
Electromaster232 opened this issue Aug 4, 2019 · 5 comments

Comments

@Electromaster232
Copy link

commented Aug 4, 2019

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

image

@xDrixxyz

This comment has been minimized.

Copy link

commented Aug 4, 2019

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.

@xDrixxyz

This comment has been minimized.

Copy link

commented Aug 4, 2019

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.

@respawner respawner self-assigned this Aug 5, 2019

@respawner respawner added the bug label Aug 5, 2019

@respawner

This comment has been minimized.

Copy link
Owner

commented Aug 5, 2019

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

@xDrixxyz

This comment has been minimized.

Copy link

commented Aug 5, 2019

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.

@respawner

This comment has been minimized.

Copy link
Owner

commented Aug 5, 2019

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.

respawner added a commit that referenced this issue Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.