Not a bash bug • Hacker News Board

Re: Not a bash bug

#21

Post by nly » Sat, Sep 27, 2014, 9:25 AM UTC

meelooo wrote: post #4

It's an "internet tech" bug. Every developper should know how hard it is to parse textual data vs well defined binary in a secure and fool proof way. Yet every damn internet piece of infrastructure is based on handling textual data, mash it up, pass it around, escape and unescape it in hundreds of stupid formats. No wonder that most security troubles surfacing over the years are some form of abuse of this crazy desig…

All very well said, but until tools like Protocol Buffers became popular the tooling for working with custom binary protocols has been pretty dire.

Re: Not a bash bug

#22

Post by danielparks » Sat, Sep 27, 2014, 9:26 AM UTC

ahy1 wrote: post #2

> This feature is documented under the -f option of the export built-in command. The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature. This undocumented implementation detail is also a limitation on the use of regular environment variables, and should be…

I agree with all your points.

I think the real bug is that all this stuff calls out to a shell at all. Sure, it's convenient, but it's basically eval().

Re: Not a bash bug

#23

Post by 0x0 » Sat, Sep 27, 2014, 9:31 AM UTC

Still sounds like a bug in bash to me.

What if I have a printer called "() { :;}; echo lol", so I manually export PRINTER="() { :;}; echo lol" (see http://www.tldp.org/HOWTO/Printing-Usage-HOWTO-4.html)

I don't think this was the intended behavior even 25 years ago. :)

Re: Not a bash bug

#24

Post by vidarh » Sat, Sep 27, 2014, 9:34 AM UTC

nailer wrote: post #20

vidarh wrote: post #12

Earlier quoted context omitted.

Apache does not in general know whether or not data will be passed to bash. And they can't take into account all possible contexts, because that would involve reading the mind of all possible future users of the interfaces they provide, to make sure none of them decides to call out to programs that treats previously inert data as code.

Apache knows what data Apache passes it its own sub processes, which is the issue here. Nobody is expecting Apache to sanitise other apps, just itself.

But without knowing how other apps treat that data, Apache can not know what needs to be done to sanitize the data.

For what Apache knows, that CGI it executes could treat the presence of the letter "x" in any environment variable as "start a nuclear war".

While it may make sense for Apache to sanitize the data against specific known, common problems, until this week this was not a specific known problem. It might have been if the Apache team audited the code of every plausible piece of code that people might use to interpret CGI scripts, but that's not a realistic scenario.

Re: Not a bash bug

#25

Post by scintill76 » Sat, Sep 27, 2014, 9:41 AM UTC

nailer wrote: post #20

vidarh wrote: post #12

Earlier quoted context omitted.

Apache does not in general know whether or not data will be passed to bash. And they can't take into account all possible contexts, because that would involve reading the mind of all possible future users of the interfaces they provide, to make sure none of them decides to call out to programs that treats previously inert data as code.

Apache knows what data Apache passes it its own sub processes, which is the issue here. Nobody is expecting Apache to sanitise other apps, just itself.

AFAIK Apache itself isn't vulnerable, because it probably doesn't invoke a shell. CGI apps it invokes might, which is how the vulnerability is triggered.

Re: Not a bash bug

#26

Post by sandstrom » Sat, Sep 27, 2014, 9:42 AM UTC

Using Nginx, how could one filter/drop/reject http requests where a http header start with "() {"?

I know patching `bash` is most important (and I have). But it would give some extra comfort.

Re: Not a bash bug

#27

Post by icebraining » Sat, Sep 27, 2014, 9:43 AM UTC

meelooo wrote: post #4

It's an "internet tech" bug. Every developper should know how hard it is to parse textual data vs well defined binary in a secure and fool proof way. Yet every damn internet piece of infrastructure is based on handling textual data, mash it up, pass it around, escape and unescape it in hundreds of stupid formats. No wonder that most security troubles surfacing over the years are some form of abuse of this crazy desig…

Please describe specifically how would that have helped.

This has nothing to do with parsing text. The problem here is that Apache et all send untrusted data to a process that treats it as code. It wouldn't matter if HTTP was a binary protocol and if bash read a well defined bytecode instead. I mean, look at shellcodes.

Re: Not a bash bug

#28

Post by meelooo » Sat, Sep 27, 2014, 9:43 AM UTC

fabulist wrote: post #9

meelooo wrote: post #4

It's an "internet tech" bug. Every developper should know how hard it is to parse textual data vs well defined binary in a secure and fool proof way. Yet every damn internet piece of infrastructure is based on handling textual data, mash it up, pass it around, escape and unescape it in hundreds of stupid formats. No wonder that most security troubles surfacing over the years are some form of abuse of this crazy desig…

I really don't think making protocols less understandable by humans will solve anything. This has always been and always will be a hard problem. Consider this quote which I found in The Shellcoder's Handbook: "Wherever terms have a shifting meaning, independent sets of considerations are liable to become complicated together, and reasonings and results are frequently falsified." -- Ada Lovelace We've known about this…

It's not about making protocols less understandable by humain, it's about recognising that we are programming computers, not humans and that it's time we accept that there should certainly be a way for the humans to interact with the program at some point we should not force the same kind of interactions on the programs themselves. It's much harder to make text and text based commands' parsing and handling secure than it is to use binary protocols in the first place.

Re: Not a bash bug

#29

Post by vidarh » Sat, Sep 27, 2014, 9:43 AM UTC

fabulist wrote: post #18

tomjen3 wrote: post #15

Earlier quoted context omitted.

It has permission to trust the input the user enters into it, because that is its job. 20 years ago nobody assumed variable environments were an issue, but this should have been fixed years ago. I am also pissed that they patched the parser, the feature is still in there when nobody uses it and it has already proven to be a security vuln once.

Its used by bash itself for communicating with subprocesses. Input you type at the terminal is not the same as an environment variable; hackers set environment variables much more often than legitimate users.

There are many other ways Bash could do that, though, which would make it much harder for further exploits. Such as opening a pipe and writing them to the sub-process that way so it goes "out of band" from the regular environment variables. Or if it has to be in environment variables: Accept a special argument in the argument list that is a key it uses to sign the variables. It does not need to remain secret - just make sure that just inheriting environment variables with potential attempted exploits is insufficient for anything to get executed.

And/or change the way these definitions are handled - I get that it's tantalizingly simple to just pass this through their usual parser since then you get the function definition parsing for free, but at the very least this parsing of the environment variables shouldn't go through a code path that even potentially executes anything.

Re: Not a bash bug

#30

Post by saurik » Sat, Sep 27, 2014, 9:49 AM UTC

The original author of bash (a friend of mine, which is why I have this context) has been being interviewed by various newspapers today regarding shellshock, and finds the idea that he might have anticipated the number of ways people integrated bash into various systems (such as with Apache allowing remote control over environment variables when running software in security domains designed to protect against unknown malicious users) quite humorous. Apparently, it has been an uphill battle to explain that this was all coded so long ago that even by the time he had already passed the project on to a new developer (after having maintained it for quite a while himself) the World Wide Web still wasn't a thing, and only maybe gopher (maybe) had been deployed: that this was even before the Morris worm happened...

> In an interview Thursday, Mr. Fox, the Bash inventor, joked that his first reaction to the Shellshock discovery was, “Aha, my plan worked.”

http://mobile.nytimes.com/2014/09/26/technology/security-exp...