Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Sep 2014 15:17:55 +0400
From: Loganaden Velvindron <loganaden@...il.com>
To: oss-security@...ts.openwall.com
Cc: Chester Ramey <chet.ramey@...e.edu>, Christos Zoulas <christos@...las.com>
Subject: Re: Re: Re: CVE-2014-6271: remote code execution
 through bash (3rd vulnerability)

On Sun, Sep 28, 2014 at 8:52 PM, Bryan Drewery <bdrewery@...ebsd.org> wrote:
> On 2014-09-26 15:52, Bryan Drewery wrote:
>>
>> On 9/26/2014 9:13 AM, Christos Zoulas wrote:
>>>
>>> On Sep 26,  1:47pm, john.haxby@...cle.com (John Haxby) wrote:
>>> -- Subject: Re: [oss-security] Re: CVE-2014-6271: remote code execution
>>> throu
>>>
>>> | It's not so much the known attacks -- redefining ls, unset, command,
>>> | typeset, declare, etc -- it's the future parser bugs that we don't yet
>>> | know about.
>>> |
>>> | A friend of mine said this could be a vulnerability gift that keeps on
>>> | giving.
>>>
>>> I think that at this point the conservative approach is best, so
>>> until the bash author figures what the best solution is, the feature
>>> is disabled by default for NetBSD. It is not wise to expose bash's
>>> parser to the internet and then debug it live while being attacked.
>>>
>>> christos
>>>
>>
>> FreeBSD has taken a similar approach. We have used Christos' patch and
>> disabled the feature by default.
>>
>> https://svnweb.freebsd.org/changeset/ports/369341
>
>
> FYI I have updated the FreeBSD bash to 27 and modified the
> --import-functions script to be implicit for interactive shells and to also
> give a warning when functions are ignored.
>
> https://svnweb.freebsd.org/ports/head/shells/bash/files/extrapatch-import-functions?revision=369467&view=co&pathrev=369467
>

HI Chet,

As you are aware, a sixth security issue has been discovered.

Due to the nature of the vulnerability, I believe that it's best to
break backward compatibility as done by FreeBSD and NetBSD until a
proper patch is developed. We are lucky to have security researchers
reporting their findings publicly. What about others that don't ?

I strongly believe that it's much safer to have it disabled, and have
a complete and comprehensive audit of the source code, and then
re-enable it.



> --
> Regards,
> Bryan Drewery



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ