Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Oct 2014 04:36:12 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Chet Ramey <chet.ramey@...e.edu>
Subject: Re: More parser odities

Eric - you probably want to CC: Chet on your new findings.  Added the CC.

On Wed, Oct 01, 2014 at 07:16:40PM -0500, Kobrin, Eric wrote:
> This oddity also allows bypass of the absolute_program protection added in the recent patches:
> 
> 
> $ env $'BASH_FUNC_#badname%%'=$'() { :; }\n/bin/ls () { echo wrongfunc; }  ' ./bash -c '/bin/ls'
> fbash: error importing function definition for `#badname'
> wrongfunc
> 
> 
> 
> 
> I really do think it is time to take a different approach for a long-term solution.
> 
> 
> -- Eric Kobrin
> 
> 
> On Oct 1, 2014, at 5:35 PM, "Kobrin, Eric" <ekobrin@...mai.com> wrote:
> 
> 
> > 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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ