Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 06:47:18 +0400
From: Solar Designer <>
To: Chet Ramey <>
Subject: Re: CVE-2014-6271: remote code execution through bash

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).


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.