Critical Linux, Unix, Mac security vulnerability found in bash shell
119 replies, posted
[QUOTE=Teddi Orange;46074500]It seems if you're running nginx as a frontend as opposed to Apache, you're probably okay as nginx doesn't seem to pass env variables (web server wise)[/QUOTE]
nginx does not support CGI, CGI is an outdated technology no longer useful for anything other than simple low traffic scripts, and making CGI scripts work with nginx is more trouble than it's worth, so you're just not gonna find any nginx servers vulnerable to this.
[QUOTE=DrTaxi;46074601]nginx does not support CGI, CGI is an outdated technology no longer useful for anything other than simple low traffic scripts, and making CGI scripts work with nginx is more trouble than it's worth, so you're just not gonna find any nginx servers vulnerable to this.[/QUOTE]
Easier to state though rather than have uncertainty around :)
[QUOTE=pentium;46074555]Talked to my unofficial SGI rep and it seems that I'm in the green unless:
-If you use a bash script for CGI
-If you've replaced /bin/sh with bash
Neither apply on me so I'm okay.[/QUOTE]
I'd still try to fix this, you never know what weird stuff might be shelling out with user input set as environment variables.
Besides, you're running IRIX, surely you know how to compile a program.
[QUOTE=Amakir;46073998]Should I as a regular user be worried about this or is it only something that is dangerous to servers?[/QUOTE]
Servers mostly, since they are going to be publicly accessible. Still a good idea to patch though.
That's not to say you aren't at risk as a user. Your own system may not be vulnerable but any data you may have stored on these vulnerable systems is at risk.
If I'm understanding this issue correctly it seems to provide full command line access on the server, With this sort of access one could quite easily dump a database or modify code.
[QUOTE=SPESSMEHREN;46074066]Well that was quick. Just found this in my VPS's apache access log:
89.207.135.125 - - [25/Sep/2014:03:46:42 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 506 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Appeared to target a cPanel CGI plugin that allows for remote code execution.
[editline]25th September 2014[/editline]
209.126.230.72 - - [25/Sep/2014:00:51:48 -0500] "GET / HTTP/1.0" 200 381 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"[/QUOTE]
Thanks to this post I decided to check the log of my VPS, I don't seem to have anything along the lines of that but I have been getting some nice person at 93.118.42.117 trying to find an exploit using ZmEu. Every single request returned 404 so I guess that's okay(ish).
[QUOTE=Jsm;46075039]but I have been getting some nice person at 93.118.42.117 trying to find an exploit using ZmEu. Every single request returned 404 so I guess that's okay(ish).[/QUOTE]
I get around 200 of those each day.
[QUOTE=DrTaxi;46074601]nginx does not support CGI, CGI is an outdated technology no longer useful for anything other than simple low traffic scripts, and making CGI scripts work with nginx is more trouble than it's worth, so you're just not gonna find any nginx servers vulnerable to this.[/QUOTE]
What about things like PHP-FPM, (it's a CGI). running on nginx, would that be at risk?
good thing i run a webserver on windows
[QUOTE=kaukassus;46075053]I get around 200 of those each day.[/QUOTE]
Do you have fail2ban installed and running?
C Shell master race.
Wow, my being too lazy to code my server applications in linux seems to have paid off.
[QUOTE=sasherz;46075210]Wow, my being too lazy to code my server applications in linux seems to have paid off.[/QUOTE]
If you're running on Windows, all I can say is:
At least Linux users get to know about their vulnerabilities.
To see an example of this problem:
[code]
stone@Lappy-486:~$ env x='() { :;}; echo vulnerable' bash -c echo "This is a test."
vulnerable
This is a test.
# Straight-up code injection. That's bad.
[/code]
Despite it being unlikely for a common user to be exploited, you can try zsh. [B]Almost[/B] exactly like bash minus some interactive shell differences...at least as far as I can tell.
Thank goodness RHEL and centos already have a patch, most of the internet is safe.
[QUOTE=Stonecycle;46075306]To see an example of this problem:
[code]
stone@Lappy-486:~$ env x='() { :;}; echo vulnerable' bash -c echo "This is a test."
vulnerable
This is a test.
# Straight-up code injection. That's bad.
[/code]
Despite it being unlikely for a common user to be exploited, you can try zsh. [B]Almost[/B] exactly like bash minus some interactive shell differences...at least as far as I can tell.[/QUOTE]
[code]
env X='() { (a)=>\' sh -c "echo date"; cat echo date
[/code]
I think this is another one you can use to see whether you're vulnerable or not (from [url]http://www.openwall.com/lists/oss-security/2014/09/25/10[/url], mentioned by DrTaxi).
[QUOTE=01271;46075314]Thank goodness RHEL and centos already have a patch, most of the internet is safe.[/QUOTE]
....as long as the sysadmins actually update it.
[QUOTE=01271;46075107]What about things like PHP-FPM, (it's a CGI). running on nginx, would that be at risk?[/QUOTE]
php-fpm is fine.
I updated my Bash as per [url]https://shellshocker.net/[/url] but exploit 2 there still prints the date. Anything I can do (besides keeping Apache down)?
eh snip I guess
[QUOTE=MegaJohnny;46075733]I updated my Bash as per [url]https://shellshocker.net/[/url] but exploit 2 there still prints the date. Anything I can do (besides keeping Apache down)?[/QUOTE]
Is it printing "date" or the actual date? Just saying "date" is fine. Updating bash on Debian 7 covered both for me.
[QUOTE=Snowmew;46075859]Is it printing "date" or the actual date? Just saying "date" is fine. Updating bash on Debian 7 covered both for me.[/QUOTE]
The actual date - so the command is getting run.
I'm running a Ubuntu server, and their website says the best thing is just to update to the newest Ubuntu. I should probably get round to it, but it's just a pain setting up the screen session and all the servers after the reboot. :v:
Debian Wheezy (Security) has the exploit fixed. Wheezy itself will probably come next.
Updated bash on my Ubuntu 12.04 VPS, both tests listed on the shellshock site seem to fail now, thanks for linking to that.
This isn't as big of a security issue as people make it out to be tbh unless you are using apache and for some reason using bash as a CGI script.. which is dangerous to begin with
[QUOTE=AJ10017;46075113]good thing i run a webserver on windows[/QUOTE]
dear god
[QUOTE=Zeke129;46077964]dear god[/QUOTE]
rip
[QUOTE=kaukassus;46075053]I get around 200 of those each day.[/QUOTE]
Someone once ran a bot against my server that looked to see if the web root directory happened to be in a user's home directory, and scanned for Bitcoin, Litecoin, and Dogecoin wallets. I made a wallet.dat file and wrote "HAHAH, FUCK YOU SKIDDIE" in it, if the bot ever comes back. :v:
If you're running mod_security (now's a good time to install it if you weren't already), you can completely mitigate the risk (unless someone has SSH access to the server of course) until a proper patch is out.
SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
SecRule FILES_NAMES "^\(\) {" "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"
Courtesy of the wonderful system administrators at RedHat.
how to fix exploits and hackers 101
[img]http://i.imgur.com/AIWoP2j.jpg[/img]
[img]http://i.imgur.com/dbdiKya.jpg[/img]
just joking but blocking china and russia really helps lol.
Sorry, you need to Log In to post a reply to this thread.