Can you hear that sound?
It's Windroids salivating and Fisher-Price Programmers rushing to comment.
Will they get here before the exploit is patched...
A bug discovered in the widely used Bash command interpreter poses a critical security risk to Unix and Linux systems – and, thanks to their ubiquity, the internet at large. It lands countless websites, servers, PCs, OS X Macs, various home routers, and more, in danger of hijacking by hackers. The vulnerability is present in …
It's Windroids salivating and Fisher-Price Programmers rushing to comment.
Will they get here before the exploit is patched...
Maybe they won't get there before its patched, but who gives a shit? It'll take forever for every single thing out there that's got bash in it to actually get upgraded. Sure the major distros will be quick off the mark, but what about all the printers, network switches, VM hosts, etc etc & etc? Sounds like there's a lot of kit out there that is wide open as of this point in time.
Sigh, ya need to re-read the article
I'll have my server patched in a minute… anything I have the source code to, no problem. It's all the commercialised crap that's a problem.
make: Leaving directory `/tmp/portage/app-shells/bash-4.2_p48/work/bash-4.2/po'
>>> Completed installing bash-4.2_p48 into /tmp/portage/app-shells/bash-4.2_p48/image/
strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version
ecompressdir: bzip2 -9 /usr/share/man
ecompressdir: bzip2 -9 /usr/share/info
ecompressdir: bzip2 -9 /usr/share/doc
>>> Installing (1 of 3) app-shells/bash-4.2_p48
>>> Setting SELinux security labels
Told you so. :-)
I'm guessing it'll be the same vendors that never upgraded for the heartbleed vulnerability.
Bash is a rather fat shell. Embedded systems which run Linux often use BusyBox instead, or another lightweight shell. Does anyone know if all POSIX compliant shells which support shell functions (zsh, pdksh, etc.) are vulnerable, or is it just bash? And what about the t/csh heretics?
I think the article answers this already when it says the dash shell in Debian and Ubuntu is not vulnerable. This is a Bash-specific bug.
I misread that and then thought it was a typo, but I see what it means now.
Anyway, for those who aren't full time linux sysadmins (and I count myself in that group - although I'm learning fast) if you're running a boggo install of Debian Wheezy or any supported Ubuntu variant, give this a shot:
sudo apt-get install --only-upgrade bash
(use sudo as and if required, of course)
Wheezy main and Ubuntu have patches in the repo already - bash_4.2+dfsg-0.1+deb7u1 on debian vulnerability matrix thingy.
As a well regarded security consultant just IM'd to me, and I'll admit I'm paraphrasing here, PATCH FUCKING EVERYTHING.
> the dash shell in Debian and Ubuntu is not vulnerable
I think it's important to note that a lot of Debian systems will still be using bash as their default shell, even if dash is also available or installed.
I wouldn't be too worried about enterprise network gear. Are your printers Internet accessible?
Routers, switches, firewalls and other network gear should have either:
1) Have ACL's
2) Have a management VRF
The control plane and data plane are separate.
"It's Windroids salivating and Fisher-Price Programmers rushing to comment."
Why not? You aren't a proper Reg reader unless you gloat when an OS other than the one you use has problems. Still, bravo for being defensive even more quickly - never seen that before :)
"I think it's important to note that a lot of Debian systems will still be using bash as their default shell, even if dash is also available or installed."
.... and they're already fixed....
I lot of kit will NEVER get patched. Home routers are the biggest worry. Some use bash and not busybox.
This shellshock will be the gift that keeps on giving.
If you're running CGI scripts with BASH, then this is the slapping you wanted.
Anyone who gets to an internet router which shells out for ping/traceroute already as control.
Who puts bash rather than busybox on an embedded device?
It isn't good, but it is more like worrying about a thief getting through the non-locked internal doors in your house.
I can confirm that zsh did not trigger the exploit code in the mentioned example.
Have an upvote, that is how we do it :-)
".... and they're already fixed...."
The patch being in the repos doesn't mean the average person with a web site that once had a developer throw some code at it has actually had the patch installed...!
What about your router?
"What about your router?"
Pretty sure Drayteks run Busybox (I don't allow remote access to my management page, only VPN so I can't check at the moment for reasons I'm too lazy to explain) but a colleague tells me that BT Home Hubs run Bash.
So, that might be causing some BT people some headaches this morning, if true.
I guess this means that Linux based systems are likely going to continue to be the most risky OS for remote exploits on the internet for the foreseeable future.
I have recently migrated most of our webservers to Windows Server because of the much higher number of on-going security issues I found when using an OSS stack.
"I guess this means that Linux based systems are likely going to continue to be the most risky OS for remote exploits on the internet for the foreseeable future."
Are the only keys that work on your keyboard CTRL + C & CRTL + V?
Just as a (mainly) windows user, I think your a 13 year old moron that spends his nights on to many forums salivating over <insert female movie star>, whilst having pointless arguments with Eadon.
Sorry, I know, feeding trolls and all that.
"I think your a 13 year old moron"
I think you're an illiterate 13 year old moron...
whilst my kb of linux under the bonnet is rather limited, on entering the second item into the shell, it appears that my [Mint 16] box may have a problem....
I can tell you that pdksh is not vulnerable as it thankfully never implemented exported aliases or functions.
This is a bit of a stretch. An OS is only as secure as the measures that are taken to protect it.
Linux has vulnerabilities that show up, but so does Windows. Remember that hotfix you applied? If you read the details on what it's fixing you may scare yourself.
Sorry, I know, feeding trolls and all that.
Perfectly allowable so long as you give them copious amounts of extra tasty rat poison.
Guess he now wishes he wasn't so quick... while still waiting for a definitve patch.
"but what about all the printers, network switches, VM hosts, etc etc & etc?"
What sort of printer or network switch would be running bash? Those which I can think of all run proprietary OSs which have their own basic toolset.
May be a bit off the mark here, but that remark sounds a bit like the numerous claims in the media during 1999 that microwave ovens would start exploding as their clocks rolled over to the year 2000
(despite such clocks not having any concept of date...)
Its worth worrying about modern commodity home routers though, because a number of brands have started running cut down Linux distro's in recent years - albeit with largely custom toolsets ... as someone commented already, bash is a fairly porky dynamically linked binary - the sort of firmware in such devices tends to prefer simpler and often statically linked binaries. (avoiding the need for large numbers of shared libraries on a device which has a relatively small toolset)
Of a more clueful than average but non-expert's mind (mine. Well, I call it a mind..) whirring:
I've just checked my fully-updated (so my system tells me) Linux Mint install, and the test script gives a 'busted' result, so my PC is insecure. I note that I can't sensibly remove bash even though there are other shells installed (because I'm not sufficiently expert enough to work out how to replace bash and keep things functioning) and I am having trouble finding a .deb for a fixed version of bash.
Hang on - I've been mildy panicking and missing the flippin' obvious. Deep breath. Go to Debian site. Go to packages for the unstable build, download relevant .deb file for my kit. Got it. Now use GDebi to install it. Eh? The install's hung, let;s have a look at the terminal window. It's asking me a question.. hey I didn;t know the terminal window in that thing was interactive before! Thought it was just a log of what;s going on. Learn something every day.. OK, click in window, type Y I do want to install the maintainers version. Hmmnn.. same thing again for this other bit associated with it. Gdebi's done. OK, test the terminals I can see available from the menus - both now NOT giving 'busted'.
So I now appear to be as safe from the bash bug as anybody's likely to be. phew. I can't see yer average PC user managing that lot even if they are using Linux (and I have introduced several people to the joys of using Linux, over the years) though.
So why was a fully-updated (because I always install updates right away) Linux Mint install using a vulnerable version of bash if fixed versions are already available? I'm not being critical, I'm presuming there must be a good reason and would like to know.
There is some nonsense going around that devices running busybox are immune. Not necessarily so. my QNAP NAS runs busybox and IS vulnerable. It includes /bin/sh which turns out to be bash 3.2.
You can only do things within the privileges of the web server..
…And seriously, what kind of setup would you have that lets the web server set environment variables with data from the user??
I would have called that a big gaping security hole in itself …
...f this may be how the FBI got the silk road server to spit out information?
>>"You can only do things within the privileges of the web server"
I don't think that word "only" means what you think it means. Give me arbitrary execution on a server with Apache's privileges and I can do quite a lot with that. At the very least I can connect to whatever database powers your site and scarf all your data, read all the code of your site (looking for other vulnerabilities) and we haven't even got to subverting your site to serve malware, yet.
Fortunately I don't think so many webservers these days run CGI, do they? But still, there is a reason experts have classed this as a '10 out of 10' for seriousness and it's not because they know less about it than you do.
Also note that you're only talking about the HTTP vector. There are others, though that is the most likely.
No one wants the risk.
Give me arbitrary execution on a server with Apache's privileges and I can do quite a lot with that. At the very least I can connect to whatever database powers your site ...
using whose login credentials? You dont think that a readonly access to limited data is te same as full access to everything and to get that password anyway, you need access to the scripts that employ them, and apache does nit have access to the scripts necessarily.
>>"using whose login credentials? You dont think that a readonly access to limited data is te same as full access to everything and to get that password anyway"
No password, no login credentials. Post I replied to talked about "only" having privileges as the webserver. I'm quite right to point out that webserver privileges allow a huge amount of dangerous activity. If I can execute arbitrary scripts as the apache process I can do all of the things I described as more.
>>"and apache does nit have access to the scripts necessarily."
You're creating your own scripts with this exploit over CGI.
You might be able to connect but you cant scarf any data from it. Any sensible web admin will have configured it to not to allow random sql to be run over the connection between the web server and the DB.
Or at least that's how I've been doing it, and encouraging everyone else to do it, since I discovered you could do that well over a decade ago.
>>"You might be able to connect but you cant scarf any data from it. Any sensible web admin will have configured it to not to allow random sql to be run over the connection between the web server and the DB."
The number of web applications that assemble their own SQL: very high. Even if they don't assemble it dynamically they read it from a file of SQL statements on...guess where: the web server.
Number of web-applications that retrieve data ONLY by pre-created stored statements in the database: far, far fewer.
Number of web-applications where even pre-created stored statements couldn't be abused to extract tonnes of confidential data: vanishingly small.
In short, being able to execute arbitrary code with the privileges of the web server is a massive security flaw and don't pretend otherwise.
I'm not pretending otherwise. If people cant be arsed to put in decent security on your web site dont try and blame it something else. Its very easy to write procedures to do everything you want and prevent abuse and as a web manager its very easy to prevent coders from writing (or at least running) sql on a world facing server. You should do that anyway - not blame your fuckup on someone else finding a way to exploit it.
If the former it's scary to think just how many holes there must be out there.
The phrase "given enough eyeballs, all bugs are shallow" is mentioned a lot, but there is rarely a mention, and never praise, for "fumbling fingers". Given a large population of fumbling fingers, all bugs are hit multiple times. Then you only need one poor (but intelligent) sot to say "why did that happen?" and then go rooting around in the code. But remember, likely this bug was found because one person got clumsy with an editor in a script and wondered "where did that crap come from? oh, that looks like..."
Dyspraxics fall all over themselves to be helpful!
In "Inviting More Heartbleed" (paywalled here ... what do you think you are doing, IEEE?), Alan Geer says:
At this point, we should ask ourselves a core question: Does looking at code actually work as a quality assurance mechanism? DES got more study than any other crypto algorithm ever will and serves as an existence proof that eyeballs can work. Evidently the eyes on it were pretty good, better than the open literature knew at the time. But the DES algorithm, even in optimized implementations, seldom runs longer than 2,000 lines of source code, whereas OpenSSL is more than 2,000 files with north of 600,000 lines of content. Does that mean OpenSSL needs 300 times as many eyeball-years to get it as good as DES? Perhaps the count of available eyes should serve as a limit on the size of a code base.
Bruce Schneier has asked whether security bugs are rare or plentiful. We don’t know. Theo de Raadt’s contention that all bugs are security bugs seems a bit too strong but better that than too weak. Either way, will a determined effort to find bugs yield security value? Yes, if bugs are rare enough that by removing what we find, we materially lower the count of bugs still in operation. If, by contrast, bugs are so plentiful that we can’t make a dent in the overall supply, then finding more is a waste of time as the ensuing work factor doesn’t change the equation one iota.
Given that it’s harder to find bugs in complex operating environments than in simple ones, is there something about how we do things today that has caused us to pass a threshold of complexity, a threshold beyond which quality assurance, no matter how we attempt it, will be infeasible at the level of effort we can or will put to the problem? Again, is the eyeball supply in a continuing shortage such that we should manage it? Have we reached “peak eyeballs” the way some say that we’ve reached “peak oil?”
>>"If the former it's scary to think just how many holes there must be out there"
Article says it's been present since 4.3. IF that is correct then that means since around February this year. Obviously distributions will vary according to precisely when they became variable, but we're looking at that sort of time span of vulnerability where it wasn't known. Patching everything may take some time.
Article says it's been present since 4.3.
No, the article says The vulnerability is present in Bash through version 4.3, which is somewhat ambiguous, but means basically up to 4.3. The article also says the bug is 22 years old.
>>"No, the article says The vulnerability is present in Bash through version 4.3, which is somewhat ambiguous, but means basically up to 4.3. The article also says the bug is 22 years old."
Oh shit. Thank you for correcting me. That means we've had a major vulnerability for a really long time. I find it really unlikely there aren't people out there who haven't know about this.
Note, the vulnerability notice I've read says problem since 3.0 which would mean at least since 2005. I'm not sure where the 22 years comes from. But I'm nit saying you're wrong.
I think the words " twenty two year old bug" give some idea of how long it's been in code.
So since about 1992?
I don't know who Alan Geer is, and with the following quote from his article I can't be bothered to find out:
At this point, we should ask ourselves a core question: Does looking at code actually work as a quality assurance mechanism?
Good software testing doesn't rely on a human looking at the code. Pair programming and code reviews should be used to ensure code is readable, easy to understand and matches business requirements. Actual testing should be automated with unit tests, integrated tests, load testing and tools such as fuzzers.
Biting the hand that feeds IT © 1998–2018