Didn't take the script kiddies long to start trying...
89.207.135.125 - - [25/Sep/2014:03:22:13 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 295 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" 198.20.69.74 - - [25/Sep/2014:13:49:53 -0500] "GET / HTTP/1.1" 301 301 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c 1 104.131.0.69"
The above is on the MUUG web server. Of course, they didn't get anywhere with either of these attempts.
I have another host, with some CGI scripts that have names of the form */cgi-bin/*.sh, and those URL's are seeing a lot of attempts (all failed as well). I guess they've got lists of potential target URL's to try, and anything ending in ".sh" is going to be irresistible!
Keeps life interesting, for some, I suppose.
Gilbert
On 25/09/2014 7:23 AM, Sean Walberg wrote:
I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know...My guess would be anything attached to a web server -- CGI, dynamic apps that shell out to stuff like imagemagick, etc. Headers are passed through to the script: HTTP_REFERER, USER_AGENT, and so forth.
Sean
On Thu, Sep 25, 2014 at 6:02 AM, Trevor Cordes <trevor@tecnopolis.ca mailto:trevor@tecnopolis.ca> wrote:
Wonderful, another day, another big bad security hole... or two. Run your patches! First up: bash: $ env x='() { :;}; echo OOPS' bash -c /usr/sbin/nologin OOPS This account is currently not available. http://www.openwall.com/lists/oss-security/2014/09/24/10 claims: > In many common configurations, this vulnerability is exploitable over > the network. I'm trying to guess how? In what instance is some program allowing network vectors to set env vars, especially without sterilization? Or do I not want to know... Next up, procmail has a formail buffer overflow that may or may not allow arb code exec CVE-2014-3618. Many stock procmail recipes use formail. It's easy to see how this one is remotely exploitable.