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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ