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