A remotely exploitable hole in bash

Posted Sep 26, 2014 17:36 UTC (Fri) by marcH (subscriber, #57642)
In reply to: A remotely exploitable hole in bash by raven667
Parent article: A remotely exploitable hole in bash

> It's easy to point fingers and say that they were stupid or did a bad job in retrospect with 20+ years of experience behind us

I think it all comes down to this: when CGI was invented (20 years ago already?!) had people generally realized that some people on the Internet were not going to be nice? This is a genuine question.

(Answering it might reveal your age, sorry)

> but it's harder to say that given the constraints of the system and the knowledge of the time that you wouldn't have made the same decisions given the same inputs.

Based on the beat... feedback I usually get to "get it done" I could still be reasonably optimistic :-)

More revelant: why the hell is CGI still in use in the same sorry state 20 years and a millions of (not related) security scandals later? OK: now I guess I just need to google "Worse is Better" and do some reading.

A remotely exploitable hole in bash

Posted Sep 26, 2014 18:06 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

Remote exploits were (in principle) already a known thing, since the Morris worm was unleashed in 1988.

A remotely exploitable hole in bash

Posted Sep 26, 2014 21:00 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> had people generally realized that some people on the Internet were not going to be nice

That viewpoint was out there but wasn't a widely heeded, what we consider normal security engineering today would be considered high paranoia at the time. Packet-filtering firewalls were a new technology at the time and adding DMZs to networks was a radical new thing that people argued about. Having open SMTP relays was considered good form as well 8-)

> feedback I usually get to "get it done"

Yep.

Also passing data in environment variables is a very UNIX-y way to do things which was dominant at the time.

A remotely exploitable hole in bash

Posted Sep 28, 2014 14:29 UTC (Sun) by kleptog (subscriber, #1183) [Link] (3 responses)

The CGI interface is still around because it happens to work really really well. It's allows the webserver to be flexible about which parameters it sends. The CGI script doesn't have to do any fancy parsing, because every parameter is just a getenv() away. It's supported by every programming language.

Offhand I can't think of any other case of something being executed out of an environment variable. Most programs just look at the variables they're interested in and ignore the rest. What bash is doing here (looping over variables to find those whose *value* match a particular pattern) is I think pretty rare.

There is no other interface that is anywhere near as easy to use. Stuff like FastCGI has traction in certain areas, but it's already much more complicated.

A remotely exploitable hole in bash

Posted Sep 28, 2014 16:09 UTC (Sun) by marcH (subscriber, #57642) [Link] (1 responses)

> There is no other interface that is anywhere near as easy to use.

There is no doubt that insecure is always more convenient, actually most of the time insecure is *much* more convenient. The question was: how many more security scandals are required before secure coding starts being seriously rewarded and laziness punished by the market place? No simple answer I'm afraid.

> Offhand I can't think of any other case of something being executed out of an environment variable. Most programs just look at the variables they're interested in and ignore the rest.

"Most" does not work a security perspective. All details here:
http://www.dwheeler.com/secure-class/Secure-Programs-HOWT...

A remotely exploitable hole in bash

Posted Sep 29, 2014 10:55 UTC (Mon) by nye (subscriber, #51576) [Link]

>> There is no other interface that is anywhere near as easy to use.
>There is no doubt that insecure is always more convenient, actually most of the time insecure is *much* more convenient. The question was: how many more security scandals are required before secure coding starts being seriously rewarded and laziness punished by the market place? No simple answer I'm afraid.

Imagine the alternative: that there is no standardised way to pass variables across processes and every program needs to implement its own custom parser. That would be a nightmare, and you'd be making pretty much the same complaint, probably suggesting that the only sensible thing to do is to have it done exactly as it is now, so that the parsing is implemented in one shared implementation.

You're a very judgemental person, but in the real world it's likely that anyone reading code you've written would be bitching just as much about your scandalous laziness.

A remotely exploitable hole in bash

Posted Sep 28, 2014 18:29 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> Stuff like FastCGI has traction in certain areas, but it's already much more complicated.

I've found using spawn-fcgi works really nicely for keeping CGI services in a separate jail from the webserver itself. So you can write your CGI program then just use the wrapper.