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 …

  1. pierce

    bash is a bloated pig.

    most embedded devices use busybox, not bash.

    1. Anonymous Custard

      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

        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

      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

    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

    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

  13. Vociferous

    "since most of them can't be patched"

    What? Why wouldn't it be possible to patch most systems affected by the bug?

    1. Steven Raith

      Re: "since most of them can't be patched"

      Can you compile the update of Bash for a BT Home Hub, or do you have to wait for BT to push out a full firmware update?

      There's your answer, right there.

      1. This post has been deleted by its author

      2. Charles 9

        Re: "since most of them can't be patched"

        "Can you compile the update of Bash for a BT Home Hub, or do you have to wait for BT to push out a full firmware update?"

        Are we SURE this devices uses bash? As the article and several comments note, embedded devices are strapped for space and are more likely to use a compact implementation like that in busybox, which isn't affected. Other network-facing devices are just as likely to be running BSD than Linux, and BSD prefers the C shell csh (usually TENEX C Shell or tcsh) over the Bourne shell sh(and the bug in this case is specific to the Bourne-Again Shell bash).

        1. Steven Raith

          Re: "since most of them can't be patched"

          I heard it from a chum who has the technical nouse, career history, and - frankly - geeky interests that make me look like a casual observer. He might be wrong but I'd be surprised!

          Still, even if the BT Hubs aren't affected, I'm sure there are some embedded devices that are, and the point still stands that updating those will be a mighty pain in the arse.

  14. Phil Stark

    cPanel's defaultwebpage.cgi not vulnerable

    Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable by this exploit. It is not written in bash and does not make any calls to bash.

    If you have evidence to the contrary, or are aware of any other CGI scripts distributed by cPanel that are vulnerable we would greatly appreciate it if you'd open a ticket with us with this information:

    http://tickets.cpanel.net

    Thanks!

    Phil Stark

    Technical Support Supervisor

    cPanel, Inc.

  15. Phil Stark

    cPanel defaultwebpage.cgi vulnerability

    Our internal testing showed that /cgi-sys/defaultwebpage.cgi was not vulnerable by this exploit. It is not written in bash and does not make any calls to bash.

    If you have evidence to the contrary, or are aware of any other CGI scripts distributed by cPanel that are vulnerable we would greatly appreciate it if you'd open a ticket with us with this information:

    http://tickets.cpanel.net

    Thanks!

    Phil Stark

    Technical Support Supervisor

    cPanel, Inc.

  16. Jim 59

    Graham's blog says many "internet of things" devices will be vulnerable and will remain so because they can't be patched. They may be vulnerable, but not to this bug. As 'tards have pointed out, IP cameras etc. aren't equipped with Bash, why would they be ? Embedded stuff, even more substantial items like NAS boxes routers, come with Busybox only.

    Also. Errr. Isn't Graham breaking the law in rather an extravagant way by blithely scanning thousands or organizations ? Notwithstanding his good intentions.

    1. Jason Bloomberg Silver badge

      As 'tards have pointed out, IP cameras etc. aren't equipped with Bash, why would they be ? Embedded stuff, even more substantial items like NAS boxes routers, come with Busybox only.

      Would you bet your life on either of those claims?

      It might feel true, and I suspect most likely don't use bash, but it's not guaranteed to be true and we have no idea how true it may be.

      1. GX5000

        Yes, assuming isn't a good security protocol is it ? :)

      2. Jim 59

        Yes, I pretty much would bet my life on webcams et al not using bash, for sound economic/engineering reasons. Bash is a big, big program and needs a full computing environment to run. The binary alone is over 1 MB, almost twice the size of Busybox. Even a quiescent bash instance takes several MB of memory to run, plus many libraries, plus all the other programs the user will call. Manufacturers use Busybox because it replaces all that. I have never seen an embedded device that had standalone Bash. Big NAS boxes conceivably, but I have never seen it.

        The bigger danger is web servers. I saw Graham's shellshock scan at 8:20 this morning in my logs, and patched the server an hour ago. And devices like Raspberry Pi's where the user has it internet facing for

        Bigger items

        On the other hand, internet facing NAS devices might

        systems would be out of business.

        To run it, the IP webcam would have to be running a full linux kernel/environment and have

        1. Jim 59

          @Jim 59

          Bigger items ...other hand ...business ... etc. etc.

          Maybe scroll yer edit window chap. This ain't vi.

          1. e^iπ+1=0

            Re: @Jim 59 ain't vi

            wtf is wrong with vi ffs?

            :wq

  17. Zog The Undeniable
    Happy

    My netbook running Linux Mint got a bash patch delivered to it yesterday. I only noticed because it came on its own, without updates to any other system software.

  18. Alistair
    Windows

    shell shocked admins?

    I think I've got my head wrapped around the worst of this one:

    a) in the case of ssh calling bash, this is not an issue until after authentication has completed, ie, you cannot (at the moment at least from what I've read and tested) *spawn* a shell without completing the authentication process. -> no open sewer there that would have opened a pit to hell.

    With ssh the issue is the "ForcedCommand" functionality - authentication completes, and with some creativity a user COULD pass in a function definition that would spawn them a shell.

    I've about 40 of these accounts out there and I don't know about anyone else, but I wipe the environment at the top of the script intentionally ... and then parse the hell out of the command coming in to make sure it qualifies.

    b) HOWEVER - in cases where services are exposed to the network, where those services *can* accept input from outside, and where those services then *can* call or invoke a shell with that input (unchecked) -

    You haz a great big cheezburger.

    So - at least in my *managed* apache environments we don't allow cgi, and php is heavily limited, we don't have any *screaming* issues -- I've found a couple of things that made me go *ick* but nothing terrifying.

    I don't do the DHCP, but its on BSD and should not have an issue

    things like weblogic and jboss at this point make things in my gut go ickky. I seem to recall an input in Java 1.5.(something) that could be used to fork a shell out of a jvm.....

    We have a few "packaged" apache solutions. *sigh* no comment. 3rd party vendors getting calls to investigate those.

    Last check of the patched RH systems indicates that the issue is not 100% resolved yet - and my fedora systems arent fixed yet either. Its gonna be a hella long weekend for some admins.

    1. Destroy All Monsters Silver badge
      Paris Hilton

      Re: shell shocked admins?

      I've about 40 of these accounts out there and I don't know about anyone else, but I wipe the environment at the top of the script intentionally .

      I understand that at this point it's too late?

      I seem to recall an input in Java 1.5.(something) that could be used to fork a shell out of a jvm.....

      No. You need to run

      Process p = Runtime.getRuntime().exec("bash -c '" + injectCommandLikeABeachedWhale() + '");

      1. Alistair
        Windows

        Re: shell shocked admins?

        I understand that at this point it's too late?

        I suppose that depends on what you do to strip it - check your sshd_config for AcceptEnv objects.

        I accept that not everyone is running sshd updated for that - but in our case we are.

      2. Alistair
        Windows

        Re: shell shocked admins?

        -- Process p = Runtime.getRuntime().exec("bash -c '" + injectCommandLikeABeachedWhale() + '"); --

        Thanks for that -- playing with it now.

  19. Justin Case

    I may be being stupid here

    But I was always told that if you absolutely had to allow a webserver access to a bash script or built in function then you should really completely sanitise what you send it. That is, only allow that which should be allowed. So if people are getting bitten on the backside by this then it must be sloppy practice on their part?

  20. Nuno trancoso

    Re: I may be being stupid here

    Not so much but then again yes.

    The problem is not that you know you have to sanitize input so much as having to know WHAT to sanitize it against. Or to make it more clear, to avoid passing inputx, you first have to know inputx was bad news. And unless you can convince me that you are aggressively (re)parsing and conforming your input, which i doubt anyone is, guess what, you're doing the basic checks just like everyone else, and this will go though.

    Can't resist the temptation to bash the zealots (pardon the pun). So, again, there goes the many eyes theory down the drain... The reverse on the contrary is quite true. Once you get many "bad eyes" looking at you, the nasty water starts popping out of the sewer lid.

  21. Anonymous Coward
    Anonymous Coward

    What about Windows

    We are running all Windows Servers (2008 and 2012). I'm assuming we're okay?

    1. Alistair
      Windows

      Re: What about Windows

      if you have bash installed in there anywhere, you'll want to patch it.

      And yes, I have windows servers with bash that have to be patched. Its not available yet but it will be out soon.

      1. Anonymous Coward
        Anonymous Coward

        Re: What about Windows

        In particular, if you're running Windows sensibly, you're probably running Cygwin, hence bash.

    2. Anonymous Coward
      Anonymous Coward

      Re: What about Windows

      We are running all Windows Servers (2008 and 2012). I'm assuming we're okay?

      Yes, *bash* isn't going to be your main worry, you have bigger problems :p

      1. Anonymous Coward
        Anonymous Coward

        Re: What about Windows

        "you have bigger problems :p"

        Like thinking what to do with your weekend while your servers patch themselves like clockwork once a month....

  22. Anonymous Coward
    Anonymous Coward

    Smartphone vulnerability?

    There's been mention of a potential vector for iPhones using DHCP; I guess the BSD DHCP client supports a way of receiving environment variables from the server, so a rogue DHCP server could potentially be set up.

    Does Android also use bash? I assume there are no external ports open, so I can't think of any way this could be exploited. It would be fairly nasty if it could, given that most Android devices wouldn't be updated.

    1. Alistair
      Windows

      Re: Smartphone vulnerability?

      hmmm.

      Cyanogen 11.2

      /system/xbin/bash.

      /wanders off to go fiddle some more --

      (for the record, most versions of weblogic have some sort of sanity checking for data strings, but if you happen to *know* the checking done....... it can get ugly fast.)

      <edit>

      Damn. I can point out that bash on Cyanogen 11.(2) is vulnerable as far as the default test goes.

      </edit>

      1. Charles 9

        Re: Smartphone vulnerability?

        "Cyanogen 11.2

        /system/xbin/bash."

        This appears to be specific to custom ROMs. Mine's a lightly-touched TouchWiz job, and bash is missing from it. Which lends credence to my supposition that most Android installs lack bash and are thus safe for now.

        1. Alistair
          Coat

          Re: Smartphone vulnerability?

          I was being fairly specific -- I've rooted my phone and put Cyanogen on it - I checked the other 4 phones in the house last night.

          a) default shell in all cases is /bin/sh - not bash.

          b) bash is present on my Cyanogen unit *and* on the moto (on the moto, it *might* have been installed by an app the young fella installed)

          *and* Cyanogen pushed an update last night that has the *first* patch to bash.

          Rooted iphone has something *called* bash on it but it does not appear to be a binary.

    2. Charles 9

      Re: Smartphone vulnerability?

      I may be wrong, but I think Android's default is the basic Bourne Shell sh. Bash has to be explicitly installed, and I think that takes a rooted phone. Since sh isn't robust enough to be vulnerable to the same problem as bash, most Android implementations should be safe. Besides, most Android rooters tend towards Busybox, which is also safe.

  23. Anonymous Coward
    Anonymous Coward

    so this affects like.... two people?

  24. Jim 59

    Saw Graham's shellshock scan on my server logs at 8:20 this morning UK time. Patched now. Those guys at Debian work fast.

  25. Richard Tobin

    Stupidest bug ever

    How can anyone have thought it was a good idea to parse arbitrary environment variables to see whether they contain something that looks like a function definition?

    1. Anonymous Coward
      Anonymous Coward

      Re: Stupidest bug ever

      Passing function definitions via environment variables is a useful feature for an interactive shell and this feature is not disabled by the recent patches. The security problems are not caused by that but by a combination of several other things:

      1. Bash immediately executes commands found in arbitrary environment variables.

      2. This bug/feature was not documented.

      3. The CGI standard uses environment variables for transmitting client data to CGI scripts.

      4. Some people have used bash for CGI scripts and the like, either deliberately or accidentally.

      Arguably there is a pervasive problem of programs invoking shells in various unclearly documented circumstances. For example, under what circumstances does Perl's system() function invoke a shell? Does "ssh user@host command" use a shell for interpreting the command, or doesn't it? If you're not an experienced hacker you probably can't answer those questions with great confidence in the correctness of your answers.

      1. Gordon 11

        Re: Stupidest bug ever

        For example, under what circumstances does Perl's system() function invoke a shell?
        When it is passed a string containing active shell characters.

        Which is why you should always invoke it with an array, as that will always fork()+exec() and, of course, read documentation, which is where this is mentioned.

    2. stephanh

      Re: Stupidest bug ever

      Apparently the idea is that you can export a function, like you can export a variable (meaning it gets inherited by subshells). The function body is then communicated through an environment variable.

      Example:

      $ function foo { echo hello, world; }

      $ export -f foo

      $ tclsh # since bash doesn't show the magic variables...

      % set env(foo)

      () { echo hello, world

      }

      1. Richard Tobin

        Re: Stupidest bug ever

        Using environment variables to export functions is not a stupid idea. Doing it in such a way that every variable gets interpreted as a function if it looks like one *is* stupid. A program's environment variables can contain any text; it's none of the shell's business if that text happens to start with certain characters. They could perfectly well have used a single variable with a defined name that contained all the functions, or they could have used, say, BASH_VARIABLE_foo for the function foo.

  26. Anonymous Coward
    Anonymous Coward

    First Heartbleed...

    ...now this. Linux is dead. Time to get actual professionals in.

    1. John Sanders
      Linux

      Re: First Heartbleed...

      This is a problem of bash, the heartbleed was a problem on openssl.

      Linux is just a kernel.

      See I can troll too!

  27. Anonymous Coward
    Anonymous Coward

    OSX fix didn't take long

    That's the nice thing about an OS that at least borrows from Open Source in a way that keeps it usable - it took all but 4 minutes to pull in the updated bash code, recompile it and replace the exposed binaries.

    1. This post has been deleted by its author

  28. eulampios
    Stop

    Too much ado about almost nothing...

    It's pretty bad and embarrassing that the popular Shell is capable of this unintended stuff. However, if you're writing a script you would be able to do all the "scary" things the proper way already. As far as things CGI, every shell is not the safest language by its nature and should not be used for this risky business. It's a SHLELL of the system, not a webserver "shell". The article reiterates this known for ages postulate. Shell doesn't have the power nor the convenience of the more capable languages like perl, php, python etc.

    Moreover, taking input from a stranger is dangerous already and asks for trouble. Proper tools and checks are to be in place to minimize the likelihood of this. Single quotes in Perl is one solution, not a panacea though, if an input is still blindly passed to operators, say, you can get ddos'ed by feeding it too big of a number or too long of a string, than you intended those to be, if the latter is not being properly checked.

    So again, a shell should not have been used in cgi, other potential explorations, like embedded devices, are pretty questionable, as many commenters have said above. Busybox is what is used there for default shell. I got Tomato usb Netgear router here and installed bash on it, the version of which is vulnerable. However, one can talk to it via ssh and web interface within the local network only. The latter is protected by password, the former -- by ssh key. cgi doesn't use bash, the admin panel of the web interface does take the system commands there, which was intended to be so already.

    Next "shockingly sensational" news please...

    1. eulampios

      Re: Too much ado about almost nothing...

      Okay, I see someone's already downvoting it. Since it's not being explained, I get it's one of the alarmists out there, either an ignorant or an anti-open source, anti-Linux shill.

      1. Nuno trancoso

        Re: Too much ado about almost nothing...

        Now you have two, but you get the benefit of an explanation. This is NOT a problem with the exposure method, be it CGI or whatever. It's a problem with Bash not properly parsing vars. Trying the "it's not supposed to be used for" defense is just about as good as Job's "you're holding it wrong" stunt... A spade is a spade and a vulnerability a vulnerability.

        And your comment only proves that Open Source has long moved from a "philosophy" to a religion, shock full of dogmas and unwilling/unable to face (even substantiated) criticism. and like a "good" religion, you obviously must be "right" thus can do no wrong. And along comes the usual "it's not important/relevant/substantial" excuses zealots, especially the devs, are so fond of.

        Grow up, a turd is a turd, and if you call it an OpenTurd it still won't smell like roses :)

        1. eulampios

          Re: Too much ado about almost nothing...

          >>This is NOT a problem with the exposure method, be it CGI or whatever. It's a problem with Bash not properly parsing vars.

          We must be reading different articles. What you're talking about is the original article about the GNU Bash bug. This one about the inexorable, inevitable doomsday awaiting the humanity due to the affect on cgi. This is a vulnerability affecting all those abusing shell in places it didn't belong even without a single vulnerability as well as might cause some local problems and break local scripts.

          >>..as good as Job's "you're holding it wrong" stunt...

          It would be my job to correct you your apostrophe as well as observe that you either reading my comment from the right to the left or looking at the wrong article.

          >>And your comment only proves that Open Source has long moved from a "philosophy" to a religion, shock full of dogmas and unwilling/unable to face...

          Can't talk on behalf of the whole FOSS or OSS. Common sense is my religion, calling spade a spade, or overly-sensational journalism overly-sensational is one of my dogmas, when I am not too lazy.

          >>Grow up, a turd is a turd, and if you call it an OpenTurd it still won't smell like roses :)

          Not sure about your age, yet judging from "Grow up" there is a high chance I had grown up long before you were born.

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

Other stories you might like