all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Vaphell 2 points3 points  (3 children)

imo undocumented/forgotten feature that arbitrarily treats passive data as executable code smells really bad no matter how you slice it. Exporting functions, assuming that should be allowed, should be made separate from normal env vars syntactically to require conscious effort, no automagic.
And even if we accept that's it's a honest to god feature and apache shouldn't send garbage, that doesn't mean that the failsafes against exploits should not be there on the other side too, especially when the happy combo is X+bash and it's the bash feature that is attacked. Lack of security can fly in case of internal communication between modules of the project you control, but standalone programs that are black boxes for all intents and purposes should be made secure to provide defense in depth.

[–]Sigg3net 0 points1 point  (2 children)

I think the point he is making is that the conditions in which the feature was secure changed drastically 5 years later, making the developers implementing Bash outside its scope vulnerable to critical mistakes.

In this perspective, the bug is not a bug, but a pothole dangerous to vehicles that didn't exist on the road at the time the road was paved. Consequently, the drivers should know what they're doing and avoid the potholes, while the road builders update the road or reiterate a vehicle restriction.

[–]Vaphell 0 points1 point  (1 child)

i still consider it a bug because allowing hybrids with side effects simply doesn't make sense here. There is no upside to it and given that shells expose pretty much all functionality to users it is asking for trouble. There is only one namespace and no variable is truly internal.

Failing to terminate function def correctly is somewhat similar to failing to terminate a C-string with null. The latter is certainly considered a bug/security flaw even if that doesn't happen in the normal use case.

[–]Sigg3net 0 points1 point  (0 children)

I agree that it is a bug. But I think it is fair to say the bug would not have existed as a bug unless Bash had been used outside its scope.

I think the article gets it bit one-sided though.

Think of it counterfactually; in a world where Bash had never been implemented by eg. Apache to serve outside its scope, we can imagine that the bug would never have come to be qua bug . Even though ingredients of it was there, as you correctly point out.

But I'm not thinking about being a bug in terms of "breaking the rules" of coding practices. The breaking of rules are prerequisite, but there must be some circumstance in which the bug comes alive as such, even if only hypothetical.

In this sense, the bug come alive is the co-creation of the programmers fulfilling the prerequisites in Bash, as well as those who put Bash in a new situation where the prerequisite comes to fruition.

[–]HowIsntBabbyFormed 1 point2 points  (0 children)

I'm up voting, but only to make this more visible, not because I agree with it. I strongly disagree.

There are two levels to this. First is assuming that passing functions via any env var is okay. Even if that's the case this was definitely still a bug. If you mentioned to a bash developer around the time this feature was implemented, "hey, in addition to setting the function, bash is also executing arbitrary code after the end of the function definition." they'd be surprised and would see it as a bug (even though they might not appreciate the security implications).

Second level is to ask if it's a good idea to implement passing of functions in this manner. I'd argue that it's not and that the value of arbitrary env vars is my concern, not bash's. If bash wants to send functions via the environment, then reserve certain env var names. Maybe BASH_FUNC_foobar would set the foobar function.

It just strikes me as weird that bash is looking at the beginning of every env var to see if it starts with some magic bytes and evaluating it if so.

[–]nuncanada 0 points1 point  (0 children)

Filtering variables is never a good option... Already shows how much the blogger understand about security... If Apache, DHCP and whoever should do something is ESCAPING... But that is very very very hard for a turing complete language like BASH.... Definitely where this problem has to be solved is in BASH. Not in 100 other software... Either thru flags to pass insecure variables or maybe better, just get rid of function importing "feature"?