Bash Bashed

Bourne Again Shell is in the news, in a bad way:“CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection.”
Of course, I’ve known not to use BASH for CGI for ages but that this bug has been around for years is really shocking. If anything should have been secure it should be the basic scripting interpreter for GNU/Linux systems. I use dash on some systems but bash is widely used. SSH is also vulnerable but as I’m the only one allowed to use it here, I should be safe barring mental breakdown. A patch is on the way

See Patch Bash NOW: 'Shell Shock' bug blasts Linux, OS X systems wide open.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology and tagged , , . Bookmark the permalink.

44 Responses to Bash Bashed

  1. DrLoser says:

    (Technically, you are indeed still vulnerable with FastCGI if the application in question calls system() or some such thing. In practice this falls into the category of Mr Pogson’s “only 3000 out of tens of millions,” because I have a hard time imagining that any vulnerable HTTP element containing the exploit will pass straight through to the shell. It’s theoretically possible, but not something to lose sleep over.)

  2. DrLoser says:

    Debian uses dash as the default shell for users but a CGI script or any other application can use BASH.

    Good point, Robert. I think we’ve reached some sort of agreement here.

    You did, however, miss the essential absurdity of Joe.M‘s claim. And I’m not talking about describing the original form of CGI as “vanilla,” which is a term that more precisely applies to FastCGI.

    Thing is, and as far as I am aware, there are no bindings to FastCGI for any shell of which I am aware. Since Shellshock, as one might guess from the name, is a shell exploit, this renders Joe.M‘s hilariously badly informed suggestion entirely moot.

    Unless, of course, Joe.M is prepared to take on the task of porting a Bash-based CGI script to a Perl … Python … C/C++ … even Pascal … equivalent.

    Which would obviously be considerably more difficult than a simple port from Bash to Dash.

    Where do you find these people from, Robert?

  3. Joe.M wrote, “you are not vulnerable to this is you are using FastCGI instead of vanilla CGI, or if you are using Debian or Ubuntu (which use dash insteas of bash)!”

    Debian uses dash as the default shell for users but a CGI script or any other application can use BASH.apt-cache rdepends bash
    bash
    Reverse Depends:
    foomatic-filters common-lisp-controller votca-csg-tutorials votca-csg-scripts txt2regex s3dvt rdup prey powerline podget plowshare4 origami netscript-ipfilter netscript-2.4 monotone mason lrzip linux-patch-debianlogo libbash kernel-patch-viewos inxi gt5 git-ftp foomatic-filters foomatic-db-engine firehol fiaif fadecut |emacs-goodies-el devscripts-el dpatch diffmon common-lisp-controller colortest biabam bashburn bash-completion bash-doc bash-builtins backupninja autojump kernel-patch-atopcnt kernel-patch-atopacct

    Bash is an essential package on Debian GNU/Linux systems. Attempting to delete this package summons a stern warning…

  4. Joe.M says:

    You are not vulnerable to this is you are using FastCGI instead of vanilla CGI, or if you are using Debian or Ubuntu (which use dash insteas of bash)!

  5. DrLoser says:

    Nope, I have a few scripts that don’t work with dash.

    Then rewrite them, particularly if they are only “a few.” This is the precise reason why RMS insists on open access to the source.

    Don’t know why. Don’t need to know.

    By the same token, how do you know they’re doing the right thing, if you don’t bother examining them? Taking it on trust, again. I see no difference between this and using proprietary, closed, software.

    I just keep them on BASH. There’s no benefit to the world in figuring that out.

    Actually, there is. Given one shell with proven security vulnerabilities, and another without, which one do you think is more suitable for the world to use?

    I sense your laziness and total lack of curiosity getting in the way of your usual altruism here, Robert.

    That’s been done already.

    Er, what? Debian are talking about a default shell here. As you have pointed out yourself, the default shell doesn’t help at all when running a script with a hash-spling-bin-bash at the head. Are you saying that because your system integrator of choice is too lazy and slipshod to deal with the obvious security implications, it behoves you, too, to be equally as lazy and slipshod?

    Well, your choice, I guess.

    There’s no need for dash to be identical to BASH. Then it would be just as slow and bloated …

    Slow and bloated and prone to disastrous security holes?

    If I didn’t know better, Robert, I’d think you were talking about Windows 98.

    Not the “default shell” for Debian Lenny.

    Obviously it’s easy to slip into the habit of being satisfied with “slow, bloated, and totally insecure.”

  6. oiaohm says:

    Robert Pogson I do agree that there are side effects to implementing systemd or openrc. Some parts expect the bad behavior of seeing the environmental vars from other services start up scripts.

    Some of the extra errors from systemd is the fact that the early kernel errors are in fact logged that under sysvinit just got lost and never picked up by syslog solutions. Some of the other extra logging is the fact systemd has truly cgroup wrapped and is able to catch error messages and direct them into the right log so you can see them. Both of these case its not that the error messages were not happening just prior to systemd you were not getting the reports.

    once even prevented some systems from booting for want of speed of logging.
    This is kinda true and false. Systemd debug option turned on Linux kernel debugging option to report everything and the result was failure of the in kernel logging system. The problem of course could have been triggered on a sysvinit system if someone asked the Linux kernel from kernel command line to report all debugging messages. So that one was a case of opps we found a hidden bug that no one has noticed because no one not even kernel developers turn on debug all. Why did systemd developers want to turn on kernel all debuging is provide better reporting. Testing processes of the Linux kernel have changed slightly since. The Linux kernel has got a little smarter on deduplicating and compressing in memory log and even at worst making the true and correct selection to dispose of log and report as such so booting can happen if worst happens. In fact a large number of the systemd errors are in fact conner cases that effect sysvinit solution that no one has noticed other than people trying to fix obscure problems.

    People attempting to fix obscure problems in some drivers were turning all kernel debug option and not putting 2 an 2 to come up that the lock up happening was coming from the kernel logging system instead thinking the lockup was coming from the unstable driver timing being disrupted by logging. Yes lot of drivers have got fixed since systemd broke the kernel logging system resulting in proving it was the kernel logging system with a bug.

    Systemd is a fairly drastic change I agree. Problem is a lot of the pain we are feeling from change to Systemd are in fact hidden bugs that have been biting a minority.

  7. oiaohm wrote, “Some of the complaints about systemd spreading all over the system is clean up of shell issues.”

    I switched most of our PCs to Debian Jessie when it looked like the bug-count would slide down to zero in a couple of months. Then, about the time they decided to go with systemd, it all went sideways. The bug-count has hardly changed in many months. I’m really getting tired of the updates, dozens per day. In all this the performance of the system is not improving. It’s just getting harder to manage. I’m tempted to revert to Wheezy… I can’t say that all the problems are caused by systemd but it’s right around the corner every time there is a problem. When you make so many drastic changes, things are bound to break. So far, apart from boot-speed, I haven’t seen any benefit at all to systemd. It’s adding a Hell of a lot of errors/warnings to the logs and once even prevented some systems from booting for want of speed of logging. systemd was spamming syslog… I think the people who want systemd to be under everything should fix up all the necessary changes before releasing it as beta to Debian Testing. It’s not beta-software. It’s alpha. Also, the rude bastards producing systemd make Linus seem like a choir-boy.

  8. oiaohm says:

    Some of the complaints about systemd spreading all over the system is clean up of shell issues.

    Even changing sysvinit to using dash instead of bash does not ensure that each service gets started in a clean environment. Services starting under Windows also don’t start in a clean environment.

    DrLoser you have to take into consideration that Debian and others have been attempt to remove bash for a long time. Not every item bash can do can be implemented in dash. The bashism in /sbin/dhclient-script is not supported by dash to the point you cannot rewrite the script so it will work in a standard shell.

    Yes all those complaints about having to require to know C to alter X feature in systemd is mostly clean up of script start up issues. A built C or C++ program provides massively reduced attack surface area compare to using a scripting language todo the same thing.

    The other thing there was a shellshock like bug with bash 10 years ago and no one made a fuss. The reality people are starting to at long last take security some what near serous.

  9. oiaohm says:

    DrLoser big thing you are missing is not every usage of bash is exploitable even with the flaws.

    /sbin/dhclient-script location itself is highly questionable for many reasons.
    The DHCP client network configuration script is invoked from time to time by dhclient(8)
    This is what it is. Reality is no end user being system admin or otherwise should run dhclient-script directly yet its directly in the /sbin directory. dhclient is the only thing that should run that script. dhclient when running dhclient-script creates a clean environment. Only attacks against dhclient-script is the script it calls.

    Does not take much digging to find badly designed stuff.

  10. DrLoser, losing it, wrote, “You don’t even know that you have any dependencies on bash, do you? You’re just taking this assertion on trust.”

    Nope, I have a few scripts that don’t work with dash. Don’t know why. Don’t need to know. I just keep them on BASH. There’s no benefit to the world in figuring that out. That’s been done already. There’s no need for dash to be identical to BASH. Then it would be just as slow and bloated …

    Debian used to use BASH but switched to dash a few years ago. That’s why my scripts have “bashisms”. Indeed Debian has a tool to find such things in the package, devscripts.

  11. DrLoser says:

    Just in case anybody out there wishes to take up the challenge of converting what I would assume are fairly common-or-garden bash scripts into their equivalent (POSIX!) dash scripts, btw, I offer this guide.

    Why? Because I’m a community sort of guy, I guess.

  12. DrLoser says:

    I know that some of my scripts depend on BASH and I’m not going to tinker with them just to amuse you.

    I didn’t ask you to amuse me by doing so, Robert. As a matter of fact, I’m hugely more amused by your refusal to do that small thing. Consider:

    1) You are all in favour of members of the FLOSS community spending time to improve the product(s) and to share knowledge.
    2) As a trained and professional scientist, with 40 years of knowledge in IT, you are in an ideal position to conduct a few harmless experiments here and there.
    3) You don’t even know that you have any dependencies on bash, do you? You’re just taking this assertion on trust.

    Correct me if I am wrong, but this is one of your major objections to “Closed Source” software. It’s just a binary blob, and the sheeple in question is forced to take it on trust.

    Well, here you go. The ultimate test would be to delve into the code for bash, but there are many other members of the community who can do that. Several of them have apparently spent twenty five years of their lives doing just that, and only now are they coming to a number of tentative conclusions on the thing.

    I wouldn’t expect that much dedication from you, Robert … heck, it would try the patience of a saint … but I would at least expect a little entrepreneurial spirit in the service of Freedom.

    Go on, you’ll feel much better for it! For example, clone this site into a VM, and replace bash with dash.

    The tools are right in front of you. And I am absolutely certain that you will do no such thing, because you completely lack commitment to the Cause.

    Frankly, that’s whence I derive my amusement.

  13. oiaohm says:

    DrLoser replacing every instance of bash is kinda possible. Solutions using busybox normally use udhcpc instead as well.

    More and more there is no reason to use scripting todo a lot of these tasks.

    Remember the old Unix Moto. Application should do one task well. Yet for some reason the Unix world go invaded with shell script insanity. Swaping dash for bash does not get away from the base question exactly why are items like /sbin/dhclient-script a script in the first place. Is the end user expected to modify this?

    Also DrLoser before changing a shell on a script from bash to something else run a particular command.
    checkbashisms -f /sbin/dhclient-script
    Yes /sbin/dhclient-script contains 1 line that is bash particular and not posix standard for a shell. It is also a fairly scary line from security point of view in it own right.

    Debian project has been working removing bash only scripts this is why checkbashisms exists as part of qa project and part of the automatic checking tools for new debian packages.

    Pointing /bin/bash to dash or something else is fool stunt. There are many non conforming features in bash. Bash needs a lot of Auditing. The latest shellshock issue is just another issue in a long list. All the prior cases with bash including those that allowed rootkitting worms to spread from Linux system to Linux system never got any media coverage or consideration how to prevent in future by a lot of groups.

    checkbashisms exist in Debian because of the messes bash has caused. Just a pity debian has not managed to get shell independent.

  14. DrLoser wrote, “all you have to do is to replace every occurrence of bash on The Beast with a link to a less vulnerable shell, and then you can help out with a bit of testing.”

    I know that some of my scripts depend on BASH and I’m not going to tinker with them just to amuse you. DASH is not a drop-in replacement for BASH. It’s a POSIX compliant shell. BASH isn’t. “Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2).” DASH appeared in Debian in 2002 and was descended from ash which appeared in 1997. BASH was in Debian in 1996. It’s still a dependency on most Debian systems.

  15. ram says:

    The bash bug was rather minor to begin with, and was easily fixed. I did it on serveral servers in under 15 minutes. What hype! Not a SINGLE instance of working commercial server compromise — not ONE! Compare that to another, but highly promoted, operating system 😀

  16. olderman wrote, “You regularly tout linux as the superior choice for platform because it is inherently more secure. This latest mess show that that is so much bushwah.”

    I have been using GNU/Linux on desktop and server for 15 years now. There have been only 3 vulnerabilities (only two of them affected me in the least): openSSL, HeartBleed, and now BASH. Compare that with the monthly parade of critical vulnerabilities that other OS has. I’ve worked in places that had pulled the plug or endured significant downtime due to malware on that other OS. There’s no comparison. It’s a different order of magnitude.

    In case your tunnel-vision has the better of you, let me list a few:

    • The first virus for M$’s OS I ever met got onto my own PC and caused me a lot of pain because it was aimed at Pascal code.
    • Then there were an endless stream of releases from M$ that acted like malware with frequent crash/freeze behaviour causing untold $billions in damage to IT. It disrupted my classrooms and caused students’ work to be lost/wasted.
    • When the big worms came around, one employer actually pulled the plug to keep that other OS away from the web… Melissa, Kak, I Love You, Code Red, Nimda, Klez, Slammer, Blaster, SoBig, MyDoom, Sasser, Conficker, and many more. I can’t name a single worm for GNU/Linux. It’s not the top reason I left M$ but it’s right up there.
    • Today there are more than 1K malwares written daily for that other OS. They can’t even name them all. They get numbers now. There is no such industry for GNU/Linux. That other OS is just too easy. There are some malwares for GNU/Linux but new releases are days/months apart.
  17. DrLoser says:

    You do know how that magic “#!” shell invocation works, don’t you, Robert?

  18. DrLoser says:

    Oh wait, there’s another point release of the Linux kernel just out a couple of hours ago.

    No matter. Use Beast to build that first. Make sure you have it in 32-bit and 64-bit and ARM and possibly even Itanium releases. Run the entirety of the automated test suites after that.

    And after that, whilst you’re taking a well-deserved tea-break, replace bash with a link to dash and see what happens.

    Your chance to be a hero in your spare time, Robert!

  19. DrLoser says:

    head /sbin/dhclient-script
    #!/bin/bash

    I am fascinated, Robert, by your admirable habit of testing something out on the command line and then posting the results, however inconsequential and irrelevant they might be to the subject at hand.

    Now, back to my point. Replace “/bin/bash” (naturally after having backed “/bin/bash” up as “/bin/bash.tainted”) with a link (soft or hard, your choice depending upon your config) to “/bin/dash” or even “/bin/sh”.

    That was, I seem to recall, my original proposition.

    The fact is that dash is a subset or different than BASH sufficiently that some folks stick with BASH to avoid having to rewrite stuff.

    But not all folks, Robert, not all folks. And as you will also recall, I was not proposing this as an instant solution to everyone, everywhere. Let me refresh your memory as to what I actually said:

    So, all you have to do is to replace every occurrence of bash on The Beast with a link to a less vulnerable shell, and then you can help out with a bit of testing.

    I see this as an excellent opportunity to pay Freedom back for all that Freedom has given you. It would also make for an excellent blog post, I think.

    I seriously think that this is a challenge you should welcome. Without really thinking about it, I suspect that dash will function as a 100% drop-in on Beast.

    Look, you have a chance to make a real contribution back to the Community. Why dither, man? Do it now!

  20. DrLoser wrote, “Do you really use the bash shell (indirectly), Robert? I don’t think so. I suspect your set-ups rely on the syntax of the bash shell, which is a wholly different dependency. “

    file /sbin/dhclient-script
    /sbin/dhclient-script: Bourne-Again shell script, ASCII text executable
    head /sbin/dhclient-script
    #!/bin/bash

    This is despite /bin/sh being linked to dash. The fact is that dash is a subset or different than BASH sufficiently that some folks stick with BASH to avoid having to rewrite stuff.

  21. DrLoser wrote, “I’d like to question the authority behind your claim that a maximum of 0.001% of Linux servers use Bash for CGI.”

    Mathematically challenged people can be really boring. Do the maths. There are hundreds of millions of GNU/Linux servers out there. 0.001% of 300million is 3000. Twit. The precise number doesn’t really matter. The fact is that while the hole was huge. Most installations had it covered. You have to turn on CGI, DrLoser and you have to have a BASH script sitting there. The remote user can’t invoke BASH, just exploit it when it answers the call.

  22. DrLoser says:

    Ah, my second favourite security ignoramus on this site comes up with his most hilarious joke yet!

    Regarding both Home Depot and Target, the POS systems were compromised with malware and running an outdated XP embedded OS. Now, its not like one can just walk-up to a POS and install malware, obviously the vector was the corporate back-end connecting all the POS back to the corporate office.

    I understand that The Register is an accredited and trustworthy site here on this blog. I understand, therefore, that this single small example cite, culled from literally microseconds of diligent search, will be taken as Gospel Truth.

    You can so “hack” POS terminals directly, without benefit of server, Dougie. And there are other examples too: they don’t just have to be “MPOS,” although I suspect that Home Depot and Target use those in any case.

    Happy Flappy Bird Hacking! Well, you might be happy. Unfortunately, you’re not even that technically competent, are you, Dougie?

  23. DrLoser says:

    This vulnerability which was very widespread resulted in very few successful attacks because the huge vulnerability was masked by the very few servers running BASH as a CGI scripting language, a few thousand out of hundreds of millions of servers. That’s because anyone running CGI is most likely going to use anything but bash for a script-interpreter.

    I don’t think you followed your cite very far, Robert. And before I enumerate a few points which can be gleaned from this cite and its link chain, I’d like to question the authority behind your claim that a maximum of 0.001% of Linux servers use Bash for CGI.

    For anything from Mom’n’Pop to a sizeable SME, I’d guess more like 50% or more. (It’s just a guess.) Bash is there, right out of the box. Possibly linked via /bin/sh, but that’s no help. I think it’s fair to say that all those Bash tutorials out on the Web are there for a reason. And even beyond that, I suspect that your minuscule percentage assertion is out by at least three orders of magnitude.

    But, anyway, to your cite and the links:

    1) Early results from my scan: there’s about 3000 systems vulnerable just on port 80, just on the root “/” URL, without Host field. That doesn’t sound like a lot, but that’s not where the bug lives.

    Not a good source for that “3000” number, is it? Early … just on port 80 … just on the root … and the kicker at the end. Apparently your eyes glazed over after the “3000” bit.

    2) Spidering the site, and testing well-known CGI scripts (like the CPanel one) would give a lot more results, at least 10x.

    Oh well, that’s only “at least 30,000,” factored up by all those other little details.

    3) Thirdly, it’s embedded webserves on odd ports that are the real danger.

    Isn’t it nice to know that Linux (and often bash, and often over telnet) “runs on everything?” Well, maybe nice is not the word. Reassuring, that might be the word. Or possibly not.

    4) … this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems.

    Which is, of course, the real nub of the vulnerability. It’s not a one-off fire-and-forget thing. It’s very possibly a platform for massive virus delivery. Or, to put it another way, as did the link from your cite:

    … once the worm gets behind a firewall and runs a hostile DHCP server, that would “game over” for large networks.

    I presume you have an extraordinarily good argument why none of this is actually true.

    And I presume you are, right now, regretting that you linked to somebody who fundamentally disagrees with what you are saying. And who has gone out of his way to test your proposition.

  24. DrLoser says:

    I do use it [bash] as do many distros. bash is called explicitly by many dhclient processes, for instance, which means a fake DHCP server could do a lot of damage.

    Do you really use the bash shell (indirectly), Robert? I don’t think so. I suspect your set-ups rely on the syntax of the bash shell, which is a wholly different dependency. For a bog-standard call-out via system() or popen() or even a CGI script, I reckon dash would be a no-pain drop-in. Maybe even sh at a pinch.

    You’d have to check for the six (or whatever it is today) CVE vulnerabilities, but that’s actually quite a simple task. Six one-liners and you’re done.

    So, all you have to do is to replace every occurrence of bash on The Beast with a link to a less vulnerable shell, and then you can help out with a bit of testing.

    I see this as an excellent opportunity to pay Freedom back for all that Freedom has given you. It would also make for an excellent blog post, I think.

  25. olderman says:

    “I still fancy my odds of survival better than with that other OS.”

    The issue has never been what you personally could survive with. You regularly tout linux as the superior choice for platform because it is inherently more secure. This latest mess show that that is so much bushwah.

  26. Deaf Spy wrote, “you may wish to diminish the huge impact of Bash, because you do not use it”.

    I do use it as do many distros. bash is called explicitly by many dhclient processes, for instance, which means a fake DHCP server could do a lot of damage. I think that is a bigger hole rather than the CGI problem. Imagine a LAN with hundreds of clients using DHCP. Some miscreant plugs in his smartphone with a fake DHCP server spreading malware… That is huge but requires a spy who had access in those vulnerable hours. M$ has vulnerabilities like that every month compared to GNU/Linux every few years. There have been some biggies: openSSH (which hurt me a lot but, fortunately, not my employers), heartbleed and now BASH. Bad things happen when we use this much IT. Live with it or do without. I still fancy my odds of survival better than with that other OS.

  27. If you’re going to insist on using the freetard sobriquet “GNU/Linux” then you’d better use it consistently. This is not a bug in the Linux kernel. It’s a bug in a GNU utility.

  28. Deaf Spy says:

    Deaf Spy wrote, “It gets better and better” and then degenerates into ad-hominem attack for lack of any real argument.
    Well, I am not to blame that ram started with complete non-sense how the bug is fixed and how a production server is updated. I simply drew conclusions from his own words.

    Now, you may wish to diminish the huge impact of Bash, because you do not use it. However, most other people do. It is the same with Photoshop. You don’t use it, but almost everyone else does. Bash is popular, you know. It is one of the pets of FOSS. Some more enthusiastic FOSS proponents dare say it is better than Windows Powershell.

    The whole fiasco proves that Bash is a piece of spaghetti code, with no testing frameworks and procedures involved. It cannot be even patched quickly for these current problems.

    After Heartbleed and Bash, what would be next? And you dare say Linux is secure, just because it is Linux. Well, that is not convincing for professionals, you know.

  29. Deaf Spy wrote, “It gets better and better” and then degenerates into ad-hominem attack for lack of any real argument.

    This vulnerability which was very widespread resulted in very few successful attacks because the huge vulnerability was masked by the very few servers running BASH as a CGI scripting language, a few thousand out of hundreds of millions of servers. That’s because anyone running CGI is most likely going to use anything but bash for a script-interpreter. It just doesn’t make sense to open up a server to every command on the system. I’d bet many of those vulnerable systems have other layers of protection like a chroot/virtual machine/readonly file-system. While I know BASH could be used for CGI and I use CGI a lot, I have never used BASH that way except perhaps in testing on a local machine. There’s just no need to use it with Pascal, PHP, Perl and so many other good languages designed for the purpose. A known bug in BASH predates this one, Man page for BASH: “It’s too big and too slow.” That’s not an exaggeration. Look at this:
    ls -l /bin/*sh
    -rwxr-xr-x 1 root root 1033720 Sep 25 16:48 /bin/bash
    -rwxr-xr-x 1 root root 117176 Jan 10 2014 /bin/dash
    ls -l /usr/bin/perl
    -rwxr-xr-x 2 root root 10416 Sep 20 12:07 /usr/bin/perl
    ls -l /usr/bin/php5
    -rwxr-xr-x 1 root root 9011944 Aug 28 08:19 /usr/bin/php5
    ls -l /home/pogson/pascal/fpc-2.4.4/bin/fpc
    -rwxr----- 1 pogson pogson 368248 Apr 21 2011 /home/pogson/pascal/fpc-2.4.4/bin/fpc

    That’s one reason I don’t particularly like PHP but BASH is a far worse choice.

    The biggest danger from this vulnerability was the possibility of getting a malicious DHCP server on LANs spready malware when DHCP-client used BASH to set things up. Of course that shouldn’t be easy to plant from the web unless there is already a doorway in. Anyway, this is nothing compared to weeks of depradations users of that other OS had when various worms were rampant. I worked at one place that unplugged from the web in order to save its local IT.

  30. Deaf Spy says:

    It gets better and better:
    http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/

    “Most Linux server administrators patched the bug within hours of its publication”
    Ram, let me guess. You have never, ever touched a real, production server with Linux. What am I saying! You have never, ever touched even a real, staging server with any OS.

  31. ram says:

    Most Linux server administrators patched the bug within hours of its publication. Easy too, just “sudo apt-get install bash”, seconds later everything fixed!

  32. oiaohm says:

    Robert Pogson the reason why CVE-2010-2730 fault 4 years later is still open is a process Microsoft has of silently patching. Fixing CVE-2010-2730 alters credential processing so making particular company internal websites fail. Patches related to security need to be clearly marked as such. One of the patches to CVE-2010-2730 by Microsoft is exactly like using modsecuirty to block bash issue with appache httpd.

    A lot of Microsoft so call silently patched security flaws is we add filter solutions not fix base flaw. Basically Microsoft is serous-ally not a good example. Decade old flaws are how IIS systems are exploited a lot. Yes old unmaintained application running on a OS is never healthy even less healthy when what are security patches are not clearly marked.

  33. oiaohm wrote, “CVE-2010-2730 in IIS is still open.”

    “Buffer overflow in Microsoft Internet Information Services (IIS) 7.5, when FastCGI is enabled, allows remote attackers to execute arbitrary code via crafted headers in a request, aka “Request Header Buffer Overflow Vulnerability.”

    M$ claims to have patched this thing: “MS10-065 – Nessus Plugin ID 49223 (Credentialed Check) – IIS servers with FastCGI enabled are vulnerable to a remote code execution vulnerability that can be exploited by sending HTTP requests (CVE-2010-2730). Two other vulnerabilities were patched (not requiring FastCGi), including a denial of service and privilege escalation vulnerability. “

    Wikipedia: “IIS 7.5 was included in Windows 7 (but it must be turned on in the side panel of Programs and Features) and Windows Server 2008 R2.”

    Much of the world migrated to IIS 7.5 when they migrated to “7”. There must be a few instances out there… M$ takes months to fix a critical vulnerability yet the FLOSS community takes care of business in a matter of hours. Good one.

  34. oiaohm says:

    DrLoser there are many Linux shells. Dash was changed in debian init systems because dash instructions are more limited than bash so reducing security risks. Dash limitations also make it a complete pain to use like it does not support arrow keys on command lines to edit them.

    Dash is in fact a fork from NetBSD shell ash that was designed to reduce shell script exploits in BSD init system. Due to ash being from the BSD world it has in fact been through a more formal security audit process than bash has ever faced.

    DrLoser please learn to keep mouth shut at times.
    http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3436/Microsoft-IIS.html Very good read.

    Remember to exploit apache by bash bug CGI had to be on. CVE-2010-2730 in IIS is still open. Found 2010 and its 2014 today. Enable CGI under IIS equals exploited system. I can suggest more secure options but its not IIS with some random configuration. Apache on bsd something for example that does not have have poorly audited shells to exploit.

    Does not take 4+ years for Linux world to push out update so these issues with just do not do the following instructions in the mean time. Yet its not uncommon for Microsoft to take 5 to 6 years with working around instructions.

    Apache on a systemd system with Apache running in a restricted cgroup result would not be complete data loss. Microsoft Windows lack the ability to properly zone applications.

    Not all Apache installs have bash shell either.

  35. dougman says:

    Well, from what I read, the credit card transactions were not even encrypted, so it was fairly easy to siphon and copy the data.

    I expect this to be a reoccurring theme, the coming months/years ahead.

    Eh.

  36. dougman wrote, “its not like one can just walk-up to a POS and install malware, obviously the vector was the corporate back-end connecting all the POS back to the corporate office.”

    That’s probably true, if only to save labour. POS terminals are thin clients of something upstream. You’d think they could push a button and deploy whatever security they needed on the terminals and the server, though. Home Depot has downtime every night on the clients. Maybe they didn’t have enough resilience in the servers. You would think the terminals and servers would be on a private network, too. There’s no need for either to be on the web. A system that valuable should have as many layers as practical.

  37. dougman says:

    Of course the media never faults M$ and it’s products, they would be sued.

    Regarding both Home Depot and Target, the POS systems were compromised with malware and running an outdated XP embedded OS. Now, its not like one can just walk-up to a POS and install malware, obviously the vector was the corporate back-end connecting all the POS back to the corporate office.

  38. “In order to get your CGI programs to work properly, you’ll need to have Apache configured to permit CGI execution. There are several ways to do this.”

    see Apache Tutorial: Dynamic Content with CGI

  39. DrLoser wrote, “Apache, a Web Server which is inherently wide open to this disastrous security breach”.

    That’s not true at all. Apache is not configured to use CGI-BIN let alone use BASH as an interpreter. There’s two layers of error by an admin to make this vulnerability real. I’ve used CGI for years and never used BASH for that. It’s just too perilous. Languages like PHP and Pascal are much easier to use than BASH for such purposes and there’s just no need to link in every binary on the system to a CGI script… Apache usually needs to be told which directories need CGI and the scripts usually run as the server so you can do a bit with execute permissions but it’s a very dangerous way to operate. This is why I like native code for CGI. The interpreter can’t misinterpret which is what happens in this vulnerability.

  40. olderman questioned the URI…

    I could not find that either but Google found this: “It is highly advised and recommended the NTP Firewall component be deployed and that Windows Firewall be discontinued,” the report states. For intrusion prevention to work properly, it says, NTP was needed on all Home Depot computers, including register payment terminals. Instead, the company kept the protection off its registers and continued to scan for suspicious activities at the network level, say the internal documents. John Van Blaricum, a spokesman for FishNet, declined to comment.”

    It’s a case of Home Depot feeling lucky that the banks are on the hook for credit-card fraud. I don’t see what IIS has to do with POS terminals but there could be some command/control interfaces that use it which could have been a point of entry. Anyways M$’s desktop firewall might not have been the best choice for a network dealing with $billions.

  41. olderman says:

    Ask Home Depot and Target about IIS on the backend and how secure it is. ”

    Oh, Dougie,

    I think that you gave the wrong URL. This article doesn’t even mention Microsoft let alone IIS.

    LOL

  42. dougman says:

    Bollocks..

    Ask Home Depot and Target about IIS on the backend and how secure it is. Knowing this, why would any retailer begin to even rely on MicroSh1t??

    http://www.courant.com/opinion/op-ed/hc-op-geitz-banks-pay-for-20140922-story.html

  43. DrLoser says:

    A small question here, Robert: do you believe that dash is more secure than bash in this respect? Because I doubt that it is.
    Have you checked it out? The code is freely available for examination, you know.

  44. DrLoser says:

    Rather unfortunate that Netcraft statistics suggest that Apache, a Web Server which is inherently wide open to this disastrous security breach, has 55% market dominance, isn’t it? Monopolies are obviously a bad thing.

    I recommend Microsoft Internet Server. It’s the little guy in the game — it only serves about 15% of web pages — but, boy, is it secure!

    Why, you could build a UPS for it just by not allowing random criminals to steal all your data and bankrupt you!

Leave a Reply