On Thu, Sep 25, 2014 at 2:58 PM, Bruce W. Martin <[email protected]> wrote: > I am a bit confused about this bug. What is the vector to exploit this?
Most web servers pass various bits of information to CGI scripts via environment variables, such as HTTP_USER_AGENT, HTTP_REFERER, and others, which are all settable to arbitrary text. Those environment variables are evaluated upon the invocation of some shells, most notably bash, in this instance. If you can get the web server to run bash, either through a shell script invoked directly, or, more likely, as part of the system() call, then you can exploit this particular bug in bash. The reason why this is so bad is because on many Linux distributions, the default shell used to invoke shell commands is /bin/sh, which is symlinked to /bin/bash. Interestingly, on most modern Debian or Ubuntu systems (or distributions derived from them), /bin/sh is symlinked to /bin/dash, which is not vulnerable to this exploit. So those systems are not generally expoitable (but may still be specifically exploitable, if somebody has written a bash script that is invoked by a CGI script without first clearing the environment of variables populated by data from a remote user). > If I > turn off the web server daemon is the only vector then from those who can > log in with appropriate credentials? Not necessarily. There are certainly other services which may invoke shell scripts, but the question is whether any of them set environment variables where a client can specify the contents. I don't have a specific example, but it's not out of the realm of possibility. Certainly, there are other services which take advantage of the popularity of the HTTP/CGI protocols and embed their own servers, and those could potentially execute scripts via an external process. > I have an old RHEL server that no > longer gets updates and a debian server that suddenly apt-get does not seem > to work. I have shit down the debian server and turned off the web server > daemon on the old RHEL box. Does that make it safe as long as no miscreant > can log in via ssh (no telnet daemon in decades)? The only sure bet is if the box is not serving anything to untrusted hosts, or if you're intimately familiar with the source code internals to know that such a vector is not possible. I specifically would not trust game servers or anything closed source. > The press seems all > sensational and says this is worse than Heartbleed but beyond that there is > not much substance in what I have found so far. It is not worse than Heartbleed. With Heartbleed, there was no obtainable evidence about whether any of your keys had been compromised, and once a key had been compromised, someone could have decrypted all of your SSL traffic, both in real time, as well as past SSL transactions, had they had the foresight to capture the traffic prior to the time of compromise. In other words, once you patched, you HAD to additionally replace your keys purely as a self-defense mechanism, without ever truly knowing if your keys were ever compromised (and that still would only protect you going forward, not protect your past sessions). With this issue, if someone exploits your box, you're going to know about it in short order. -- Tilghman -- -- You received this message because you are subscribed to the Google Groups "NLUG" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en --- You received this message because you are subscribed to the Google Groups "NLUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
