Re: Question regarding CVE applicability of missing HttpOnly flag

["Vincent Danen" <vdanen () redhat com>]

On 06/26/2014, at 10:00 AM, Kurt Seifried wrote:

> On 26/06/14 05:45 AM, Jamie Strandboge wrote:
> > Based on this email and the one this is in response to, I find this
> > comment unclear. Is MITRE saying that:
> >
> > a) lack of implementing SELinux, AppArmor, virus scanner, firewall,
> > <insert hardening software here> does not justify a CVE because of
> > the complexity? b) lack of implementing SELinux, AppArmor, virus
> > scanner, firewall, <insert hardening software here> does not
> > justify a CVE and also cannot be considered an implementation error
> > because of the complexity? c) implementing SELinux, AppArmor, virus
> > scanner, firewall, and/or <insert hardening software here> is not
> > worth it because the added complexity intrinsically makes the
> > system less secure? d) something else?
> >
> > Thanks
>
> So one comment on this, replace the above with "DAC"
> (http://en.wikipedia.org/wiki/Discretionary_access_control) and I bet
> we'd hand it a CVE =).
>
> Security lines move, I would expect most modern system of any type
> (Windows, Linux, router, maybe not my bathroom scale that talks
> wifi... yet) to have some sort of firewall enabled by default and not
> simply leave everything exposed to the world. So in that case not
> having a fire enabled by default would definitely violate the
> principle of least surprise and maybe even qualify for a CVE.

Wait.  You're saying that not having a firewall enabled by default qualifies for a CVE?  I mean, firewalls are pretty 
common sense and should definitely be used/available/whatever but to say that an operating system or device doesn't 
have a firewall enabled by default should have a CVE assigned seems... excessive, doesn't it?

How is not having a firewall enabled by default a _vulnerability_?  If we look at it this way, it's a good thing CVEs 
go past 9999 per year because we need to change everything we used to call "hardening" to be a vulnerability, do we not?


-- 
Vincent Danen / Red Hat Product Security

Attachment: signature.asc
Description: OpenPGP digital signature