More patches....
I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.
Third patch brings more admin Shellshock for the battered and Bashed
A third patch, from Red Hat engineer Florian Weimer, has been released for the vulnerable Bash Unix command-line interpreter, closing off flaws found in two previous fixes. Weimer's unofficial fix was adopted upstream by Bash project maintainer Chet Ramey and released as Bash-4.3 Official Patch 27 (bash43-027) which addressed …
-
-
Tuesday 30th September 2014 07:14 GMT Anonymous Coward
Re: More patches....
LOL. 3 patches and we still don't know if it's fixed. I think that this has to be the record for the suckiest OS security ever. Even Microsoft a decade ago couldn't compete with this compendium of disasters...
It seems to me that it is broken by design. Perhaps the Linux distributions should adopt a more secure and powerful scripting solution like Powershell ?
-
Tuesday 30th September 2014 08:20 GMT Anonymous Coward
Re: More patches....
Linux distributions should adopt a more secure and powerful scripting solution like Powershell
You obviously don't understand the issue, yet you turn it into an "I love Microsoft" chant?
I've used Windows long enough to know that we've had more than our share of remote exec problems, too.
You're in a glass house...
-
-
Tuesday 30th September 2014 08:39 GMT auburnman
Re: More patches....
We need an option on posts that is more severe than a downvote but less severe than 'report this post' for content that contributes nothing to the discussion and/or wildly praises/denigrates certain companies/products. Although as I type this it dawns on me such a thing would be abused until it lost al meaning.
-
Tuesday 30th September 2014 09:16 GMT Anonymous Coward
Re: More patches....
We need an option on posts that is more severe than a downvote but less severe than 'report this post' for content that contributes nothing to the discussion and/or wildly praises/denigrates certain companies/products.
What, and deprive commentards of the pleasure of ripping such a poster to pieces with clear facts, razor sharp analysis, sarcasm and hollow laughter? You must be joking.
-
-
-
-
Tuesday 30th September 2014 11:28 GMT Anonymous Coward
Re: More patches....@AC
"Look up GDI flaws, it's been patched more times than a sex maniacs blow up doll and still keeps leaking."
But so far not 3 times in 3 days for 6 different holes (and counting). And the patches generally actually work. And most importantly when talking about servers - GDI vulnerabilities are not remotely exploitable without local user interaction...
-
Tuesday 30th September 2014 16:59 GMT Tom 13
Re: But so far not 3 times in 3 days for 6 different holes (and counting).
Of course not. MS doesn't even issue a simple patch in less than a month. Which is not exactly a ringing endorsement.
And IIRC the first "patch" they issued for the problem was a tool that you had to manually run to see if you had the vulnerability. After which you had to locate the correct bit to download and apply to the bits it found. Yes, the tool was in MS Updates (or whatever it was called back then) but not the patches. Royal PITA too as I recall since it stopped the other downloads from proceeding.
Oh, and part of the reason MS switched to monthly patching? Yeah, it was because of admin fatigue from constantly patching and rebooting their servers before that.
-
-
-
-
Tuesday 30th September 2014 08:38 GMT Anonymous Bullard
Re: More patches....
I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.
Oh god yeh, I'm not even a sys-admin, yet the 5 Linux computers I maintain are a right pain in the arse having these security updates automatically applied! I'm over-run by the work.
I wouldn't mind, but none of these machines even have services that are vulnerable.
-
Tuesday 30th September 2014 11:28 GMT Anonymous Coward
Re: More patches....
"yet the 5 Linux computers I maintain are a right pain in the arse having these security updates automatically applied"
But the latest holes have not been patched on most Linux distributions yet - unless you installed one guy's unofficial fix - which involves some effort.
If you wait for the patches (presumably your systems check once a day?) you might well already be owned if the boxes are vulnerable...
-
-
Tuesday 30th September 2014 09:13 GMT Anonymous Coward
Re: More patches....
I'm glad I'm not a sysadmin and I have the utmost respect you that are. You're going to be burning the OT on this set of bugs.
Actually, no. The process to address such issues is well established, so it's more a matter of inserting the right components and cranking the handle. Unix is by its very nature very easy to automate, and you can choose just how much you want to do yourself, all the way to downloading the patches and compile the binaries yourself. It is a Unix feature that Apple OSX users enjoy as well, provided they have Xcode installed (which is free, BTW).
Also keep in mind that 90% of what you read casually omits the fact that this is only an issue for servers, not for desktops (unless I got this wrong, happy to be corrected). That is very bad when it comes to Internet exposed services (think a gazillion Google and Amazon machines, for instance), not so much for your desktop or laptop AFAIK.
-
Tuesday 30th September 2014 10:36 GMT Raumkraut
Re: More patches....
> Also keep in mind that 90% of what you read casually omits the fact that this is only an issue for servers, not for desktops (unless I got this wrong, happy to be corrected).
Unfortunately, you are indeed mistaken. It turns out that, at the very least, DHCP - the service which likely assigns you your IP address on a network - is often implemented on a *nix client using calls out to a shell. So a malicious DHCP server on your network could exploit this flaw on any machine (or router, storage device, thermostat, lightbulb, etc.) which uses Bash - completely without user intervention!
Of course, getting that rogue DHCP server on your network is another matter, so this is mostly a concern when using open WiFi networks.
-
This post has been deleted by its author
-
-
-
Tuesday 30th September 2014 10:46 GMT Alistair
Re: More patches....
Say it with me now folks:
Awwwwwtoemmmmmmmation!
cfengine/chef/puppet/etc etc.
1500 to 1600 active systems, no sanity in trying to do each one manually. Test against the app layer in a controlled environment, validate results and push it out with automation. Including the validation.
-
Thursday 2nd October 2014 05:37 GMT Anonymous Coward
Re: More patches....
A sysadmin worth their salt of course has an automated way of updating systems. Then it is just a matter of downloading the patched package in your repository (or wait for the automated download) and your scripted cronjob on each system does the rest. Or else just setup the distribution's preferred automated update mechanism. Debian provides the very helpful unattended-upgrades package.
-
-
Tuesday 30th September 2014 03:05 GMT Anonymous Coward
Fixed. Really?
If at the very beginning they had ripped out the nova-hot security hole that pass functions around in environment variables, then we wouldn't need to be doing these contortions. My first reaction would have been to bash Bash right off my systems no matter the breakage. And don't think I wouldn't get away with it. My bosses knew I didn't freak over nothing.
From the very first, Bash has been the only shell equipped with this feature. And it's why you don't find it over BSD-land unless bolted on. Nooo, we have to put enough bandages on it so that it doesn't bleed out all over the place. You can be damned certain of one change that'll happen here should I get the CentOS urge again. Arghhh!
Where's the giving the middle-finger salute or European equivalent icon?!
-
Tuesday 30th September 2014 03:13 GMT G Mac
Review time - don't be complacent just because of limited shell functionality
I have been following this story pretty much since the start. Not much impact on me (well timed vacation?) but our system administrators and engineers (for review and regression of production systems) have been roped in.
With the news that there are other undisclosed remote execution bugs out there there are going to be a *lot* of blackhat (and hopefully whitehat) folks carefully reviewing ALL shell code...
-
-
Tuesday 30th September 2014 11:04 GMT Anonymous Coward
@Eddy Ito
Outside the Linux realm, sh(1) is not bash(1), not even with bash in Posix mode. If you want to do such a temporyry fix, it's bash you need to relink to something professional, maintained and tested.
Personally, I think it very poor to trick people into using bash (or any other shell) by linking the name they do want to bash. The web seems to have a lot of people wondering why bash(1) handles variable scope so oddly in loops. They must get really confused if they, after working on a real UNIX, specify sh or ksh and see the same behaviour because, invisibly, they are just using bash with some variables set.
I wonder how many other such Linux-isms are lurking. Suppose I should do a find(1) across the various bin directories on a couple of Linux distributions.
-
Tuesday 30th September 2014 14:45 GMT Eddy Ito
Re: @Eddy Ito
There's no need to trick anybody. The user will still be using whatever shell is specified for their login, typically called out in /etc/passwd. They can chsh to any shell from ash to zsh or even fish anytime they like, assuming it's installed. In fact if you look at recent Debian or Debian based distro you'll see that bash is the default login interactive shell but /bin/sh is a symbolic link to dash.
The thing is you're unlikely to find a regular Bourne shell on a Linux box at all because the Bourne shell was proprietary at the time. I understand the Bourne shell is now CDDL which, while GPL incompatibilities exist, I don't believe there is anything stopping someone from installing it much like zfs. Interestingly, it was the same copyright issue that led to the creation of ash with a BSD license.
-
-
Tuesday 30th September 2014 05:29 GMT pierce
this article says this is the third patch, but its apparently already incorporated in redhat's 2nd patch released last friday....
$ foo='() { echo not patched; }' bash -c foo
bash: foo: command not found
$ bash --version
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
...
$ rpm -q bash
bash-4.1.2-15.el6_5.2.x86_64
(this on centos 6.5)
-
Tuesday 30th September 2014 09:21 GMT Fred Flintstone
Yup, OSX is safe too if you have installed patch 54 (https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-054), which was released late on the 27th of September. Otherwise you'll have to add patch 54, recompile and replace the binaries as before.
From what I've seen, most HOWTOs on the topic have been updated to incorporate patch 54 - nice to see that people are on the ball.
-
-
Tuesday 30th September 2014 07:38 GMT Anonymous Coward
And I thought that I would never see a bit of bash scripting on a mainstream site
That is, if the Reg counts as such.
Mines are already patched. But really, if this "allows remote code execution" is only applicable if you have open web services that spawn bash to serve remote requests, most desktop systems are unaffected. Which makes us the 1% feel very comfortable.
-
Tuesday 30th September 2014 09:51 GMT A Non e-mouse
Re: And I thought that I would never see a bit of bash scripting on a mainstream site
But really, if this "allows remote code execution" is only applicable if you have open web services that spawn bash to serve remote requests, most desktop systems are unaffected
Oh boy no! This is what the fuss is about. Bash is used in *lots* of places in a *nix system and is exploitable in numerous ways because of it. There's a proof of concept here for attacking clients via DHCP.
-
Tuesday 30th September 2014 10:21 GMT Anonymous Coward
Re: And I thought that I would never see a bit of bash scripting on a mainstream site
here's a proof of concept here for attacking clients via DHCP.
For that to work, you need to have control of the DHCP server. If you have control of the DHCP server, then all the clients are fucked, regardless of OS.
-
Tuesday 30th September 2014 11:18 GMT Anonymous Coward
Re: And I thought that I would never see a bit of bash scripting on a mainstream site
"For that to work, you need to have control of the DHCP server."
It's easy to plug in one that responds fastest - or set one up on WiFi
"If you have control of the DHCP server, then all the clients are fucked, regardless of OS."
Not if they run say Windows - or anything that doesn't rely on an exploitable version of BASH. You might be able to do things to the traffic - but you won't automatically own the host!
-
-
Tuesday 30th September 2014 14:59 GMT Anonymous Coward
Re: DHCP
There's a lot of wrongness in this thread!
"no need for a bash exploit when I own ALL your traffic": Lots of people use a mobile device with an untrusted network. I don't expect my mobile device to be open to remote code execution just because I'm using it in a hotel, say, rather than behind my company firewall.
However, it's not clear yet, at least to me, whether there are many (mobile) devices around that use bash as part of the DHCP client.
-
Wednesday 1st October 2014 14:52 GMT elip
Re: DHCP
Hmm, I was addressing the rogue DHCP server threat. Nothing wrong in my statement. Guess the 'vote-down' brigade doesn't have an imagination. I guess I'll spell it out:
"I don't expect my mobile device to be open to remote code execution just because I'm using it in a hotel, say, rather than behind my company firewall."
I said "no need for a bash exploit when I own ALL your traffic"... nothing in there implies remote execution on your phone, though that too would be trivial to pull off. If I'm handing out leases to your device on an open network, guess what your device is getting for its DNS and gateway???? That's right, *my* hand-crafted DNS and router doing MITM on all of your traffic. From this position getting remote execution on your phone becomes simple, but why bother when I have access to all of your data sitting in the fuzzy cloud of the interwebs.
-
Monday 6th October 2014 12:36 GMT Anonymous Coward
Re: DHCP
So presumably you never use WIFI outside of your house, or office, for anything, elip, right?
And you don't use 3G / 4G either?
Because from your analysis, if you do, then "getting remote execution on your phone becomes simple" to any admin of those services ... I don't think you actually believe that though, do you?
-
-
-
-
-
-
-
-
Tuesday 30th September 2014 08:43 GMT Anonymous Coward
How it works
The article would benefit from an explanation of what has been changed in bash.
It looks as though an exported function called "foo" used to be exported by putting its definition in the environment variable "foo", but now it goes in the environment variable "BASH_FUNC_foo()". So bash no longer has to parse the value of an environment variable called HTTP_USER_AGENT, for example. So it's much safer.
-
Tuesday 30th September 2014 09:52 GMT Icy North
Foo - a short history
Ah, the foo function.
Students of computer history may know that this term derives from the Ancient Chinese word 'foo', meaning 'a chicken'. It has survived in such terms as 'egg foo yung' (egg of a young chicken), 'Fu Manchu' (tough chicken) and the martial art 'Kung Fu' (way of the chicken).
The chicken was of course revered in Ancient China. Men would keep lots of hens as they believed their noise would make them grow wise.
As Confucius once said: "Some men are wise, but some do not have a clucking foo."
-
Tuesday 30th September 2014 18:44 GMT Anonymous Coward
My first thought when this broke on reddit was to remove bash while the details were teased out on the live servers I'm responsible for and symlink bash to dash. Some quick testing revealed It promptly broke the apachectl package installed therein and stopped them starting up so I had to revert to the first patched version and apply the updates and we removed the cgi module functionality to try and minimise our exposure.
The only real pain isn't the 3 fixes in a few days, thats bau and we should be pleased at the speed of response, its the devices that will never be fixed, network elements that the vendors haven't disclosed to their customers use a shell, cgi's running on little gui's etc.
IIRC someone posted a few days back to full disclosure a poc example of a dhcp client p0wning the dhcp server if it ran bash as the shell, and that is far far far more serious and has massive ramifications for large corporate infrastructures as once you own the dhcpd server, you can then own any clients with bash installed who connect.
The truth is we don't understand all the vectors enough to let the middle managers talk away the seriousness away, so the responsible course is just to fix everything asap.
As for the windows is best tack, I remember sitting exposed for weeks with machines in a pool behind a f4 big ip load balancer being periodically owned while microsoft spent time frantically working on finding out exactly how the attacker was getting into our web farm and capturing his zero day. We'd take the infected machines down asap to try and stop the attacker realizing they were suceeding, and to avoid any bad press (el reg almost had us at one point, cough cough). The final week we ended up with a linux box serving a static version of the site while waiting for the fix. So be careful how you gloat or complain about the frequency of fixes. Lets just rejoice that we've been given the tools so quickly and move on and be professional.
Biting the hand that feeds IT
