Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Apple Yet To Push Patch For "Shellshock" Bug

spitzak Re:The whole function exporting mechanism is a bug (208 comments)

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.

3 days ago
top

Nearly 2,000 Chicago Flights Canceled After Worker Sets Fire At Radar Center

spitzak Re:what a difference a day makes (221 comments)

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...

4 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:"could be worse than Heartbleed" (317 comments)

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().

4 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:It's been in bash a while. (317 comments)

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

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:So flog the bash developer who checked this in. (317 comments)

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.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:This exposes systemic insecurities (317 comments)

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.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:USER-AGENT (317 comments)

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().

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:"could be worse than Heartbleed" (317 comments)

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?

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:Why is this a real problem? (317 comments)

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.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:"could be worse than Heartbleed" (317 comments)

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.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:"could be worse than Heartbleed" (317 comments)

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.

5 days ago
top

Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

spitzak Re:It's been in bash a while. (317 comments)

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.

5 days ago
top

Remote Exploit Vulnerability Found In Bash

spitzak Re:My explanation (399 comments)

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.

about a week ago
top

Fukushima Radiation Still Poisoning Insects

spitzak Re:BS (115 comments)

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.

about a week ago
top

Fukushima Radiation Still Poisoning Insects

spitzak Re:Cue the knee-jerk nuke lovers & their BS. (115 comments)

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.

about a week ago
top

Remote Exploit Vulnerability Found In Bash

spitzak My explanation (399 comments)

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...

about a week ago
top

Universal Big Bang Lithium Deficit Confirmed

spitzak Re:Quite accurately? (171 comments)

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.

about three weeks ago
top

Universal Big Bang Lithium Deficit Confirmed

spitzak Re:Quite accurately? (171 comments)

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?

about three weeks ago
top

SpaceX and Boeing Battle For US Manned Spaceflight Contracts

spitzak Re:Can someone explain to me (123 comments)

The "upgrade" to Hubble could have been accomplished more cheaply by launching another Hubble.

about three weeks ago

Submissions

spitzak hasn't submitted any stories.

Journals

spitzak has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?