Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Shellshock



Bill Ricker <bill.n1vux at gmail.com> writes:
> Code fuzzed on the ENV value *after* the function definition should
> not have been accepted at all. Executing it at function def time is a
> bug.

What troubles me most about this is how the bit of code that reads in
environment variables sends the function body string into the top of the
general purpose parser.  I.e. the start symbol is not function_body but
the start symbol for the whole shell language. I don't know yacc/bison
very well. Is there no easy way to call into the generated parser asking
for a different start symbol, something lower down in the grammar?  Or
else to share code between two generated parsers?

This seems the fundamental issue to me. That and the fact that what's
called is "parse_and_execute" not "parse_and_collect_parse_tree" or
whatever. The patches workaround this from outside, which is fine for
fixing in a hurry, but what's the long term fix? How it is now looks
really messy and hackish IMO. And the amount of C string manipulation in
that latest function name prefix/suffix protection patch makes me
nervous. But I'm not a regular C programmer, so maybe that's par for the
course for such things.

-- 
Mike Small
smallm at panix.com



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org