[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <C39634D7-0B3F-4377-ADA5-A0096C0D628B@akamai.com>
Date: Wed, 1 Oct 2014 16:35:49 -0500
From: "Kobrin, Eric" <ekobrin@...mai.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: More parser odities
Using bash from the GNU git, subsequently patched to level 28:
$ env $'BASH_FUNC_#badname%%'=$'() { :; }\nfoo () { echo wrongfunc; } ' ./bash -c 'foo'
./bash: error importing function definition for `#badname'
wrongfunc
This is an artifact of the name and value being passed directly to parse_and_execute, separated by a space. Structures started in the name such as comments, quoted strings, etc. are allowed to continue into the body. Some of the existing safety checks stop the obvious attacks, but things like this can still get through.
I don't know of a safe way to pass the contents of an environment variable to parse_and_execute. Has anyone worked on a simplified grammar which could be more rigorously checked?
If there were one, with a parser called bash-simple-parse in following example, this problem would be easier to manage.
This way `function f() {...}' can be parsed, but `export -f f' could store a version of the function readable by bash-simple-parse. The function importer can then call bash-simple-parse and extract a function definition, knowing that nothing other than a function definition (not even the name) will be returned. That result can then be bound to the name provided, directly in the variable setup function without ever invoking the general parser.
Thoughts?
-- Eric Kobrin
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
