121–130 of 226 posts
PoC floating around: rm -f echo && env -i X='() { (a)=>\' bash -c 'echo date'; cat echo
rm -f echo && env -i X=' \ \echo date" in a bash term somehow yields same result as "date > echo". Is this a feature? [4] Does bash have a ">\" operator? [5]
' bash -c 'echo date'; cat echo I would really appreciate anyone shedding some light on [1]...[5].
Earlier quoted context omitted.
I am seeing: web22 ~> grep "() {" logs/access_log 209.126.230.72 - - [24/Sep/2014:17:16:46 -0700] "GET / HTTP/1.0" 200 5733 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" 13378 () { :; }; ping -c 23 209.126.230.74 80 74529
very interesting one: 89.207.135.125 - - * () { :;}; /bin/ping -c 1 198.101.206.138"
Lets all ping 198...138!
With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…
The exploit worked against my cgi perl scripts as well! I had cgi-bin/update.pl running on OS X and I exploited it as mentioned here: https://twitter.com/hernano/status/514866681530023936 My perl scripts call $out = `git pull`, log to a file, and print a response; I was quite surprised the exploit worked against them. Promptly disabled, upgraded bash, and re-enabled, now disabling all cgi for a bit longer. What are t…
Perl backticks and system() delegate commands to the system shell, normally sh. On many systems, sh is simply bash in compatibility mode. That's how the attacker gets at the vulnerability.
Earlier quoted context omitted.
I am seeing: web22 ~> grep "() {" logs/access_log 209.126.230.72 - - [24/Sep/2014:17:16:46 -0700] "GET / HTTP/1.0" 200 5733 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" 13378 () { :; }; ping -c 23 209.126.230.74 80 74529
very interesting one: 89.207.135.125 - - * () { :;}; /bin/ping -c 1 198.101.206.138"
>89.207.135.125 - - - "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 302 483 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
...searching for vulnerable CPanel installs.
With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…
This assumes that system() is calling bash, but it usually calls /bin/sh, which is often linked to something other than bash (for example, dash is used on recent Ubuntu and Debian installs).
It should be possible to mitigate this attack (and many similar) by better header values parsing (in Apache/nginx/... - maybe in some proxy?). For instance, Content-Type header can only include alphanumeric chars + slashes. Most of the other headers are similar. User-Agent is free-form, but there is no need to pass it to ENV (and it could be sanitized to only include alphanumeric chars and spaces).
Any idea, are web server maintainers working on this?
With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…
It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. Seriously, polutting ENV with HTTP headers? Admins should at least be able to block this. It should be possible to mitigate this attack (and many similar) by better header values parsing (in Apache/nginx/... - maybe in some proxy?). For instance, Content-Type header can only include alpha…
It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. Seriously, polutting ENV with HTTP headers? Admins should at least be able to block this. It should be possible to mitigate this attack (and many similar) by better header values parsing (in Apache/nginx/... - maybe in some proxy?). For instance, Content-Type header can only include alpha…
The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).