On 09/26/2014 02:22 PM, Linda Walsh wrote: > Eric Blake wrote: > >> They are not portable to broken bash. But the argument in these threads >> is that bash's implementation of function exports should be changed so >> that _fixed_ bash will once again be POSIX compliant and let this >> bog-standard assignment work regardless of contents. If Chet accepts >> Florian's patch [1] to change function exports to use BASH_FUNC_foo()= >> instead of foo= (which is what Red Hat is already using in their fixes >> pushed today), then this POSIX compliance bug in broken bash will be >> avoided. >> >> [1] http://www.openwall.com/lists/oss-security/2014/09/25/13 >> > ---- > IS this added only in memory? I.e. no changes to source code? > > What prevents BASH_FUNC_foo = '(){ :; ...'; Nothing, as you wrote it, because you have no () on the left of the equal. Florian's patch makes it so that the child bash sees your example as a NORMAL variable, and so you get "echo $BASH_FUNC_foo" outputting "(){...". What matters is that 'export -f foo' results in 'BASH_FUNC_foo()=...' in the environment (note the parens on the left of the equal). As this is NOT a valid shell variable name, you have now cleanly separated the namespace, and arbitrary contents of a shell variable can no longer be coerced into a function. And yes, you could still pass this arbitrary name via env or other means, but remember that this exploit is not about the NAME of the variable, but that arbitrary CONTENTS of a fixed name in the environment were parsed rather than being treated as a string literal (in violation of POSIX). By separating namespaces, bash no longer violates POSIX, and programs like apache that stick arbitrary contents into fixed-name variables (but which do NOT create arbitrary-name variables) are no longer subject to the parser intercepting their contents. > > Why is there a need for a long prefix on top of switching > the ()/= order? only to make it all the more clear that this is a hand-shaking mechanism between bash parent and child, and NOT something that most other processes will care about. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
