back to article Third patch brings more admin Shellshock for the battered and Bashed

A third patch, from Red Hat engineer Florian Weimer, has been released for the vulnerable Bash Unix command-line interpreter, closing off flaws found in two previous fixes. Weimer's unofficial fix was adopted upstream by Bash project maintainer Chet Ramey and released as Bash-4.3 Official Patch 27 (bash43-027) which addressed …

  1. Mark 85 Silver badge

    More patches....

    I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.

    1. Anonymous Coward
      Anonymous Coward

      Re: More patches....

      LOL. 3 patches and we still don't know if it's fixed. I think that this has to be the record for the suckiest OS security ever. Even Microsoft a decade ago couldn't compete with this compendium of disasters...

      It seems to me that it is broken by design. Perhaps the Linux distributions should adopt a more secure and powerful scripting solution like Powershell ?

      1. Anonymous Coward
        Windows

        Re: More patches....

        Linux distributions should adopt a more secure and powerful scripting solution like Powershell

        You obviously don't understand the issue, yet you turn it into an "I love Microsoft" chant?

        I've used Windows long enough to know that we've had more than our share of remote exec problems, too.

        You're in a glass house...

      2. Anonymous Coward
        Anonymous Coward

        Re: More patches....

        You know, I'm just going to recycle my answer here. You don't deserve more.

        1. auburnman
          Facepalm

          Re: More patches....

          We need an option on posts that is more severe than a downvote but less severe than 'report this post' for content that contributes nothing to the discussion and/or wildly praises/denigrates certain companies/products. Although as I type this it dawns on me such a thing would be abused until it lost al meaning.

          1. Anonymous Coward
            Anonymous Coward

            Re: More patches....

            We need an option on posts that is more severe than a downvote but less severe than 'report this post' for content that contributes nothing to the discussion and/or wildly praises/denigrates certain companies/products.

            What, and deprive commentards of the pleasure of ripping such a poster to pieces with clear facts, razor sharp analysis, sarcasm and hollow laughter? You must be joking.

        2. RealFred

          Re: More patches....

          Given Apples recent endevours, I'm sure you will want to modify that reply

      3. Anonymous Coward
        Anonymous Coward

        Re: More patches....@AC

        Oh really ?

        Look up GDI flaws, it's been patched more times than a sex maniacs blow up doll and still keeps leaking.

        1. Anonymous Coward
          Anonymous Coward

          Re: More patches....@AC

          "Look up GDI flaws, it's been patched more times than a sex maniacs blow up doll and still keeps leaking."

          But so far not 3 times in 3 days for 6 different holes (and counting). And the patches generally actually work. And most importantly when talking about servers - GDI vulnerabilities are not remotely exploitable without local user interaction...

          1. Tom 13

            Re: But so far not 3 times in 3 days for 6 different holes (and counting).

            Of course not. MS doesn't even issue a simple patch in less than a month. Which is not exactly a ringing endorsement.

            And IIRC the first "patch" they issued for the problem was a tool that you had to manually run to see if you had the vulnerability. After which you had to locate the correct bit to download and apply to the bits it found. Yes, the tool was in MS Updates (or whatever it was called back then) but not the patches. Royal PITA too as I recall since it stopped the other downloads from proceeding.

            Oh, and part of the reason MS switched to monthly patching? Yeah, it was because of admin fatigue from constantly patching and rebooting their servers before that.

      4. Jim 59

        Re: More patches....

        LOL. 3 patches and we...

        Calm down, troll.

    2. Anonymous Bullard

      Re: More patches....

      I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.

      Oh god yeh, I'm not even a sys-admin, yet the 5 Linux computers I maintain are a right pain in the arse having these security updates automatically applied! I'm over-run by the work.

      I wouldn't mind, but none of these machines even have services that are vulnerable.

      1. Anonymous Coward
        Anonymous Coward

        Re: More patches....

        "yet the 5 Linux computers I maintain are a right pain in the arse having these security updates automatically applied"

        But the latest holes have not been patched on most Linux distributions yet - unless you installed one guy's unofficial fix - which involves some effort.

        If you wait for the patches (presumably your systems check once a day?) you might well already be owned if the boxes are vulnerable...

    3. Anonymous Coward
      Anonymous Coward

      Re: More patches....

      I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.

      Actually, no. The process to address such issues is well established, so it's more a matter of inserting the right components and cranking the handle. Unix is by its very nature very easy to automate, and you can choose just how much you want to do yourself, all the way to downloading the patches and compile the binaries yourself. It is a Unix feature that Apple OSX users enjoy as well, provided they have Xcode installed (which is free, BTW).

      Also keep in mind that 90% of what you read casually omits the fact that this is only an issue for servers, not for desktops (unless I got this wrong, happy to be corrected). That is very bad when it comes to Internet exposed services (think a gazillion Google and Amazon machines, for instance), not so much for your desktop or laptop AFAIK.

      1. Raumkraut
        Alert

        Re: More patches....

        > Also keep in mind that 90% of what you read casually omits the fact that this is only an issue for servers, not for desktops (unless I got this wrong, happy to be corrected).

        Unfortunately, you are indeed mistaken. It turns out that, at the very least, DHCP - the service which likely assigns you your IP address on a network - is often implemented on a *nix client using calls out to a shell. So a malicious DHCP server on your network could exploit this flaw on any machine (or router, storage device, thermostat, lightbulb, etc.) which uses Bash - completely without user intervention!

        Of course, getting that rogue DHCP server on your network is another matter, so this is mostly a concern when using open WiFi networks.

        1. This post has been deleted by its author

      2. RealFred

        Re: More patches....

        If you have web services running on your desktop, guess what

    4. Alistair Silver badge
      Coat

      Re: More patches....

      Say it with me now folks:

      Awwwwwtoemmmmmmmation!

      cfengine/chef/puppet/etc etc.

      1500 to 1600 active systems, no sanity in trying to do each one manually. Test against the app layer in a controlled environment, validate results and push it out with automation. Including the validation.

    5. Anonymous Coward
      Anonymous Coward

      Re: More patches....

      A sysadmin worth their salt of course has an automated way of updating systems. Then it is just a matter of downloading the patched package in your repository (or wait for the automated download) and your scripted cronjob on each system does the rest. Or else just setup the distribution's preferred automated update mechanism. Debian provides the very helpful unattended-upgrades package.

  2. Anonymous Coward
    FAIL

    Fixed. Really?

    If at the very beginning they had ripped out the nova-hot security hole that pass functions around in environment variables, then we wouldn't need to be doing these contortions. My first reaction would have been to bash Bash right off my systems no matter the breakage. And don't think I wouldn't get away with it. My bosses knew I didn't freak over nothing.

    From the very first, Bash has been the only shell equipped with this feature. And it's why you don't find it over BSD-land unless bolted on. Nooo, we have to put enough bandages on it so that it doesn't bleed out all over the place. You can be damned certain of one change that'll happen here should I get the CentOS urge again. Arghhh!

    Where's the giving the middle-finger salute or European equivalent icon?!

  3. G Mac

    Review time - don't be complacent just because of limited shell functionality

    I have been following this story pretty much since the start. Not much impact on me (well timed vacation?) but our system administrators and engineers (for review and regression of production systems) have been roped in.

    With the news that there are other undisclosed remote execution bugs out there there are going to be a *lot* of blackhat (and hopefully whitehat) folks carefully reviewing ALL shell code...

  4. Eddy Ito Silver badge
    Trollface

    There is always easy1 way

    ln -s /bin/ash /bin/sh

    1. For vanishingly small values of easy.

    1. Anonymous Coward
      Anonymous Coward

      @Eddy Ito

      Outside the Linux realm, sh(1) is not bash(1), not even with bash in Posix mode. If you want to do such a temporyry fix, it's bash you need to relink to something professional, maintained and tested.

      Personally, I think it very poor to trick people into using bash (or any other shell) by linking the name they do want to bash. The web seems to have a lot of people wondering why bash(1) handles variable scope so oddly in loops. They must get really confused if they, after working on a real UNIX, specify sh or ksh and see the same behaviour because, invisibly, they are just using bash with some variables set.

      I wonder how many other such Linux-isms are lurking. Suppose I should do a find(1) across the various bin directories on a couple of Linux distributions.

      1. Raumkraut

        Re: @Eddy Ito

        > Outside the Linux realm, sh(1) is not bash(1), not even with bash in Posix mode.

        Even Debian (and by extension Ubuntu, etc.) has /bin/sh linked to dash (Debian Almquist Shell), and not bash.

        And I let them talk me into using CentOS for our servers. Shame on me.

      2. Eddy Ito Silver badge

        Re: @Eddy Ito

        There's no need to trick anybody. The user will still be using whatever shell is specified for their login, typically called out in /etc/passwd. They can chsh to any shell from ash to zsh or even fish anytime they like, assuming it's installed. In fact if you look at recent Debian or Debian based distro you'll see that bash is the default login interactive shell but /bin/sh is a symbolic link to dash.

        The thing is you're unlikely to find a regular Bourne shell on a Linux box at all because the Bourne shell was proprietary at the time. I understand the Bourne shell is now CDDL which, while GPL incompatibilities exist, I don't believe there is anything stopping someone from installing it much like zfs. Interestingly, it was the same copyright issue that led to the creation of ash with a BSD license.

  5. pierce

    this article says this is the third patch, but its apparently already incorporated in redhat's 2nd patch released last friday....

    $ foo='() { echo not patched; }' bash -c foo

    bash: foo: command not found

    $ bash --version

    GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)

    ...

    $ rpm -q bash

    bash-4.1.2-15.el6_5.2.x86_64

    (this on centos 6.5)

    1. Fred Flintstone Gold badge

      Yup, OSX is safe too if you have installed patch 54 (https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054), which was released late on the 27th of September. Otherwise you'll have to add patch 54, recompile and replace the binaries as before.

      From what I've seen, most HOWTOs on the topic have been updated to incorporate patch 54 - nice to see that people are on the ball.

    2. Doctor Syntax Silver badge

      @pierce

      The previous Debian patch also appears to have included this. I get the same response.

    3. Jim 59

      Agree here, already incorporated (Red Hat 6.5):

      $ foo='() { echo not patched; }' bash -c foo

      bash: foo: command not found

  6. Anonymous Coward
    Anonymous Coward

    And I thought that I would never see a bit of bash scripting on a mainstream site

    That is, if the Reg counts as such.

    Mines are already patched. But really, if this "allows remote code execution" is only applicable if you have open web services that spawn bash to serve remote requests, most desktop systems are unaffected. Which makes us the 1% feel very comfortable.

    1. A Non e-mouse Silver badge

      Re: And I thought that I would never see a bit of bash scripting on a mainstream site

      But really, if this "allows remote code execution" is only applicable if you have open web services that spawn bash to serve remote requests, most desktop systems are unaffected

      Oh boy no! This is what the fuss is about. Bash is used in *lots* of places in a *nix system and is exploitable in numerous ways because of it. There's a proof of concept here for attacking clients via DHCP.

      1. Anonymous Coward
        Anonymous Coward

        Re: And I thought that I would never see a bit of bash scripting on a mainstream site

        here's a proof of concept here for attacking clients via DHCP.

        For that to work, you need to have control of the DHCP server. If you have control of the DHCP server, then all the clients are fucked, regardless of OS.

        1. Anonymous Coward
          Anonymous Coward

          Re: And I thought that I would never see a bit of bash scripting on a mainstream site

          "For that to work, you need to have control of the DHCP server."

          It's easy to plug in one that responds fastest - or set one up on WiFi

          "If you have control of the DHCP server, then all the clients are fucked, regardless of OS."

          Not if they run say Windows - or anything that doesn't rely on an exploitable version of BASH. You might be able to do things to the traffic - but you won't automatically own the host!

          1. elip

            Re: And I thought that I would never see a bit of bash scripting on a mainstream site

            Huh? I think you missed the point. If your client is accepting leases from a rogue DHCP server, you're already MITM'ed; no need for a bash exploit when I own ALL your traffic.

            1. Anonymous Coward
              Anonymous Coward

              Re: DHCP

              There's a lot of wrongness in this thread!

              "no need for a bash exploit when I own ALL your traffic": Lots of people use a mobile device with an untrusted network. I don't expect my mobile device to be open to remote code execution just because I'm using it in a hotel, say, rather than behind my company firewall.

              However, it's not clear yet, at least to me, whether there are many (mobile) devices around that use bash as part of the DHCP client.

              1. elip

                Re: DHCP

                Hmm, I was addressing the rogue DHCP server threat. Nothing wrong in my statement. Guess the 'vote-down' brigade doesn't have an imagination. I guess I'll spell it out:

                "I don't expect my mobile device to be open to remote code execution just because I'm using it in a hotel, say, rather than behind my company firewall."

                I said "no need for a bash exploit when I own ALL your traffic"... nothing in there implies remote execution on your phone, though that too would be trivial to pull off. If I'm handing out leases to your device on an open network, guess what your device is getting for its DNS and gateway???? That's right, *my* hand-crafted DNS and router doing MITM on all of your traffic. From this position getting remote execution on your phone becomes simple, but why bother when I have access to all of your data sitting in the fuzzy cloud of the interwebs.

                1. Anonymous Coward
                  Anonymous Coward

                  Re: DHCP

                  So presumably you never use WIFI outside of your house, or office, for anything, elip, right?

                  And you don't use 3G / 4G either?

                  Because from your analysis, if you do, then "getting remote execution on your phone becomes simple" to any admin of those services ... I don't think you actually believe that though, do you?

  7. Anonymous Coward
    Anonymous Coward

    How it works

    The article would benefit from an explanation of what has been changed in bash.

    It looks as though an exported function called "foo" used to be exported by putting its definition in the environment variable "foo", but now it goes in the environment variable "BASH_FUNC_foo()". So bash no longer has to parse the value of an environment variable called HTTP_USER_AGENT, for example. So it's much safer.

  8. Icy North

    Foo - a short history

    Ah, the foo function.

    Students of computer history may know that this term derives from the Ancient Chinese word 'foo', meaning 'a chicken'. It has survived in such terms as 'egg foo yung' (egg of a young chicken), 'Fu Manchu' (tough chicken) and the martial art 'Kung Fu' (way of the chicken).

    The chicken was of course revered in Ancient China. Men would keep lots of hens as they believed their noise would make them grow wise.

    As Confucius once said: "Some men are wise, but some do not have a clucking foo."

  9. Cody

    replace with ksh? or zsh?

    Is that possible or advisable? Just uninstall bash and install one of these?

    1. Anonymous Coward
      Anonymous Coward

      Re: replace with ksh? or zsh?

      Yes...but any script the relies on bash-specific syntax. will bess in new-andunusual ways. Also, sone shell scripts call scripts of their own...by invoking ${BASH}…

      1. Anonymous Coward
        Anonymous Coward

        Re: replace with ksh? or zsh?

        Exactly. Unfortunately, Gentoo's package manager requires Bash, explicitly.

        1. Cody

          Re: replace with ksh? or zsh?

          Also, looking at zsh, that's a monster, just configuring it is a major challenge. Desktop Debian with the latest bash updates seems OK tested against the exploits so far.

  10. Anonymous Coward
    Anonymous Coward

    My first thought when this broke on reddit was to remove bash while the details were teased out on the live servers I'm responsible for and symlink bash to dash. Some quick testing revealed It promptly broke the apachectl package installed therein and stopped them starting up so I had to revert to the first patched version and apply the updates and we removed the cgi module functionality to try and minimise our exposure.

    The only real pain isn't the 3 fixes in a few days, thats bau and we should be pleased at the speed of response, its the devices that will never be fixed, network elements that the vendors haven't disclosed to their customers use a shell, cgi's running on little gui's etc.

    IIRC someone posted a few days back to full disclosure a poc example of a dhcp client p0wning the dhcp server if it ran bash as the shell, and that is far far far more serious and has massive ramifications for large corporate infrastructures as once you own the dhcpd server, you can then own any clients with bash installed who connect.

    The truth is we don't understand all the vectors enough to let the middle managers talk away the seriousness away, so the responsible course is just to fix everything asap.

    As for the windows is best tack, I remember sitting exposed for weeks with machines in a pool behind a f4 big ip load balancer being periodically owned while microsoft spent time frantically working on finding out exactly how the attacker was getting into our web farm and capturing his zero day. We'd take the infected machines down asap to try and stop the attacker realizing they were suceeding, and to avoid any bad press (el reg almost had us at one point, cough cough). The final week we ended up with a linux box serving a static version of the site while waiting for the fix. So be careful how you gloat or complain about the frequency of fixes. Lets just rejoice that we've been given the tools so quickly and move on and be professional.

  11. H.Winter
    Thumb Up

    I don't mind too much

    As long it's as simple as doing 'yum update bash' a few times until it's all over then I'm not too worried about this.

    1. Anonymous Coward
      Anonymous Coward

      Re: I don't mind too much

      You might want to get your head around this a bit better than that. Especially if you admin any business systems for a company who might not be impressed by you neglecting them.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019