Date: Wed, 8 Oct 2014 17:30:41 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Thoughts on Shellshock and beyond >> Well, in the specific context of bash, where it's being singled out as >> a major contributing factor to the bug: how would you establish an >> out-of-band channel for exporting functions that keeps them separate >> from "pure" data? As far as I can tell, there is no trivial and >> portable way. > > Well, I think we can all think of a few options, some more portable > than others. The current namespace change is one option, obviously, But that's not really separating code and data, right? It doesn't feel like it follows the spirit of this phrasing: "When an existing construct in a system is widely expected to be used for storing data, avoid overloading it for use of storing code." ...because it very much overloads the syntax to store code alongside with the data, in a way that theoretically shouldn't but in practice may collide. It's not a whole lot better than the "separation" of CSS and JS in HTML, in the sense that both of them are sort of guarded by delineated by specific syntax structures. > 1) A single dedicated environment variable for all function exports. > e.g.: Ditto? > 2) A bash-specific file handle. Before forking, bash sets up a pipe > to share with it's child. What it's the 'exec' built-in, and the parent shell terminates before the new one gets a chance to run? What if control passes through an intermediate program that isn't bash? Cheers, /mz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ