Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Sep 2014 14:17:44 -0400
From: Chet Ramey <chet.ramey@...e.edu>
To: Tavis Ormandy <taviso@...xchg8b.com>, Florian Weimer <fw@...eb.enyo.de>
CC: chet.ramey@...e.edu, Michal Zalewski <lcamtuf@...edump.cx>,
        Solar Designer <solar@...nwall.com>, oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash

On 9/27/14, 10:28 AM, Tavis Ormandy wrote:

> It does look bad, but are you sold on the prefix/suffix solution Chet?
> That will at least mean these are not security issues.

Yes.  I have no problems worth mentioning with the exported function
encoding approach.  I have attached patches implementing it that can
be applied to bash versions from bash-2.05b to bash-4.3.  Please take
a look, make sure they can be applied cleanly, and so on.

There is another discussion worth having before officially releasing
these, which I will do later today.

The original set of patches (bash43-025 and its siblings) tightened the
restrictions on allowable imported function names, forcing them to be
shell identifiers.  The shell itself, when not in posix mode, allows
virtually any character that is not a shell metacharacter to appear in
a function name (that's basically the difference between an identifier
and a word in shell-grammar-speak).  This results in the ability to
define functions like this:

$ function /bin/echo () { builtin echo whoops; }

and have this happen:

$ /bin/echo
whoops

along with exporting these functions and importing them without complaint.

This is obviously bad, and I removed the ability to do this in the first
patch in the event that someone figured out an easy way to remotely
specify an arbitrary variable name before we implemnted something to stop
it.

The problem is that it's too restrictive.  There are folks who have taken
advantage of this flexibility to define, use, and export functions like

STD::what::does::this::do

which are no longer allowed.  This is a pretty bad break with backwards
compatibility.

So what's your opinion on the appropriate set of restrictions? This is a
question that goes farther than what a particular shell will import,
since I'm going to align the restrictions on what functions a shell will
import from the environment with what functions that shell will let a
user define.  That means that a posix-mode shell will require imported
functions to be valid identifiers, but a non-posix mode shell will allow
words.  The original check that was in bash-4.3 does this.  What additional
checks should there be? I can see starting with rejecting function names
that can be confused with pathnames.

Please chime in and let me know what you think.

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

View attachment "funcexport-encode-2.05b.patch" of type "text/x-patch" (5759 bytes)

View attachment "funcexport-encode-3.0.patch" of type "text/x-patch" (5763 bytes)

View attachment "funcexport-encode-3.1.patch" of type "text/x-patch" (5705 bytes)

View attachment "funcexport-encode-3.2.patch" of type "text/x-patch" (5705 bytes)

View attachment "funcexport-encode-4.0.patch" of type "text/x-patch" (5705 bytes)

View attachment "funcexport-encode-4.1.patch" of type "text/x-patch" (5705 bytes)

View attachment "funcexport-encode-4.2.patch" of type "text/x-patch" (5705 bytes)

View attachment "funcexport-encode-4.3.patch" of type "text/x-patch" (5931 bytes)

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