Burn in hell, you copyright violating scum!

I know you are trying to be funny, but human beings breathing does not contribute to global warming. This is because the CO2 produced is from combining O2 with biologic sources, which are produced by systems that remove the same or more CO2 from the air.

I think this is more or less what is happening.

As opposed to how X works now, new drivers will pretty much support "use EGL to draw all over the screen". The window system is *atop* that, it uses EGL to take texturemaps of window contents and draw and compose them into the right places on the screen.

The application making those texturemaps uses EGL as well, to draw into the texture maps. This means the texture map is already in the correct graphics memory for the window system to use it and everything syncs up and you will get results that are close or equal to the speed you would get if you wrote a single program that drew an entire display of overlapping windows.

In X it was more like the window system was the bottom level and EGL would draw into a window. Compositing window managers that want to use EGL have to create a big fake window that covers the entire screen, and had to add a lot of other kludges to work around the millions of assumptions that a window and any changes to it's pixels was instantly visible on the screen.

The awake guy is useful if HAL has to be disconnected.

That is an excellent idea. Somebody should mod this up!

The way bash is doing this is a ridculous hack and it is not suprising it is also a huge security hole.

You can set an envoronment variable in bash to a value that will cause recursively-called bash to think it is a function, white it is not a function in the bash that defined it. That is just stupid.

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.