Re: Patch to Vulnerability Linkage

[Stephane Chazelas]

2014-10-03 08:56:41 -0400, Chet Ramey:
> On 10/3/14, 4:55 AM, Nathan McGarvey wrote:
> >     Is there any linkage between bash patches and known CVE (or any other
> > database) IDs? (Source-code comment, bug-tracker, etc.)
> >     I understand that there is not a one<->one relationship, but for the
> > bug-fixes that do pertain to one or more vulnerability entry, it may be
> > beneficial to outright state "this patch is designed to fix X".
> 
> Yes, here's a list.  I lose track of the CVE IDs myself.
> 
> bash43-025    CVE-2014-6271                           9/24/2014
> bash43-026    CVE-2014-7169                           9/26/2014
> bash43-027    exported function namespace change      9/27/2014
> bash43-028    CVE-2014-7186/CVE-2014-7187             10/1/2014
> bash43-029    CVE-2014-6277                           10/2/2014
> 
> There is still one more, for CVE-2014-6278, that I have to do some minor
> work on before rolling out patches.
[...]

To clarify, only bash43-027 matters (stop bash parser from being
exposed to untrusted input (any environment variable)
(CVE-2014-ShouldHaveBeen)).

Once that's fixed, the other bugs become either

- non-bugs: CVE-2014-6271 (interpret code after the function
  definition) is not a bug in that it doesn't affect the
  behavior of function exporting and could even be seen as a
  feature (a debugging tool which makes it more convenient to
  have bash run code on startup rather than having to rely on
  BASH_ENV and also works when bash is invoked as sh)

- or very very minor ones (the type of bug you would not
  bother fixing unless you're a perfectionist) as they would
  never be hit, and not security vulnerabilities in any case.

For instance CVE-2014-6278 is the most severe bug (almost as bad
as CVE-2014-6271) when the door is open (when the parser is
exposed), and becomes the most insignificant one when it's
closed (when bash43-027 is applied).

-- 
Stephane