oss-sec mailing list archives
Re: CVE-2014-6271: remote code execution through bash
From: Florian Weimer <fweimer () redhat com>
Date: Thu, 25 Sep 2014 14:37:26 +0200
On 09/24/2014 08:54 PM, Michal Zalewski wrote:
My main concern with the current patch is that still exposes the bash parser and function definition printer to attacks from the network. Bugs in those fairly large components could cause another critical issue.Yup, that surprised me when testing the patch, too - I can still get a function called HTTP_COOKIE, for example. I worry about potential side effects of parsing even in absence of parser bugs. In most object-oriented languages, such side effects are practically guaranteed. Bash may be saved by simplicity, but not sure how robust that assumption is.
The parser does make an effort to properly stage all operations for later execution, without executing them immediately.
There is certainly the question of incomplete state recovery on parse errors.
I've written more code in bash than I should have and never used function exports, or even realized that they exist. I wonder if they can be made optional (e.g., gated by a flag on the subprocess) without breakage.
I've been told that there are users. From what I can see, exported functions seem somewhat popular in test harnesses:
<http://codesearch.debian.net/search?q=export\+-f>Reportedly, some users even create the function definitions outside bash, so they rely function name and variable name being identical. But I honestly cannot see a way to preserve such an assumption.
A subprocess flag is unlikely to be present when it is needed. One common use case is to define and export functions in bash.profile, and expect them to exist in interactive shells created as grandchildren. The fix is to use bashrc instead of bash.profile and non-exported functions.
Another option may be to export them through specially prefixed variables, which should be transparent but minimize the risk of interfering with web servers and such.
I added suffixes as well, see the attached patch. This patch has seen some testing, but it certainly needs more. There are some possibilities for simplification if it's acceptable to use asprintf.
What do you think about this approach?(Chet, this patch is identical to the patch I sent to you a couple of minutes ago.)
-- Florian Weimer / Red Hat Product Security
Attachment:
variables-affix.patch
Description:
Current thread:
- atd (was: Re: [oss-security] Re: Healing the bash fork), (continued)
- atd (was: Re: [oss-security] Re: Healing the bash fork) Seth Arnold (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Christos Zoulas (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Tavis Ormandy (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Michal Zalewski (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Anthony Liguori (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Huzaifa Sidhpurwala (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Huzaifa Sidhpurwala (Sep 24)