[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5426FF48.2030106@case.edu>
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
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.
