The Shellshock Bash bug - What is it, and are your computers vulnerable?

ShellshockA critical vulnerability has been discovered in the widely used Bash command processor, present in most Linux and UNIX distributions and Mac OS X.

The US Department of Homeland Security's CERT team has issued an alert about the Bash bug (known as CVE-2014-6271, but also given the more media-friendly moniker of "Shellshock" by some), and warned that if exploited the vulnerability could allow a remote hacker to execute malicious code on an affected system.

One serious concern is that malware authors could exploit the vulnerability to create a fast-spreading worm - taking advantage of the ubiquitousness of Bash.

If such a worm materialised it would, without question, make the Bash bug a more serious threat than the HeartBleed OpenSSL bug that impacted many systems earlier this year.

The fundamental difference is that the Heartbleed bug allowed unauthorised parties to spy on computers, whereas the Shellshock Bash bug allows attackers to hijack computers, and use them for their own purposes.

In a nutshell, the Shellshock Bash bug is easy to exploit and yet still have severe consequences.

Are your computers vulnerable?

Fortunately, there's an easy way to tell if your computers might be at risk.

Open a terminal window and enter the following command at the $ prompt:

If you are not vulnerable, then the following will be shown:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

But if you are vulnerable, then you will see:


Test run on a vulnerable computer

Remember, even if you have never heard of Bash before, or don't run it, you may very well have software running on your computer which spawns Bash processes.

Links to patches for some operating systems are listed on the US CERT alert page. Fingers crossed that more are forthcoming soon, including patches for OS X - as manual recompiling of Bash will be beyond many users' capabilities.

No doubt IT teams are going to be busy for the next few days, scrabbling to check whether internet-facing computers running Linux are at risk from the Bash bug, patching systems where possible and taking steps to mitigate against threats.

Further reading:

Tags: , , , , , ,

Smashing Security audio podcast
Check out "Smashing Security", the new weekly audio podcast, with Graham Cluley, Carole Theriault, and special guests from the world of information security.

"Three people having fun in an industry often focused on bad news" • "It's brilliant!" • "The Top Gear of computer security"

Latest episode:

Subscribe to the free GCHQ newsletter

, , , , , ,

24 Responses

  1. Haxton Fale

    September 25, 2014 at 11:48 am #

    Unfortunately, the already deployed patches don't fix the vulnerability entirely:

    More extensive patches are being worked on, I suspect.

  2. Ahmed Amin

    September 25, 2014 at 3:51 pm #

    How does it work?

    • Coyote in reply to Ahmed Amin.

      September 28, 2014 at 12:30 am #

      I'll give it a stab. The trick is whether or not the way I describe things will work with you. But this is the idea, anyway. I'll break each part of it… apart (that is just who I am…). I worked with this in a text editor to try to eliminate my typical elaboration (that interestingly makes things harder to understand when the intention is the opposite…) Summary is at the middle but I admit I think in a very different way from most people, and combined with really enjoying this type of thing, it makes for … confusing wording, much of the time (hence having the summary).

      env is program that allows modification of the environmental variables for a command. Those variables are actually used by some programs (and yes, there are inherent risks but Unix was never designed with security in mind, just like the Internet's predecessor and itself, I might add). This also allows emptying the environment (option -i). If you type 'env' by itself it shows
      environmental variables the shell has.

      The shell allows functions to be defined and in fact used as commands. But that isn't the issue
      here. What should happen as given, is that you define x to be '() { :;}; echo vulnerable'
      as an environmental variable, and then run bash with the command 'echo hello'. But the way it
      processed it ( ; allows ending one command and entering another on the same line so indeed
      the function could have had more than one command but is irrelevant. The : is a no-op) it instead defined the function but ran the command after the function. You could make it so the function is actually defined outside of a variable and usable as a function, to see what I mean:

      $ x() { echo test;}; x

      (functions are more powerful than that but I'm trying to, after multiple revisions of this,
      keep it as concise and precise as possible).

      bash -c allows running a specific command(s), in a new process (contrast to the
      shell that creates another).

      SUMMARY: Basically, it didn't stop after the function's definition and instead went on to run other commands (but during defining the function). If you were to leave out the ; bash -c … part, you'd see the current environmental variables, including the definition of x, when both bugs are fixed, just like if you type: env by itself (less the variable you define in the test above).

      There's actually more to the entire thing (context allows not seeing an error that is actually there, otherwise, unrelated to the bug). I initially had information about it but I cut it out for reasons given above. Either way, hopefully that makes sense to you, and hopefully I'm clearer than I actually feel (as in, hopefully I didn't write something completely stupid.. which is absolutely possible. It is something I'm experienced with and I indeed fully admit this.. and laugh about it, too).

      As for this flaw, it is an old type of flaw and one that will again show itself, much like it has now. It will always be serious, too.

  3. Spryte

    September 26, 2014 at 12:31 am #

    I remember reading about something similar (perhaps) involving BusyBox… (another popular Unix/Linux shell).

    I am no Unix expert, but I do know different shells are available (ZShell for instance).

    Would a simple fix be to change one's default shell program?

    • Coyote in reply to Spryte.

      September 26, 2014 at 7:56 pm #

      busybox is special. It is a statically linked shell (which means if the administrator makes a mistake or the more rare botched update to a library, it can still be used but with a restriction) for certain commands. Commands that used to be statically linked to begin with. So no, busybox is not so much a popular shell for general use. Basically, it is for rescuing a system. And to answer your question, no, it would not fix it necessarily because of the way shell invocation works.

      Specifically, in the older days I used ksh (korn shell) and also tcsh (turbo c-shell, as the original c-shell was horrible). bash is bourne again shell (which is an extension of the bourne shell). Well, all I would need to do is spawn a session of the other shell. For example, right now my server (scrap that, some of these I removed as I don't use… actually only have these installed on main system because of nostalgia) indeed has tcsh. So:

      $ /usr/bin/tcsh -c 'echo $0'
      (hope that shows up fine).
      The shell I used to invoke that was indeed bash.

      • Coyote in reply to Coyote.

        September 26, 2014 at 7:57 pm #

        (and yes, it showed up fine, just to confirm…)

      • Clive Darke in reply to Coyote.

        September 27, 2014 at 9:08 am #

        A couple of things: tcsh is the Tenex csh, Tenex was an old version of UNIX.

        More importantly, the shellshock bug affects some Korn shells as well, notably Sun's XPG4 version which allows function exports (tested). So far as I can tell, the current AT&T korn shell is OK, since it does not support function exports.

        • Coyote in reply to Clive Darke.

          September 28, 2014 at 1:47 pm #

          Thanks for that. I honestly wasn't sure if it was indeed turbo c-shell or not (it was a vague memory at best).

          And I am not surprised that other shells are affected. As I pointed out, the semi-colon is not exactly shell specific and neither is any thing else. Very useful that you suggest (and tested) the others (good on you for reporting). I don't use korn shell anymore because I used it in my SunOS days and well, may as well call it Oracle OS now… and besides, the UltraSPARC I had access to (a long time friend's … he had two or three of them… but hasn't had them powered on for years and years). You have AT&T Unix or is it that you have the original version of the shell in question?

          Thanks again for correcting me (I almost checked in to it but well, forgot). I know that is for some people unthinkable, but Coyote is not infallible and knows it is best to be corrected when incorrect (and not only is it best, I want to know regardless because why would I want to incorrectly report something?).

          • Coyote in reply to Coyote.

            September 28, 2014 at 1:50 pm #

            .. and actually, just after I posted that, Tenex C shell now rings a bell (the rhyme I swear, is not intentional, for once)… Thanks again.

    • Coyote in reply to Spryte.

      September 27, 2014 at 3:03 pm #

      Two other things came to mind but I was unable to get to them until now.

      First, as for busybox, as I described earlier, it is invoked like (If I recall):
      busybox command arg1 … argN

      and aside that, it is as I put it: to rescue systems or otherwise not rely on shared libraries (this is what the so stands for files that end in .so or .so.1 [as two examples]). Files ending with the .a are archives which is to say not shared libraries but neither of these are the same as statically linked binaries (a statically linked binary has everything it needs, in the binary, so as to have no external dependencies). Binary, which are actually known as text files (this might seem odd, especially to Windows users, but it is lower level – machine level, in other words – that defines this.. and actually in Unix and its derivatives, there isn't a real difference between binary and text) are programs themselves where as libraries are used IN (or if you prefer, BY) programs.

      Second, and most importantly, lots of things require bash (indirectly and otherwise), including kernels (which is the core of an operating system, and in fact Linux is the kernel of an OS hence why there is Red Hat Linux, Debian Linux, Gentoo Linux, Linux From Scratch, … Rock Linux, and many others), so it isn't a matter of just removing bash (you'd have a lot of issues). And if you were to prevent bash from being executed, you would risk a lot of problems and likely break your system (especially if you forgot that root is using bash … and you aren't logged in with some user that can su to root and therefore specify shell … assuming there even is another valid shell[1]). And default shell, unfortunately has little matter in this bug. But here's the real thing: even IF changing your shell was able to work around the problem, you're then ignoring the flaw which is dangerous, very dangerous indeed. You should never leave something that has a fix, left unfixed. That is a dangerous game.

      [1] /bin/sh or otherwise /usr/bin/sh is nowadays a symlink (sym = symbolic) to /usr/bin//bash which means what used to be bourne shell (sh) is now typically bash, even if invoked as sh.

  4. Gilbert Dion

    September 26, 2014 at 1:22 am #

    I ran the test on the computer at work, and it failed, ie it was not vulnerable. I ran it at on my home computer and it showed that it was vulnerable. Both are running Ubuntu 14.04. I wonder what's the difference between them?

  5. Gilbert Dion

    September 26, 2014 at 2:01 am #

    Well, I have the answer to my question. A simple update did it.

  6. A

    September 26, 2014 at 9:05 am #

    You say it is easy to determine whether one's computer has this problem. It would be easy if I knew what "open a terminal window "meant, and what the "$ Prompt "is. I am competent computer user but what goes on inside the computer is mostly a mystery to me. Please could somebody re-explain this process using language that ordinary people will understand? Thank you.

    • Graham Cluley in reply to A.

      September 26, 2014 at 9:16 am #

      I'm going to assume you're running Mac OS X.

      You can find the Terminal app in your Applications/Utilities folder.

      Alternatively, here's a video showing how to run it.

      • A in reply to Graham Cluley.

        September 29, 2014 at 7:48 am #

        What a nice clear answer. I did just that and discovered that I am vulnerable. In fact I wouldn't be surprised if it's too late as I did notice my little green video light on one day all on its own.
        What do I do? I have switched it off, disconnected my external hard drive and am changing all my passwords. Is Apple anywhere nearer to producing a fix?

        • Coyote in reply to A.

          September 30, 2014 at 1:49 am #

          Did Apple not yet release the fix that the developers already pushed out days ago? Again?

          Either way, as for your issue: it is unlikely the problem here. That isn't to say you shouldn't ignore it but it this is probably one of those ".. this recently was made public and suddenly X is happening… surely it is related" kind of fear. It is more like: this is made public and I am NOW noticing MORE things (that I don't normally pay attention to).

          What is your 'green video light' ? That would also help determine whether it is related or not (what it is and how it can be controlled, specifically). While it certainly isn't impossible and while it certainly shouldn't be dismissed, desktop users are less affected here, at least risk wise (certainly having no public services will lessen the impact).

          ANSWER: what you do is practise safe computing like always, be cautious when you don't know what something is, be cautious (and suspicious! it isn't really suspicion though) whenever you are using your computer (don't absentmindedly click on something, don't believe everything you read/see/hear (actually that is a good idea whether you are using your computer or not!) or.. you get the idea). This includes, mind you, keeping your system up to date.

  7. David Fremlin

    September 26, 2014 at 7:01 pm #

    I tried your command
    env x='() { :;}; echo vulnerable' bash -c 'echo hello'
    and got just
    with no complaint about function definitions. Does that mean all is well?

    • Coyote in reply to David Fremlin.

      September 26, 2014 at 11:00 pm #

      Yes. In fact, that is what you want (there are two bug fixes).

      • David Fremlin in reply to Coyote.

        September 27, 2014 at 1:09 pm #

        Thank you!

        • Coyote in reply to David Fremlin.

          September 27, 2014 at 3:05 pm #

          You're very welcome! While what Graham shows is better than having neither fixed (and therefore showing that they're vulnerable), it is of course better to have all bugs fixed, and that is what you have.

          … Glad I could help.

  8. Coyote

    September 26, 2014 at 8:30 pm #

    Graham, actually, that is somewhat incorrect. There's two bugs here. The first one is if you have another CVE patched (there was a recent bash update, before this, actually) that prevents the exploit from working but it still isn't everything fixed. The test you give should actually show:

    and that's it. I guess this is what Haxton was getting at (didn't look).

  9. Lawrence

    September 27, 2014 at 12:34 am #

    I ran the test above and failed (i.e. "vulnerable").

    I ran the test from PC World and passed:
    $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
    -bash: $: command not found

    I'm not a Unix guru. What gives?

    (MBP mid 2010 2.53 GHz Intel Core i5 OS X 10.9.4)

    • Coyote in reply to Lawrence.

      September 28, 2014 at 10:15 pm #

      You don't see vulnerable on the second one because there is an error you're getting in the output (the $: command not found). The reason is you by mistake copied the $ (that is the prompt). And since that is there it didn't even evaluate the rest. Try without that. And oh, update regardless because arbitrary command execution is very risky… you have no idea (well, maybe you do ..) how much it has been abused in the past. It is an ancient type of flaw and it is incredibly … well, just put it this way: you don't want any security risk there but this type is a serious one indeed.

      • Coyote in reply to Coyote.

        September 29, 2014 at 12:57 am #

        (Just to elaborate: you don't see vulnerable because there is an error IN the command itself. The error produced is what you see instead. The error is the prompt was actually pasted to the command line whereas Graham did not include it). $ has other uses to make it more complicated but I'll spare you the details. Whenever you see $ in the context as given it will unless specifically mentioned (the other meanings I refer to), will be the prompt (and it is shown to indicate where you type it rather than it being part of the command).)

        Either way, update bash as soon as you can.

Leave a Reply