BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Shellshock
- Subject: [Discuss] Shellshock
- From: smallm at panix.com (Mike Small)
- Date: Wed, 01 Oct 2014 11:01:52 -0400
- In-reply-to: <CAAbKA3U4r-rxkAW33HPfv6FJE36rqDJx6qESbrS4r7G_VBN1Mw@mail.gmail.com> (Bill Ricker's message of "Tue, 30 Sep 2014 22:59:53 -0400")
- References: <542B5DFA.2080108@gmail.com> <542B5F49.3050500@gmail.com> <CAAbKA3U4r-rxkAW33HPfv6FJE36rqDJx6qESbrS4r7G_VBN1Mw@mail.gmail.com>
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
- Prev by Date: [Discuss] CipherShed: TrueCrypt fork
- Next by Date: [Discuss] Shellshock
- Previous by thread: [Discuss] CipherShed: TrueCrypt fork
- Next by thread: [Discuss] Shellshock
- Index(es):