For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and am going to apply the CVE-2014-7169 patch as well once it passes review. Repository and instructions to reproduce without trusting me are located here:
CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
201–210 of 226 posts
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#202Earlier quoted context omitted.
All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.
Ubuntu symlinks /bin/sh to /bin/dash by default as of some ancient version. This is pretty annoying and I often end up manually undoing it and linking it to /bin/bash when a script fails in spectacular ways (dash doesn't support some bash-specific niceties). It's merely a fortunate accident for Ubuntu that this type of bug was discovered in bash, not dash.
So those shell scripts use bashisms but don't use #!/bin/bash and instead have #!/bin/sh ?
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#203All this "echo date, cat echo" business is confusing.
Let me fix that for you.
hobbes@metalbaby:~$ export badvar='() { (a)=>\'
hobbes@metalbaby:~$ bash -c "somestring executeMe"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
bash: executeMe: command not found
hobbes@metalbaby:~$ cat somestring #it exists but is empty.
hobbes@metalbaby:~$ bash -c "somestring date"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
hobbes@metalbaby:~$ cat somestring
Thu Sep 25 11:01:35 CDT 2014
hobbes@metalbaby:~$ bash -c "somestring echo hello"
bash: badvar: line 1: syntax error near unexpected token `='
bash: badvar: line 1: `'
bash: error importing function definition for `badvar'
hobbes@metalbaby:~$ cat somestring
hello
For this one, an attacker needs to control both the environment AND the command line of the child shell.
People, if those criteria are met, the attacker wins, with or without bugs.
Yes, yes, there are situations where the attacker has partial control of the command line via a filename argument or whatever--whatever indeed! That's not even in the same category as the first bug.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#204Earlier quoted context omitted.
OS/X does use bash as /bin/sh unfortunately so it is fairly vulnerable. Probably most people won't be affected though since there aren't many good attack vectors against a client machine, and not many people are still using macs for servers. I don't think that the issue is overblown at all though. CGI is old and crusty but it's sitting in all sorts of random places. All you need to do is to find a script that will ca…
bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache). Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options. The attacker also has to have a local…
I generally agree with this, but I do have a few nitpicks.
> Comparing this to Heartbleed is pretty absurd
They're such different bugs that they're hard to compare. Heartbleed definitely affected more high-value targets, however the exploit just gave you some RAM contents. It would still be some manual work to figure out what those values meant (whcih bits are ssh keys, which are passwords, ...) and leverage them. Shellshock is much better suited for a "sweep all of IPv4, build a botnet" scriptkiddie attack.
> bash CGI in particular are basically unheard of
The CGI doesn't have to be written in bash, it just has to call something that calls something that ends up calling system()/popen()/whatever. There are probably lots of such cases. Once httpd puts the poisonous string in your environment it's going to be passed down to all of your subprocesses. If you're using CGI at all on a machine with /bin/sh==bash you should assume you're vulnerable.
> They live on controlled networks where rogue DHCP servers can't be operated.
If you're on a network with nodes you don't trust (public wifi, large corporate networks, etc) there is a risk that machines other than the router will reply to broadcast DHCP requests. I don't know the full scope of this attack vector yet but I wouldn't be blasé about it.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#205Appears to work, even with latest patches, by using sh (from the link): $ env X='() { (a)=>\' sh -c "echo date"; cat echo date Wed Sep 24 15:00:34 PDT 2014 -- previous bug fix for bash (before/after patch) -- $ x='() { :;}; echo vulnerable' bash -c 'echo test' vulnerable test $ x='() { :;}; echo vulnerable' bash -c 'echo test' bash: warning: x: ignoring function definition attempt bash: error importing function defin…
I don't think either you or the author are correct. hobbes@media:~$ env X='() { (a)=>\' sh -c "echo date"; cat echo date cat: echo: No such file or directory hobbes@media:~$ uname -a Linux media 3.13-1-686-pae #1 SMP Debian 3.13.5-1 hobbes@media:~$ echo $BASH_VERSION 4.3.25(1)-release It looks to me like we're setting X in the environment, calling `sh -c "echo date"`, passing that X in to it, nothing happens, then we…
> I don't think either you or the author are correct.
This is out of date, but I can't edit my comment anymore.
Carry on. :)
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#206Earlier quoted context omitted.
bash on OSX is vulnerable, but as you say, there are few attack vectors. A client OSX machine with a stock config is not vulnerable. At a minimum, you have to enable a network service like printer sharing (CUPS), remote login (ssh), web sharing (Apache). Then you have to configure the service in such a way to actually be vulnerable, and these are not commonly configured options. The attacker also has to have a local…
I generally agree with this, but I do have a few nitpicks. > Comparing this to Heartbleed is pretty absurd They're such different bugs that they're hard to compare. Heartbleed definitely affected more high-value targets, however the exploit just gave you some RAM contents. It would still be some manual work to figure out what those values meant (whcih bits are ssh keys, which are passwords, ...) and leverage them. Sh…
> They're such different bugs that they're hard to compare.
I mentioned it because people are having a field day comparing the two (which results in some good old fashioned fear mongering). A random sampling:
CNet: 'Bigger than Heartbleed'
Gizmodo: Why the Bash Shellshock Bug Could Be Even Worse Than Heartbleed
Mashable: Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed
The Independent: Shellshock: Bash bug 'bigger than Heartbleed' could undermine security of millions of websites
Errata Security: Bash bug as big as Heartbleed
This was covered in my second item, about using system(). I'm certain that there is software out there that does this, but it is in no way common or has ever been best practice.
The panic over this presumes that people use CGI all the time. It's awful, it's always been awful, and should never be used for anything public facing for lots of other reasons. Note that FastCGI is not impacted.
> If you're on a network with nodes you don't trust
Correct, but this isn't the case for most (but not all) server deployments. In your own datacenter environment, you control the network and all of the hosts on it -- if someone busts in to run a DHCP server, you have bigger fish to fry.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#207Earlier quoted context omitted.
Is this an alternative to the bash upgrade or is this needed to fix the issue after the bash upgrade (because of an incomplete patch)?
It's a workaround that should be used if you must mitigate the issue right at this moment. Applying the update, once it's available, should do the same thing. Note that the workaround might have some unintended consequences as mentioned in the FAQ section of [1]. [1] https://access.redhat.com/articles/1200223
[deleted]
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#208What tools are people using to track and push out security updates, if any? Right now I only have a few servers to administer so apticron is sufficient for notification and upgrading isn't a burden. Also, does anyone have a way to push out patched packages fast? Imagine that a patch is available, or it's trivial to remove a feature that you're not using, but the distribution hasn't made a package yet. I have been dre…
On Debian or Ubuntu, install the unattended-upgrades package. Configure it to install security updates only. > ...but the distribution hasn't made a package yet. On Ubuntu, I think you can probably set up a Launchpad PPA and then configure unattended-upgrades to automatically pull from it. Then just push what you need to that PPA when you're ready. If you want to host the repository elsewhere, then that's possible to…
For anyone who doesn't know, there's also a similar "yum-updatesd" for RHEL and derivatives like CentOS, though it only gives notifications of updates IIRC.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#209Reproduced from my comment on the discussion of the previous CVE The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)= Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.
[deleted]
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#210Reproduced from my comment on the discussion of the previous CVE The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)= Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.
[deleted]
I think you screwed up your test, I have not managed to get it to work with the LD_PRELOAD workaround installed.