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.
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.
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.
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().
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.
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.
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.
This is bad. The reason is lots of things that use bash put unchecked data into environment variables.
As an example, imagine some cgi wants to test is a string is valid, and somebody wrote a clever bash script that does this check, and reads the string by looking in $INPUT. The cgi takes whatever the user typed on their web form, does setenv("INPUT", text) and then runs the bash script, which uses "$INPUT" at places it wants the text.
No matter how carefully written the bash script is, if the user can type "() {:;}; exploit" into the text field, it will run "exploit". There is no reason for the cgi to test for any syntax errors because that is the job of the bash script!
It seems hard to believe such a bug is possible. It appears that when setting an environment variable, if it is a function, it runs some code that splits the text at semicolons, puts the first section in the environment variable, then runs the rest as shell input! But I can't figure out any reason such code exists. I thought at first it was pasting "export " on the start of the environment line and executing that using the interpreter, but tests show that does not work because it splits at the spaces. And if you add quoting to fix that then it also fixes the semicolon. And it obviously examined the environment variable to see if is a function, because semicolons in non-function ones are handled correctly. So I think bash code might be quite a mess for such a bug to be possible without much more obvious bugs happening...
You may have seen tables of various isotopes of Hydrogen and Helium, those seem to match predictions very well, and there are more than 2 of them, which may be why you are thinking it may go above 2 in the atomic table.
The model can give a "quite accurate" expected value, even when wrong. Example (note numbers are completely made up):
Say there is model A which predicts 2.5-2.6% lithium.
Say there is another model B which predicts 2%-8% lithium.
Say in reality there is 1% lithium.
Both models are apprently wrong. But Model A is more "accurate" in making the wrong prediction. Therefore the text in the article is perfectly correct.
Actually it will be a lot worse than Venus and due to a different cause in that the sun would actually be irradating many times more energy on it, and possibly even engulfing it in hot plasma. Venus is heated by the insulation of a huge amount of CO2, the Earth with that much CO2 would be equally hot, and Venus without it would be just a tropical Earth. And when the sun expands the CO2 will be irrelevant (I would think the heat would actually make it escape to space), not that that is going to help any.
I don't know if this is a troll, but if not you may be a bit confused about who is "falling for this". It seems you are as you just listed a few outright lies and distortions.
Slashdot Mirror
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.
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.
This is bad. The reason is lots of things that use bash put unchecked data into environment variables.
As an example, imagine some cgi wants to test is a string is valid, and somebody wrote a clever bash script that does this check, and reads the string by looking in $INPUT. The cgi takes whatever the user typed on their web form, does setenv("INPUT", text) and then runs the bash script, which uses "$INPUT" at places it wants the text.
No matter how carefully written the bash script is, if the user can type "() { :;}; exploit" into the text field, it will run "exploit". There is no reason for the cgi to test for any syntax errors because that is the job of the bash script!
It seems hard to believe such a bug is possible. It appears that when setting an environment variable, if it is a function, it runs some code that splits the text at semicolons, puts the first section in the environment variable, then runs the rest as shell input! But I can't figure out any reason such code exists. I thought at first it was pasting "export " on the start of the environment line and executing that using the interpreter, but tests show that does not work because it splits at the spaces. And if you add quoting to fix that then it also fixes the semicolon. And it obviously examined the environment variable to see if is a function, because semicolons in non-function ones are handled correctly. So I think bash code might be quite a mess for such a bug to be possible without much more obvious bugs happening...
You may have seen tables of various isotopes of Hydrogen and Helium, those seem to match predictions very well, and there are more than 2 of them, which may be why you are thinking it may go above 2 in the atomic table.
The model can give a "quite accurate" expected value, even when wrong. Example (note numbers are completely made up):
Say there is model A which predicts 2.5-2.6% lithium.
Say there is another model B which predicts 2%-8% lithium.
Say in reality there is 1% lithium.
Both models are apprently wrong. But Model A is more "accurate" in making the wrong prediction. Therefore the text in the article is perfectly correct.
Get it?
The "upgrade" to Hubble could have been accomplished more cheaply by launching another Hubble.
Actually it will be a lot worse than Venus and due to a different cause in that the sun would actually be irradating many times more energy on it, and possibly even engulfing it in hot plasma. Venus is heated by the insulation of a huge amount of CO2, the Earth with that much CO2 would be equally hot, and Venus without it would be just a tropical Earth. And when the sun expands the CO2 will be irrelevant (I would think the heat would actually make it escape to space), not that that is going to help any.
I don't know if this is a troll, but if not you may be a bit confused about who is "falling for this". It seems you are as you just listed a few outright lies and distortions.