Live data from Hacker News

Re: CVE-2014-6271 – remote code execution through bash

seclists.org

41–50 of 52 posts

Re: Re: CVE-2014-6271 – remote code execution through bash

#41
There seems to have been some confusion about the effect of this feature on PHP in previous threads on HN. If you are running mod_php you are unaffected even if you use exec / system etc as the Apache PHP SAPI doesn't pass the environment variables to the sub process.

However if you pass any user data (_POST, _GET, etc) into a system/exec etc call that sets an environment variable then you would be vulnerable.

Re: Re: CVE-2014-6271 – remote code execution through bash

#42
This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as normal if you use open source the way it was intended.

Re: Re: CVE-2014-6271 – remote code execution through bash

#43

This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as…

There are many ways to argue this way or that way.

I could argue, that there is a bug for over 20 years in open source and nobody discovered it? WTF? So Windows is better, because it does not has this bug in the first place?

There is no right or wrong. Open Source is not better and not worse. Everything has its place and its purpose.

Regarding those embedded device I can say, they don't use BASH. Because of size constraints they all use Busybox, which does not have this problem, like all those other Shells.

Re: Re: CVE-2014-6271 – remote code execution through bash

#44

This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as…

Devil's advocate: most OS X systems aren't running exposed services that could be exploited, and if you were running an OS X server you can always re-compile bash manually for something of this severity (and Homebrew/MacPorts make this even easier).

That said, I do think it's ridiculous though how slow Apple is. It's absolutely crazy. I can only hope that Heartbleed and now this are causing some major internal reviews over there...

Re: Re: CVE-2014-6271 – remote code execution through bash

#45
post #21

Earlier quoted context omitted.

Jessie isn't released / stable and doesn't receive security patches until it is. It's called testing for a reason.

debian testing do receive security patches, but it is not a priority so they may not get there in a timely manner.

Yeah. I'm aware that stable and old stable need to be patched first, I was just surprised by how much time it took considering the kind of risk (and being beaten by sid, the kid whom always breaks his toys).

Re: Re: CVE-2014-6271 – remote code execution through bash

#46
post #44

This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as…

Devil's advocate: most OS X systems aren't running exposed services that could be exploited, and if you were running an OS X server you can always re-compile bash manually for something of this severity (and Homebrew/MacPorts make this even easier). That said, I do think it's ridiculous though how slow Apple is. It's absolutely crazy. I can only hope that Heartbleed and now this are causing some major internal review…

Even though I've got MacPorts bash installed, it lives in /opt/local/bin, while the default one in /bin/{ba,}sh is the ancient apple 3.2 one.

https://apple.stackexchange.com/questions/146849/#146851 has a simple enough step-by-step guide to patching & recompiling the system version with the appropriate patches, if you've got XCode installed and are comfortable with that sort of thing.

Agreed on the Apple security response time though. I reckon they have all their best guys fighting the IOS jailbreakers :P

Re: Re: CVE-2014-6271 – remote code execution through bash

#47

This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as…

I don't want to defend Apple too much – at various points I spent many months hoping nobody else discovered a MITM exploit before they shipped the next OS release – but this is a near-complete non-issue for an OS X desktop user and even servers have fairly limited exposure.

If you want to beat Apple up, a much better case was goto fail where they left all of the Mac users hanging for a long period of time after shipping the iOS patch and disclosing the vulnerability.

Re: Re: CVE-2014-6271 – remote code execution through bash

#48

This issue is an awesome demonstration of how bad closed ecosystems are. The open systems that are running on Linux (RedHat, ubuntu, etc) are 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 also stuffed (we've got to moved to open router firmware like OpenWRT). Basically, you can carry on as…

How is OSX a closed system in this particular case? You can easily compile bash, with patches, and replace the system binary -- using the same code that's used to build those Debian/Redhat/whatever binary. Its all the same gnu code.

What about all those EOLed distros that don't see most security updates? Being "Open" is a non-issue here.

Re: Re: CVE-2014-6271 – remote code execution through bash

#49
post #29

And I'd like to thank Gentoo developers for the usual very fast response they had towards this security advisory. The moment I saw the news here, I ran to update my stuff -- the patch was already there, marked stable in the official gentoo repositories. My impression is that they're following very closely the progression of this event and the relevant GLSA entries are being updated without any noticeable delays. Than…

Same with Ubuntu, which I run on my servers. It was patched by the time I had SSH'd in.

Re: Re: CVE-2014-6271 – remote code execution through bash

#50
post #46
post #44

Earlier quoted context omitted.

Devil's advocate: most OS X systems aren't running exposed services that could be exploited, and if you were running an OS X server you can always re-compile bash manually for something of this severity (and Homebrew/MacPorts make this even easier). That said, I do think it's ridiculous though how slow Apple is. It's absolutely crazy. I can only hope that Heartbleed and now this are causing some major internal review…

Even though I've got MacPorts bash installed, it lives in /opt/local/bin, while the default one in /bin/{ba,}sh is the ancient apple 3.2 one. https://apple.stackexchange.com/questions/146849/#146851 has a simple enough step-by-step guide to patching & recompiling the system version with the appropriate patches, if you've got XCode installed and are comfortable with that sort of thing. Agreed on the Apple security res…

You should jump to using Homebrew. It's superior in most ways. I'd used MacPorts and Fink before Homebrew came about and I never much liked either. Homebrew is as simple as it can be and is really good at detecting conflicts which MacPorts and Fink were terrible at.
Post reply on HN