No, everybody should carry matches! They would surely have stopped this maniac that way! It's the damn gubiment saying we can't carry matches...

Whoosh!

Sorry you are right. It is with any program that calls anything that eventually calls system recursively.

The problem is a lot of people are saying "this program calls system() and is therefore vulnerable". That is false. That program, or something calling it, must also set an environment variable to unchecked user input. Therefore it is not quite as bad as this knee-jerk reaction is. It is pretty bad, but all actual holes found involve an outermost program that sets environment variables.

I fully agree that 100% of the bug is in bash, not anywhere else. Though programmers and libraries could be blamed some for encouraging use of system() when other methods would not only be safer but faster too, but those methods have too complex an api. Certainly I have seen even python code use system to do things such as run rm, when python has a library method to remove files. There is a serious problem that it is nearly impossible to locate how to do something easily other than doing system().

Yuck, that's pretty bad, especially because web servers are not so easy to update.

Apparently it also concatenates the -c argument and parses the whole thing at once. Unbelievable.

This is the still-existing exploit. Try this in the patched version (or the one for that matter):

    env X='() { (a)=>\' bash -c "file echo vulnerable; cat file"

My guess is because it pasted the -c onto the end of the command with a newline. The >\ somehow caused a > sign and an escaped newline to be parsed, resulting in the command ">file echo vulnerable" to be executed.

This looks a lot harder to exploit as there is less control over the -c argument, and it has to be the last environment variable.

No I think you are confusing it a bit. Yes it would be really bad if something calling system() had a defect such that an attacker could set $PATH beforehand. But that would be an obvious bug and fixed long ago.

This bug just requires a piece of text crafted by the user to be in *any* environment variable. For instance if the calling code put the arguments to the function it wanted into $ARG1, $ARG2, etc.

No GP is correct.

Calling system() is not sufficient. The vulnerable software also has to set an environment variable to a value the attacker can control. The GP lists two known ones: web servers and DHCP. This is obviously a subset of all software that calls system().

No, it is any CGI program that sets an environment variable to unchecked user input and then invokes a shell or calls any other program that invokes a shell.

Got that?

Programs use system() and popen() because it is easy. They want to search the path for executables, they want to do glob expansion of filenames, they want to put the process in the background. Go ahead and try to write those with what libc provides, and compare to the one-liner of system()/popen(). Compare which is easier to understand, too.

The problem is that the functions provided by libc are not what programmers actually need. Most everybody would be happy with a "do what the shell does with these words", ie do_what_i_want(FORK, "rm --","foo","bar","name with space");

Though this bug in bash is pretty inexcusable. Even if it was patched to not be a hole, it sounds like it parses the entire environment on startup, which is not good for these quick uses. Should defer it until the variable is first accessed.

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...

You have it somewhat wrong. The arguments to the shell are irrelevant as several mention below. However the program must set an environment variable to unchecked user input, something everybody seems to be missing. According to the advisory, DHCP has this bug in that it copies strings in the request (or at least the string identified by "114") to environment variables.

Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

You need to insert user-supplied data into an environment variable for this to be vulnerable.

Also your example calls system() and thus it does not matter whether the executable is a bash script or not, because system() launches it's own bash interpreter. If the exploit was in an environment variable this would do it twice!

The fact that you did this does show that system() is the problem. It is so tempting to call. I think about 90% of the reason is that it searches the path for the executable, which exec() does not do. Getting glob results is probably the other 10%. Really the library should be providing more convienent minimal functions so people don't do this.

That requires the interpreter to copy the value of Cookie into an environment variable, so it won't work if that is not done. Don't know what web server you are talking about that does that.

The problem is cgi that purposely puts a user-settable variable into an environment variable. For instance something a user types into a form. They type their name and the cgi does setenv("NAME",text) and then calls system().

I suppose there are web servers that copy Cookie into an environment variable. Is there a particular one you know about? I would say the bug is somewhat in that as there seems no really good reason to do this.

Well I don't know much bash, so I figured out why this is happening, though it still seems unbelievable.

Apparently the normal way to define a function is to write "x() {...}". But it stores it in an environment variable for some reason, I think so that a recursively called bash gets the same function definition.

To support that, on startup it scans the environment for variables starting with "() {" (spacing must be exactly that). It then defines the function by pasting the variable name onto the start of the variable and interpreting that. And the interpreter splits at the semicolons and executes the remaining text as commands, leading to this bug.

The whole thing looks pretty messy. Certainly it should have been possible to call some lower-level function *after* the interpreter has figured out it is defining a function, and that one would barf on the semicolon. Also you get this interesting and misleading effect:

      $ export x='() { echo WORKS;}'
      $ x
      x: command not found
      $ bash -c x
      WORKS

Their solution is rather annoying because you now cannot set environment variables to all possible byte strings. That sucks. They should have left the environment variable set to the text and not defined the function.

As for the oceans around Hawaii, they probably were damaged more by the 106 above ground nuclear bomb tests the US did at the Pacific Proving Grounds [wikipedia.org] - I doubt Fukushima and Chernobyl will ever do as much damage as those did, even if all of the reactors there had resulted in full meltdowns..

Yea I was confused about his Hawaii statement, but I suspect this is actually what he was referring to.

Actually hydro is powered by the sun evaporating water and transporting it higher.

And almost everything else we burn was chemicals made using solar energy by plants.

So really *every* power source we use is nuclear.