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
