oss-sec mailing list archives

Re: More parser odities


From: Chet Ramey <chet.ramey () case edu>
Date: Wed, 01 Oct 2014 22:06:39 -0400

On 10/1/14, 8:36 PM, Solar Designer wrote:
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 () akamai 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

Two things.

First, there is already a fix for this in the patch pipeline.

Second, given the existence of the bash-4.3.27 and vendor and previous
version equivalents, this is not a security problem.  What we are coming
up with is more and more esoteric ways to execute commands bash allows
you to execute directly.  There isn't a local privilege escalation issue,
and the game is already over if you allow someone to specify arbitrary
environment variable names and values.

Please keep the reports coming.  They're valuable in making bash better;
they're just not security problems or vulnerabilities.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet () case edu    http://cnswww.cns.cwru.edu/~chet/


Current thread: