back to article Bash bug: Shellshocked yet? You will be ... when this goes WORM

Much of the impact of the Shellshock vulnerability is unknown and will surface in the coming months as researchers, admins and attackers (natch) find new avenues of exploitation. The vulnerability, called Shellshock by researcher Robert Graham, existed in the Bash command interpreter up to version 4.3 and affected scores of …

Page:

  1. pierce

    bash is a bloated pig.

    most embedded devices use busybox, not bash.

    1. Anonymous Custard Silver badge

      I'm currently helping beta-test a new OS version for a NAS box from a well-known vendor which is BusyBox based, and we had a report from another tester overnight indicating that it too was vulnerable (at least if I'm interpreting his report correctly - I'm not a Unix guru but the test code is repeated in some of the posts below so I think it is the same item).

      So running busybox might not mitigate things quite so well, unfortunately. But I can see it's going to be worth checking myself tonight to confirm.

      1. Jaybus

        BusyBox

        Hard to say. BusyBox uses the Almquist shell (ash), initially a clone of the System V.4 Bourne shell and was developed for BSD versions of Unix. GNU Bash was hand coded by the Free Software Foundation back in the 1980's and has nothing to do with ash other than both were designed to run existing (at the time) Bourne shell scripts. That said, the current crop of one-liner tests for the bug are designed to test whether or not the version of Bash that you are using is vulnerable, NOT whether ash is vulnerable. Make sense?

    2. Anonymous Coward
      Anonymous Coward

      "when this becomes a worm "

      Yep - this one could beat the Morris Worm as the worst ever!

    3. This post has been deleted by its author

  2. Daniel B.
    Boffin

    Oh $!#t.

    $ bash -version

    GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)

    Copyright (C) 2007 Free Software Foundation, Inc.

    So we all OSX users are screwed?

    1. Flocke Kroes Silver badge

      Depends...

      If there was some way to remotely pass environment variables through bash, then yes, you might already have been screwed. I would expect that there is a patched version available for OSX by now. Go find it.

    2. vagabondo

      Re: Oh $!#t.

      "So we all OSX users are screwed?"

      Depends. A security patch may have been applied without upgrading the bash version. I do not use OSX, so do not know how their security patch policy works.

      On my systems (openSUSE):

      $ env x='() { :;}; echo "vulnerable"' bash -c 'echo "hello"'

      vulnerable

      hello

      -- sorry about the extra line-feeds added by El Reg.

      and

      $ env x='() { :;}; echo "vulnerable"' bash -c 'echo "hello"'

      bash: warning: x: ignoring function definition attempt

      bash: error importing function definition for `x'

      hello

    3. Charlie Clark Silver badge

      Re: Oh $!#t.

      bash -version

      GNU bash, Version 4.3.25(1)-release (x86_64-apple-darwin13.2.0)

      But then again I use MacPorts to manage most of my command line stuff as you can't rely on Apple to update the stuff.

      1. iWiring

        Re: Oh $!#t.

        Using MacPorts (or Hoebrew) doesn't protect you against this in any way. First, bash isn't normally replaced with MacPorts, you'd have to explicitly include it in MacPorts. Moreover, since you or some user must explicitly enable MacPorts for use by some specific user - and hopefully never root or system users - everything else is still using the distro bash, e.g. cron, apache, anything other than users relying on MacPorts. So you're still left with a vulnerable bash even if you have MacPorts.

        1. b166er

          Re: Oh $!#t.

          I picked a bad day to quit amphetemines

    4. Dan 55 Silver badge

      Re: Oh $!#t.

      You'll have to wait for a security update for OS X. They usually bundle several up and release them every quarter or so so as not to scare the fanbois. Yay Apple.

      But I don't think it will affect anyone unless they're using OS X Server facing the Internet.

      1. Semtex451 Silver badge

        Re: Oh $!#t.

        I picked a bad day to quit smoking

        1. Skyraker

          Re: Oh $!#t.

          I picked a bad day to quit sniffing glue.

          1. Paul Crawford Silver badge
            Trollface

            Re: Oh $!#t.

            I picked a bad day to quit trolling.

      2. Anonymous Coward
        Joke

        Re: Oh $!#t.

        "But I don't think it will affect anyone unless they're using OS X Server facing the Internet."

        Well that's going to scare all two of them.

      3. Brewster's Angle Grinder Silver badge

        Re: Oh $!#t.

        "But I don't think it will affect anyone unless they're using OS X Server facing the Internet."

        Until it skips through the firewall on a vulnerable device.

        1. John Hughes

          Re: Oh $!#t.

          What service do you have listening for TCP calls that will run a bash script with an environment crafted by the caller?

          Why would anyone do such a weird thing?

          1. Destroy All Monsters Silver badge
            Paris Hilton

            Re: Oh $!#t.

            What service do you have listening for TCP calls that will run a bash script with an environment crafted by the caller?

            Why would anyone do such a weird thing?

            Everybody who uses old-school CGI or anybody who hacked some stuff back in 2000 on the quick?

            1. Michael Wojcik Silver badge

              Re: Oh $!#t.

              Everybody who uses old-school CGI or anybody who hacked some stuff back in 2000 on the quick?

              CGI is the obvious vector, but others include programs that invoke system(3) with insufficiently-vetted attacker-supplied data, if bash is the shell for the account that program runs under. Advisories have mentioned some dhcpd configurations, for example (though I haven't looked at the sources to confirm the vulnerability).

              It's also possible to set environment variables with typical telnetd and sshd implementations. Again, I haven't personally tried to exploit Shellshocked through one of those, but I wouldn't rule it out without investigation.

              Security protection for environment variables has typically been done by blacklisting (e.g. prohibiting setting PATH and LD_LIBRARY_PATH in sensitive environments) or whitelisting (programs will only set particular variables). It's rare to have programs that do support setting environment variables actually put much effort into vetting the supplied values.

          2. Anonymous Coward
            Anonymous Coward

            Re: Oh $!#t.

            In the old days, it was quite common for web servers to implement "dynamic" web pages by receiving a request over TCP, parsing the request parameters and set one environment variable for each (in the form of BLAH=FOO), and then launch some program. The program wrote its response on standard output, and that's what the web server sent back to the client. Later on it was codified as a standard as CGI-something (or similar)

            The nature of the vulnerability is that if that if the program your web server is launching is bash, you have a huge problem because you can craft a request that will execute bash commands when bash is parsing its environment variables.

            Of course, that's only one of the pieces of the puzzle. If the web server is properly configured the commands will not be able to alter the environment outside the context of the user that is running the web server process. But it is enough to sniff local files accessible to the web server, for example. Additional security layers may or may not mitigate the impact, but it the problem is potentially serious enough to be concerned.

            Running bash scripts to process requests on a web server is 1980-era software design that is in dire need of an upgrade anyway, not only for security reasons but also because web software has evolved a lot since then. You have much better ways of doing it, either with less memory, CPU or with more functionality.

            But there could still be machines out there doing this, perhaps sold as appliances that never upgrade themselves, that are vulnerable. I can only speak for myself, but certainly I haven't seen such a beast in ages.

            1. Gordon 11

              Re: Oh $!#t.

              Running bash scripts to process requests on a web server is 1980-era software design
              Given that the ability didn't start until the early 90's it will be 1990-era software design.

              Some of us can still remember when CGI handling was first added to the NCSA httpd code (and also when the entire source code first passed 1000 lines!).

            2. Destroy All Monsters Silver badge
              Coat

              Re: Oh $!#t.

              Running bash scripts to process requests on a web server is 1980-era software design that is in dire need of an upgrade anyway

              Doc Brown, you need more jigawatts!

              I know that for some Gulf War I was before they were born, but still!

              1. GX5000

                Re: Oh $!#t.

                When you realize it's been twenty seven years and the guy next to you started two years ago and is VERY opinionated. Yeah, sniff the glue.

            3. Jaybus

              Re: Oh $!#t.

              This won't be a huge future problem for dynamic content on web servers, since they will be patched readily. Most have probably already been patched. The problem is that CGI is used in the web interface of many current devices, such as routers, switches, security cameras, etc. It will be months before all of these are patched. Still, those sort of devices are not usually directly accessible from the internet. I don't look for this to be a huge problem going forward. I worry about the fact that this bug has been in place for decades. Has someone been exploiting this for decades without detection?

  3. Anonymous Coward
    Anonymous Coward

    When do the films come out?

    "Shell Shocked", "Heartbleed" ??!

    What's next?

    "Firewall of Death"

    "Microshaft"

    "aPColypse now"

    "TellallNet"

    "Bay of Pings"

    I mean since the big IT players have had films about them/being made about them, I suppose it is only natural that these kind of things are next.

    1. Destroy All Monsters Silver badge

      Re: When do the films come out?

      "Smoking Hashroom"

      "Randthrax Attacks"

      "Illegal State of Siria and the Login"

    2. I ain't Spartacus Gold badge
      Coat

      Re: When do the films come out?

      When the attack is specially crafted to put porn on church websites: Bashing the Bishop

      Then they'll try to hack the Coronation Street child stars in: Bash Street Kids

      After which an attack will be crafted for London and Essex called: Bish Bash Bosh

      At some point there must also be an attack on Bashar Assad...

      [I'd best get my coat hadn't I]

    3. John Gamble
      Happy

      Re: When do the films come out?

      Ooooh. I like "Bay of Pings".

      Please somebody, find this vulnerability, as soon as possible.

      1. Anonymous Coward
        Anonymous Coward

        Re: When do the films come out?

        I suppose it could be the title of an eBay denial of service attack?

      2. PeteA
        Coat

        Re: When do the films come out?

        Sounds like the follow-up to "Ping Flood"... do we need to negotiate royalties? Maybe work "Ping of Death" into the franchise too...

  4. Flocke Kroes Silver badge

    Important, but easily fixed

    You do not need to get you vendor to tell you if you are affected. Just type:

    x='() { :; } ; echo shellshockable' bash -c 'echo test'

    If you updated your software last night (this morning for Rasbian) you will get:

    bash: error importing function definition for `x'

    My router says:

    /bin/sh: bash: not found

    Embedded systems often use one of the trimmed down shells available with Busybox. Ash and lash are not vulnerable.

    This is important, as CGI passes parameters to through the environment, CGI scripts can be written in bash and it is easy to install vast amounts of software on a Linux system, some of which might still use '90s tech because it did not break every time a vendor required their users to buy an upgrade. If you need to test some embedded system without any obvious access to the shell, try a google search for your device's name with the word 'telnet'. If you actually find one that uses bash, and the vendor does not have new firmware ready by tonight, look for a replacement that can run openwrt.

    1. Phil Endecott Silver badge

      Re: Important, but easily fixed

      > My router says:

      > /bin/sh: bash: not found

      Just to be sure, try replacing 'bash' with 'sh':

      x='() { :; } ; echo shellshockable' sh -c 'echo test'

      (You'll probably find that your router is still safe.)

  5. TrevorH

    Even the fix is flawed... CVE-2014-7169

    1. Destroy All Monsters Silver badge
      Trollface

      Damned bash who does it work?

    2. Anonymous Coward
      Anonymous Coward

      Thanks for the heads up on the flawed fix TrevorH. RedHat have an advisory here.

      Looks like a bit of a fustercluck.

  6. tony2heads
    FAIL

    "The use of shells for CGI was discouraged since the mid 90s."

    Who the hell sets up servers allowing bash to be available.

    There are chroot options, restricted shell options and other sandboxing if you NEED a shell at all.

    1. Destroy All Monsters Silver badge

      Re: "The use of shells for CGI was discouraged since the mid 90s."

      Yes, yes, yes.

      In other news, homeopathy is still a hot topic.

  7. DrXym Silver badge

    Not as serious as openssl issue

    Hearbleed affected lots of software, many of which may have shipped with modified versions of the openssl library or statically with it.

    This is bash. One patch and the entire system is fixed. On top of that I suspect the number of webservers with externally facing and exploitable cgi scripts that ran bash and where an environment variable could be injected in some way is rather low. It's probably a greater threat from internal users who might be able to exploit an ssh session or a restricted shell in some way.

    But again it's one patch and I suspect most dists already have the patch ready to go.

    1. Anonymous Coward
      Anonymous Coward

      Re: Not as serious as openssl issue

      Heartbleed could allow you to disclose system information which then allows you a direct attack vector.

      This IS a direct attack vector and not just via unpatched webservers. All very well saying a patch will sort it, but there have already been reports of tools like massscan being used to exploit machines.

      I would bet that more machines are compromised because of this and the highly public nature surrounding it than because of heartbleed.

    2. Flocke Kroes Silver badge

      Lots of sites have man-pages

      The first google search I tried, three of the first four sites use a CGI bash script to return search results for man pages. Those sites either have already, or urgently need to replace bash.

    3. Jason Bloomberg Silver badge

      Re: Not as serious as openssl issue

      It's not simply "one patch" if the system is embedded and everything boots from on-board flash chips. Those can be very difficult to patch and especially if the manufacturer has deliberately made it that way.

      Desktop systems and the like probably can be easily patched, it's the billions of routers and IoT-type devices which are the big risk.

      1. Anonymous Bullard

        Re: Not as serious as openssl issue

        If it's embedded then it most probably won't have bash

  8. John Sanders
    Mushroom

    Some people does not get it.

    The CGI vector is one of possible vectors, anything that creates or invokes a sub-shell is at risk if that sub-shell is bash.

    With such a hole in bash parsing I'm sure that someone with more imagination and more free time than me will find creative ways to exploit plenty of systems, not just those that run CGI's on a web server.

    The patch is straight-forward people, go and patch!

  9. MacroRodent Silver badge

    Too pessimistic

    "Scan your network for things like Telnet, FTP, and old versions of Apache (masscan is extremely useful for this). Anything that responds is probably an old device needing a bash patch.

    This looks like alarmism. As others have noted, embedded Linux systems usually use Busybox. Even if the shell feature from Busybox is not used, some light-weight alternative to bash as the system's /bin/sh is likely.

    In addition, many network devices run some variant of BSD, which has never had bash as the default shell.

  10. Chris--S

    Ok, it's early and I haven't finished my coffee yet. Isn't this an injection vulnerability due to not escaping the remote input before using it to set the environment variable?

    What is crafting the command which is setting the env with a function using the remotely supplied value?

    1. Flocke Kroes Silver badge

      It is nastier than that

      Using the CGI attack vector, the web server will un-url-escape a string I supply and put it into an environment variable. The CGI script is expecting an unescaped string, so the standard does not provide a way to prevent my choice of string going into an environment variable.

      Bash provides a mechanism to export bash functions to a bash sub-process. Bash assumes any environment starting with '() {' is a function. Defining a bash function is part of the bash language, and bash uses the bash interpreter to convert the environment variable into a function definition. The bad news is that the interpreter did not stop at the end of the function definition. Extra text in the environment variable after a function definition gets interpreted just like a bash script.

      If a web server has a vulnerable version of bash, and a CGI script either written in bash or using a bash sub-process that receives the CGI environment then remote users can execute their own bash scripts with the authority of the web server.

      The obvious places to prevent this are any of these:

      *) make bash stop interpreting function definitions at the end of the function definition.

      *) use something like fastcgi which passes parameters through file descriptors instead of environment variables.

      *) Do not write write CGI scripts in bash AND ensure that the environment is sanitized before starting a bash sub-process.

    2. amanfromMars 1 Silver badge

      Some Cream for that Coffee.

      Ok, it's early and I haven't finished my coffee yet. Isn't this an injection vulnerability due to not escaping the remote input before using it to set the environment variable?

      What is crafting the command which is setting the env with a function using the remotely supplied value?.....Chris--S

      An irregular and unconventional intelligence somewhat greater than the norm and for/from future operations rather than from/for past systems in present race overlode conditions/critical situations seems most probable and likely however inconvenient that might be to current executive admins. Chris--S.

      I wonder if Kevin Mitnick is selling it? ....... `http://www.wired.com/2014/09/kevin-mitnick-selling-zero-day-exploits/

  11. This post has been deleted by its author

  12. John Sanders
    Unhappy

    It seems the patch is not quite there yet...

    Not a definitive patch yet.

    https://bugzilla.redhat.com/show_bug.cgi?id=1141597

Page:

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