back to article Stunned by Shellshock Bash bug? Patch all you can – or be punished

The UK's privacy watchdog is urging organisations to protect their systems against the infamous Shellshock vulnerability in Bash – even though the full scope of the security bug remains unclear. The Shellshock flaw affects Bash up to and including version 4.3. It's a vital component of many Linux and Unix systems, as well as …

  1. Anonymous Coward
    Anonymous Coward

    Take a closer look at that TrustSec proof-of-concept:

    https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/

    That's an evil DHCP server sending shell script to the client, which will get executed under root (if the dhcpclient is configured to use bash at all)

    So may be a rather bigger attack surface than just "LOL! Lame CGI!" - what other services have helpful extensions like this?

    1. pompurin

      So if I replaced the echo 'foo' command with rm -rf /, a DHCP server could essentially wipe out any linux machine that requested an IP address which runs bash.

      1. Anonymous Coward
        Anonymous Coward

        Stunned by Shellshock Bash bug? Patch all you can – or be punished

        "So if I replaced the echo 'foo' command with rm -rf /, a DHCP server could essentially wipe out any linux machine that requested an IP address which runs bash."

        dhcpclient normally runs as a daemon under the root user ... which almost never has bash as its shell. Solaris has the good old bourne shell (sh) for its root user. Linux doesn't have a bourne shell, so its root user runs the Korn shell instead, in bourne shell mode.

        This is mainly because the bourne shell is statically linked, so still functions if your system is b0rked and half your file system isn't mounted.

        Only interactive users tend to be configured with bash ... but you find a lot of sysadmins have set up web service daemon logins which are configured with bash because they're used to running it as their interactive shell and write scripts using bash syntax and builtins which aren't available in Korn shell.

    2. John Deeb
      Boffin

      Mongo: "That's an evil DHCP server sending shell script to the client,"

      That's a disturbing application of the shellschok misfeature. I might change my mind on the scope now.

      Then again, this example is then also about the insecurity of DHCP client-server model (unauthorized DHCP servers being a well known and unpatched attack vector). Plus the proof of concept will probably work only with the DHCP client using the dhclient-script process (written by Ted Lemon). For some reason they found it nice to pass parameters to the subprocess by setting environment variables. It's the naive, 80-90's somewhat lame but also consistent "CGI approach" -- deeply embedded (in my view) in some of the UNIX philosophy of the time: everything a file, composite approach, interconnecting well made general tools through simple, transparent mechanisms, etc. But it makes it too easy to trick as well ("worse is better?") with all the current day security challenges.

  2. Anonymous Coward
    Anonymous Coward

    smtpd

    Well, if the mail servers are found to be at risk, all hell will be let loose.

    This could be really bad. Time to fire up the ZX Spectrum I think.

  3. BongoJoe

    Revenue

    So, whilst being thorough in one's investigations and not download the first patch that one comes across could well lead to one being fined.

    Sometimes I think that these bodies are all about revenue gathering rather than being there to provide advice and support to those who need it.

    Not everyone who hosts a server, this could be anyone on the end of a fixed IP address (and in fact not necessarily that), has the knowledge to understand all this stuff but enough to host their own stuff and threatening them with fines isn't really the way forward.

    1. John Brown (no body) Silver badge
      Thumb Down

      Re: Revenue

      I think you'll find the people they are "threatening" with fines are those operating within the confines of the Data Protection Act. ie those who may be allowing personal data to be stolen if they don't patch up as soon as possible once suitable patches are available.

  4. Anomalous Cowturd
    Alert

    CVE-2014-7169 patched today on Ubuntu.

    Was flagged as a partial fix.

    CVE-2014-6271 was patched a couple of days ago.

    Patch hasn't made its way upstream to Debian yet. :o(

    1. Flocke Kroes Silver badge

      CVE-2014-7169

      Was fixed on Debian and Rasbian before this article appeared.

      Anyone vulnerable embedded system? My TV and router do not have bash installed.

      1. Anonymous Coward
        Anonymous Coward

        Re: CVE-2014-7169

        How did you check your TV? I have a 'smart' freeview+ box, and can't get into it, so no way of checking. Mind you, it isn't Internet facing and runs off my DHCPD server so is not an attack vector.

        1. Flocke Kroes Silver badge

          Checking the TV

          I did a web search before purchase and picked one that was hackable. There is a magic sequence of buttons on the remote control that gives you the service/retail menu. One of the options enables shell access on a serial port on two unused pins on the VGA input. Just solder a VGA connector to a 3.3V serial to USB converter, plug it into your Pi and start miniterm. I picked an old TV, so most of the work had already been posted on the internet already. Take a look here to see what sort of things are available.

          I strongly recommend searching for a hackable device before purchase - especially for long lifetime items like a TV. If you cannot recompile and install the firmware yourself then you are dependant on the vendor producing patches. Plenty of vendors think that ending support for a product is a good way to force users to buy a new toy. Just imagine how bad things would get if computers used secure boot so people could not install their own BIOS...

          1. Anonymous Coward
            Anonymous Coward

            Re: Checking the TV

            Ahh, thanks - good plan. I will keep that in mind in the future.

            Also reminds me of the Hewlett Packard 486's in the early 90's that had passworded BIOS so the user couldn't mess about, and the Compaq models that had non-standard sized floppy discs and shit so you couldn't replace anything from off the shelf, but had to pay £50+ more to get a Compaq one :)

      2. This post has been deleted by its author

      3. Eddy Ito

        Re: CVE-2014-7169

        Debian and Rasbian use dash not bash by default so a default install wouldn't have a problem. Similarly busybox, which is often used in embedded systems, uses ash so no problem. It would only be when one has specifically configured one of these systems to use bash where they would have a problem.

  5. Anonymous Coward
    Anonymous Coward

    what else lurks

    After heartbleed and now this, which was apparently lurking in plain sight for 22 years, one has to wonder what else can be found in long-trusted code. I would imagine miscreants will be paying a lot more attention than before to common open source software as it seems it could be rather fertile ground for exploits that have long been overlooked.

    1. Zippy's Sausage Factory
      Windows

      Re: what else lurks

      ...and what is lurking supposedly more safe closed source code, like Windows, that we don't know about - and probably are never going to find out about, either?

      1. Anonymous Coward
        Anonymous Coward

        Re: what else lurks

        I am loath to say it - but Microsoft's 'security through obscurity' might be a better option sometimes. But as you say, how many 1000's of exploits are in their code that will never be patched.

        At least the *nix guys have started to fix this within hours of the first post.

        1. Anonymous Coward
          Anonymous Coward

          Re: what else lurks

          "Microsoft's 'security through obscurity' "

          Microsoft have never taken that approach.

          "how many 1000's of exploits are in their code that will never be patched."

          Statistic show that the quality of Open Source code is generally no better than commercial code, and often much worse. Open SSL springs to mind...

      2. Craigness

        Re: what else lurks

        "and probably are never going to find out about"

        That's a bad thing?

    2. tfewster

      Re: what else lurks

      bash is like a gun - powerful and dangerous, but fairly safe if kept in a locked cabinet ("Authentication"). If you leave it lying around or your kids get the keys to the cabinet, bypassing the safety mechanisms - Then you have a problem!

      John Leyden, thank you for describing it as "vulnerability" or "flaw" rather than a bug in bash

      1. Tom 38

        Re: what else lurks

        bash is like a gun - powerful and dangerous, but fairly safe if kept in a locked cabinet ("Authentication"). If you leave it lying around or your kids get the keys to the cabinet, bypassing the safety mechanisms - Then you have a problem!

        The problem with shellshock is that this is true, but bash was not being kept in the cabinet - most Linux distros use bash as their shell interpreter "/bin/sh" which means that every single time you invoke a command using the shell, it invokes bash. Most other UNIX like operating systems do not use bash as their "/bin/sh", they use "sh".

        The attack vectors for shell shock involve passing spurious environment variables to bash - Linux servers that invoke CGI shell scripts are particularly vulnerable, because the CGI spec specifies that arguments are passed as environment variables, making it trivial to provide a URL argument - without authentication - that triggers the parsing bug (and it is a bug, bash executes commands that it should not. There is expected behaviour for this scenario - ie it is not the result of undefined behaviour - and bash fails to meet the expectation. Classic bug).

        1. m4r35n357 Bronze badge

          Re: what else lurks

          No they don't

          1. itzman

            Re: what else lurks

            Indeed. All debian derived stuff uses dash by default and bash only for user console work and you can fix that in /etc/passwd

        2. Anonymous Coward
          Anonymous Coward

          Re: what else lurks

          "most Linux distros use bash as their shell interpreter "/bin/sh"

          WTF? When did they change that?? Just checked a RedHat system I develop on, and you're quite correct ...

          /bin/sh -> bash

          Last I knew, /bin/sh was symlinked to the Korn shell on Linux. /bin/sh is supposed to be a statically linked binary so you can rescue your system without all the shared libraries available.

          FFS.

          1. Anonymous Coward
            Anonymous Coward

            Re: what else lurks

            "most Linux distros use bash as their shell interpreter "/bin/sh"

            ...which is why I use FreeBSD instead, which doesn't have this insanity.

      2. Anonymous Coward
        Anonymous Coward

        Re: what else lurks

        "bash is like a gun - powerful and dangerous"

        Windows has a much more powerful scripting language than BASH in Powershell - and that's secure by default - it will only run signed scripts remotely. So I guess following your analogy - a heavy machine gun / grenade launcher - but locked in a gun safe. A much higher level of security that BASH could clearly benefit from...

    3. Brian Miller

      Re: what else lurks

      Well, the attack is based on a feature of Bash. This means that it's been "out in the open" for the entire existence of the feature, not hidden as an oopsie-daisy bug in the source code. It also points out why it's a bad idea to have so much running with root permissions, besides not sanitizing input. And why it's a bad idea to allow just any server to throw whatever traffic it likes out onto the network.

      The equivalent on a Windows system would be to pass in PowerShell script and .NET binaries through the http request, and then run it all with Administrator permissions. Attacks like these should be in the category of GET root!

      1. Uffe Seerup

        Re: what else lurks

        > Well, the attack is based on a feature of Bash.

        No - it is a *bug*. The ability to define functions in env vars was the feature. The unintended consequence of using a poorly implemented parser was that it proceeded to *execute* text that may come *after* the function definition in the env var.

        > This means that it's been "out in the open" for the entire existence of the feature

        Nope. Nobody ever considered the possibility that extraneous text following such a function definition would be executed *directly*. At least, we *hope* that it was the good guys who found this first. But we really don't know.

        > It also points out why it's a bad idea to have so much running with root permissions, besides not sanitizing input.

        Yes. And why SUID/setuid is such a monumentally bad idea. It is a deliberate hole in a too simplistic security model.

        > The equivalent on a Windows system would be to pass in PowerShell script and .NET binaries through the http request, and then run it all with Administrator permissions.

        Not sure I agree. That is such an obviously bad idea that nobody would ever do it. Shellshock is - after all - a bug (unintended behavior). However, there are multiple historic reasons on Unix/Linux that tend to amplify this bug:

        1: The (dumb) decision to use env vars to pass parameters through the Common Gateway Interface (CGI). Env vars are stubbornly persistent: They are inherited by all child processes. This serves to make security auditing much harder: You cannot simply audit the script that *received* control directly from CGI; you also has to consider all processes that can ever be launched from the script, its child processes or descendants.

        2: Inadequate and too restrictive Unix security model. This led to the invention of SUID/setuid (a hole in the security boundary) because there were still a lot of tasks that "plain users" (or least privilege daemons) legitimately needed to perform - such as printing, listen on sockets etc. Rather than refining the security model, SUID punched a deliberate hole in it. However, this means that user accounts are frequently not granted rights to access a *resource* or a syscall - rather they are granted right to launch an *executable* (SUID) that will execute with an effective user (often root, sadly) who has access to the resource. Which means that you have created a culture where you all but *need* to launch processes through system() calls to get the job done. With a proper security model where such right could be *delegated* you would not have to invoke external executables.

        3: Old software that lingers on even in modern operating systems. It has long been accepted that the bash parser is, well, quirky. The way that it is semi-line oriented, for instance (definitions only take effect on a line-by-line basis). Today, parser construction is under-graduate stuff, all the principles are well known. The bash code in question was written in another era and by another community where those principles were perhaps not as well known as they are today.

        1. Anonymous Coward
          Anonymous Coward

          Re: what else lurks

          >1: The (dumb) decision to use env vars to pass parameters through the Common Gateway Interface (CGI). <

          I tried to convice the openVPN people that internal use of environment variables to run executables on Windows was a known security flaw, which could lead to unintended consequences if an exploit was developed. They weren't convinced.

          I think that perhaps the idea of using environement variables was too deeply embedded in the culture.

  6. Dylbot

    Posted this on another article but it warrants repeating. I'm seeing a spike in phishing emails from obviously compromised domains today, enough that a couple has slipped through the net and one of the clients is now being cleansed by PXE fire after contracting a bit of ransomware. Might be a good time to remind the prolies that nobody sends confidential finanicial information in a link to an obscure building contractor's website, and that clicking links in emails that are obviously sus is grounds for cruel and unusual punishment.

    1. Hargrove

      @Dylbot

      . . . clicking links in emails that are obviously sus is grounds for cruel and unusual punishment.

      Dylbot is spot on. Clicking on these links is the IT equivalent of engaging in unprotected sex with monkeys.

      However, as the US CAN-SPAM regulations are implemented in practice, this is exactly what the recipients of SPAM and phishing e-mails are expected to do to "opt" out unsolicited e-mails.

      This points up the insanity of relying on badly worded laws and even more arcane and convoluted regulations to address real technical problems.

      As a side note, my personal take is that the US FISMA puts any chance of serious computer security into the "too-hard-to-do" box. It effectively requires constant patching and updates of programs by third party vendors. These are invisible to most small and medium business users. (Being proprietary, they are also invisible to most system administrators.) This deprives the business users at the application level of essential knowledge of the configuration and functions of the system.

      1. Anonymous Coward
        Anonymous Coward

        Re: @Dylbot

        The f* impossible to comply (ITC) defense.Embedded and appliance business users should have no problem there -- at least in court. But that'll be cold comfort when all your customers leave in anger because they have no one else to blame. IT is a swamp. Appliances are sinkholes masquerading as bridges. It isn't the public's fault that modern day snakeoil sales go unregulated -- except to the degree that they keep electing legislatures who are too stupid, lazy and greedy to deal with the problem.

  7. This post has been deleted by its author

  8. Hargrove

    A discouraging trend. . .

    "This flaw could be allowing criminals to access personal data held on computers or other devices. For businesses, that should be ringing real alarm bells, because they have legal obligations to keep personal information secure."

    This article points to a discernible trend on the part of governments and regulators to push responsibility legal liability for information security to the average business user. . .the vast majority of whom are categorically incapable of effective action.

    These "legal obligations" and the threat of action against businesses who fail to maintain security beg several critical questions. . . How do the average small to medium-sized business, running out-of-the-box consumer software and dependent on commercial internet service providers determine their vulnerability? What practical steps can they possibly take to ensure that they can demonstrate due diligence in a court of law when held liable?

    Finally what, if any, responsibilities do the big IT companies, special interests, legislators, and regulators--all of whom are in a position to address the issues and all of whom in some tangible or intangible way profit from the status quo--bear.

    1. Anonymous Coward
      Anonymous Coward

      Re: A discouraging trend. . .

      Good point - usual software disclaimers are like this:

      This is *free/MS* software with ABSOLUTELY NO WARRANTY.

      So _who_ is responsible?

      1. Anonymous Coward
        Anonymous Coward

        Re: A discouraging trend. . .

        in a logical world, the person who takes the money for the product.

        This isn't one of those worlds.

        The govt can leave social security / criminal record data lying around for anyone to grab whenever they want, but know beyond doubt that they don't pay any fines or face any real sanctions themselves (when was the last time you heard of a civil servant being held personally liable for fines?), and yet can threaten small organisations with all kinds of things from behind their safe "someone else will pay-"wall.

  9. Anonymous Coward
    Anonymous Coward

    How decisions bite you on the ass

    The shop I work in used to be just FreeBSD. When I started about ten years ago, the boss was still insisting that everyone use csh, and I threw a fit - "This is the noughties, we have bash and it is good!". He relented, and we got bash rolled out everywhere as an optional shell.

    This week, he has absolutely loved it - "It's all your fault BOY" he thundered from across the room. I did have to point out that actually we still aren't exposed as all our scripts are still sh and not bash, and remember all those new linux servers you bought because you won't pay enough for FreeBSD administrators, they're ALL vulnerable.

    How he remembers who proposed installing a package 9 years ago when he can't remember approving new SSDs for our DB servers last week...

    1. Anonymous Coward
      Anonymous Coward

      Re: How decisions bite you on the ass

      Um... isn't /bin/sh linked to /bin/bash?

      1. Jan 0 Silver badge
        Coat

        Re: How decisions bite you on the ass

        @theodore > Um... isn't /bin/sh linked to /bin/bash?

        Simplifying: Only on systems that don't have the Bourne shell installed.

        Because Bash is considered to be a superset of Bourne, many OS distributions assume that genuine Bourne shell scripts will run perfectly if passed to Bash. In which case they dispense with Bourne shell. That seems to be how most Linux distributions treat the Bourne Shell. /bin/sh is not a link to /bin/bash on the OS X 10.9.5 system that I'm typing on and although the executables are the same size, they're not identical. However the /bin/sh does allow me to assign an array variable, so it probably is bash. In Solaris up to version 10, /bin/sh is the Bourne shell, whereas in Solaris 11 it's linked to ksh93! A proper Bourne shell is still available: /usr/sunos/bin/sh. I'll get my coat before this delves into every Unix variant!

      2. itzman
        Happy

        Re: How decisions bite you on the ass

        Um... isn't /bin/sh linked to /bin/bash?

        Not on any of my systems, no.

        /bin/dash on all systems I control.

    2. PJI

      Re: How decisions bite you on the ass

      Be careful. Asses kick and bite back.

    3. Anonymous Coward
      Anonymous Coward

      Re: How decisions bite you on the ass

      I did the same thing around that time, except our O/S platform was Solaris. All those systems have been replaced by now of course -- by Red Hat Linux. Guess who was the most vocal advocate of that change?

  10. wyatt
    Facepalm

    We're getting support cases raised by companies asking if this is an issue, when we say 'no' they then ask for it in writing.. Even though they're running Microsoft OS's..

    1. Anonymous Coward
      Anonymous Coward

      Just tell them they already have the patch, its called Windows ;)

    2. Justicesays
      Alert

      And this is a problem why exactly?

      So, just tell them in writing it's not vulnerable? Or better yet put a message somewhere on your main support site...

      And, just because they are running windows, doesn't mean they are not vulnerable to stuff embedded in products.

      Which is easier when making your previously UNIX only product run on windows, re-write all your scripts in powershell or compile and ship a bash interpreter for windows and just change some paths...

      Cygwin based services can use bash, including apache with cgi etc.

      These things can happen in the real world.

      1. Hargrove

        Re: And this is a problem why exactly?

        People usually want things in writing to document a legal position. My concern would be that if a variant of the attack to which they were vulnerable emerged, the customer might claim that they were damaged by relying on faulty information.

        The fact that the advice might have been right at the time may not hold up, if the customer trots out a parade of "experts" to testify that the emergence of a Windows threat was reasonably predictable.

        @jJusticesays's point about things happening in the real world, is correct--and the technical thrust of the post is sound. The concern is that the legal system is often ill-equipped to sort out the complex technical arguments when litigation is the thing that happens.

    3. PJI

      You're mistaken

      Running Windows is no protection if you run a bash shell under it, either directly or via Cygwin, for example, I assume.

      It's not the operating system. It's the shell programme and the web server software.

      Has anyone proved bash is the only shell that has this behaviour (older implementations)?

      Regarding the chap asserting that sh is a link to bash: only on Linux unless your friendly SA has copied this on your OS X or Solaris or AIX or BSD.

  11. John 104

    @Hargrove

    Dylbot is spot on. Clicking on these links is the IT equivalent of engaging in unprotected sex with monkeys.

    Er, Um. Are you implying that there is an IT equivalent of engaging in protected sex with monkeys?

    1. nsld
      Coat

      Re: @Hargrove

      I believe that's outsourced to "management consultants"

      1. Hargrove

        Re: @Hargrove>@nsid

        My sense of obligation to come up with a witty rejoinder has been blown out of the water by @nsid's response. In all seriousness, arguably the perfect humorous response. Worthy of Scott Adams.

        I am humbled by the presence of greatness.

  12. Anonymous Coward
    Anonymous Coward

    BBC factual as ever

    "Apache system, software which includes the Bash component." ... errr ....

    "Unix is an operating system on which many others are built, such as Linux and Mac OS" ... errr ....

    and this gem:

    "That such key parts of everyday technology are maintained in this way is a cause for concern, said Tony Dyhouse from the UK's Trustworthy Software Initiative."

    This, from a man who can't even maintain his own profile on the UK's Trustworthy Software Initiative's website.

    Next we'll have the Beeb saying that PwC are nice, kind and considerate people for stealing iPhone prepayments from Phones4U customers while also publishing the email addresses of the affected people.

  13. Anonymous Coward
    Anonymous Coward

    Meanwhile on Solaris

    [~]=> bash --version

    GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)

    Copyright (C) 2004 Free Software Foundation, Inc.

    [~]=> env X="() { :;} ; echo busted" /bin/sh -c "echo completed"

    completed

    1. John Deeb

      Re: Meanwhile on Solaris

      AC, I'm pretty sure Solaris 10 has the Bourne shell as default. Your example should not invoke "/bin/sh" then.

  14. This post has been deleted by its author

  15. synonymous cowherd

    embedded

    I'm patched ... phew!

    GNU bash, version 4.3.26(1)-release (x86_64-unknown-linux-gnu)

    Copyright (C) 2013 Free Software Foundation, Inc.

    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

    This is free software; you are free to change and redistribute it.

    There is NO WARRANTY, to the extent permitted by law.

    -`NO WARRANTY` :P

    Uh Oh, what about my router? That's *nix, let's hope it's busybox. TaDahh! We now have 'Security by assumption'

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