[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 06:47:18 +0400
From: Solar Designer <solar@...nwall.com>
To: Chet Ramey <chet.ramey@...e.edu>
Cc: oss-security@...ts.openwall.com
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).
Alexander
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.
