Live data from Hacker News

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

seclists.org

51–52 of 52 posts

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

#51
post #35

Earlier quoted context omitted.

I think the cases where it's still a hole are probably obscure and/or unlikely in the wild, but I definitely think the response to this should have been to disable the feature altogether. It's a terrible idea and I'm really curious if anything actually uses it and should be using it .

It's used to export functions from one instance of bash to a child. Do you think that that's a terrible idea, or do you have a better idea of how to implement it? (The fix changes it so that exporting is done through specially named variables. Instead of exporting `x='() { :; };`, it now exports `BASH_FUNCTION_x()='() { :; };'`.)

Do any other shells do it? Afaik it's not part of the POSIX sh spec. So any script that does it is going to be extremely dependent on bash in particular.

It would take actual use cases to convince me it's not a terrible idea. No matter what it's a mechanism to throw arbitrary code into a script that has no say in it. This is not the sort of thing you should do because it seems cool, it should be the sort of thing you do because of a really compelling use case that necessitates it. The fact that afaik no other shell has implemented this behaviour since bash did (a couple of decades ago if I understand correctly?) would rather suggest there is a lack of need for this.

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

#52
post #50
post #46

Earlier quoted context omitted.

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.

I've fought with both of them in the past, and ultimately went back to MacPorts when I last reinstalled.

Homebrew was (at the time, maybe a year or so ago) missing a lot of things I wanted to use, and some packages broke for no obvious reason.

I'm sure some of it was the result of my rather frankensteinien setup by that point, but I have no real desire to reinstall things again until I have to.

MacPorts may be occasionally annoying, but at least it's usually in a way have come to understand. :)

Post reply on HN