4 ms·

I have a feeling this is blown out of proportion. Who's running bash setuid exactly? Right. Who's running shell CGIs today? Right. So.. who has an example of c

• revelation 12y ago
  GitHub? I'm reminded of https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61 https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61 Of course that was fixed a long time ago, but I wonder what other systems are just a thin veneer over pretending the user controls a shell.
• fabulist 12y ago
  Google brings up 410 .bash CGIs. Every one of them is almost guaranteed to be vulnerable at this point. Of the 1.2 million .sh CGIs, some are surely vulnerable. By this time, many of them are already be in the process of being owned. CGIs are likely the smallest piece of the vulnerable hosts here. This is going to stick around as a local vulnerability on the plentiful supply of under-patched Linux boxes for a long time.
  • zobzu 12y ago
    thats a really small number of servers actually.. i mean ppl get owned every day, every minute. theres a bunch of more easily exploitable local bugs that actually elevate your privileges. this one bug DOES NOT elevate privs. you need a service that passes unsanitized env vars (unchecked user input) to bash with another user id than yours.
• adamt 12y ago
  As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ https://securityblog.redhat.com/2014/09/24/bash-specially-cr... The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and running it)
  • cpncrunch 12y ago
    You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.
    • adamt 12y ago
      Because of the way cgi works you could just set a user agent or other http header to contain an 'rm' or'nc' command or something in to download and run an attack tool. E.g. You could run netcat to listen on a port or connect out to an attacker's system to provide a connection into an otherwise firewalled database server
      • cpncrunch 12y ago
        Yes, you're right. We have perl running on our server, and I just verified that it is vulnerable if any shell scripts are run from perl. However I just quickly switched on modperl, and I verified that it is now not affected. (According to Redhat, mod_perl and php are not affected, but it's good to verify).
    • jrochkind1 12y ago
      RedHat security says: > PHP scripts executed with mod_php are not affected even if they spawn subshells. https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
• kazinator 12y ago
  Even if the malicious code doesn't have superuser context, it can do damage to whatever context it is running under. If it's running as www-data, it can trash all your www-data-owned files. Or send your www-data-owned password files somewhere, etc. Unprivileged code can also attack other systems (firewalls permitting); you don't have to be root on system A, to be part of a bot net which attacks system B. Denial-of-service havok can be wreaked from a regular user context, too. Not to mention privacy violations. Pretty much all browser-related security and privacy issues are user space!