[I am terribly sorry that my In-Reply-To is wrong :/] ----- "Eric Blake" <ebl...@redhat.com> wrote:
> ... Remember, the security hole of > Shell Shock is NOT what the function is named, but the fact that > arbitrary variable contents were being parsed. ... Not quite: the point of exploit can be in the variable name. $ env 'date;x=() { :;}' bash --norc -c : Sat Sep 27 20:40:41 UTC 2014 Segmentation fault (core dumped) $ bash --version | head -n 1 GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu) While AFAIK you can't create functions with names that eventually lead to dangerous variable names, this is due to a quoting requirement (to place that ";", for example, in a function definition statement, I'd have to quote it, and check_identifier refuses to allow any quoted characters) that happens when parsing the function as it is created "in the first place" that are not quite so easily replicated when trying to use check_identifier to validate the name before importing the function (hence why, even with the patch I provided yesterday that verifies function names before importing using a mechanism similar to that used for definitions, I still rely on SEVAL_FUNCDEF to catch "date;x": the ; has not been "quoted", so check_identifier considers it not to be a problem; incidentally, this is why my original patch concept, before I understood the new SEVAL_FUNCDEF and verified it was sufficient as in the patch I provided yesterday, involved running the name itself through the parser to verify it was a single word).