[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <542436C9.1080502@case.edu>
Date: Thu, 25 Sep 2014 11:37:45 -0400
From: Chet Ramey <chet.ramey@...e.edu>
To: Solar Designer <solar@...nwall.com>
CC: chet.ramey@...e.edu, oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash
On 9/24/14, 10:47 PM, Solar Designer wrote:
> On Wed, Sep 24, 2014 at 03:12:08PM -0400, Chet Ramey wrote:
>> There are several options for making shell functions inherited via the
>> environment more robust, none of them backwards compatible. I will
>> choose one and implement it for a future bash version.
>
> While we're at it, I think it's preferable not to output error messages
> triggerable by untrusted input, e.g.:
>
> $ ssh -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'
> bash: warning: SSH_ORIGINAL_COMMAND: ignoring function definition attempt
> bash: error importing function definition for `SSH_ORIGINAL_COMMAND'
>
> (as seen with the current bash patches). This might be unnecessarily
> revealing or/and it might confuse whatever other program was invoking
> something via bash, resulting in attacker-triggerable unintended
> behavior in that caller program. Yes, there are numerous other error
> conditions anyway - such as running out of memory - which may result in
> messages printed to stderr. Yet we might want to avoid printing error
> messages for environment variable value parsing errors (ideally, we'd
> avoid the parsing itself as well), unless a debugging or a verbose mode
> is enabled locally (in a way that can't realistically be triggered via
> an unsuspecting network service).
I disagree. It's important for a program -- not just the shell -- to tell
the user when it attempts to do something on his behalf and is unable to
do it.
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/
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.
