Re: Re: Question regarding CVE applicability of missing HttpOnly flag

[Jamie Strandboge <jamie () canonical com>]

On 06/25/2014 06:07 PM, cve-assign () mitre org wrote:
> There admittedly isn't a precise distinction between "opportunity for
> security improvement" (a CVE ID cannot be assigned) and "exposure" (a
> CVE ID can be assigned in some cases).
>
> In web applications that function correctly with the HTTPOnly flag for
> a cookie, absence of this flag might be categorized as a CWE-668
> ("Exposure of Resource to Wrong Sphere") issue. In general, factors
> that can be considered include:
>
>   -- are there compatibility downsides to setting the flag? (An
>      example of a downside might be: a popular but noncompliant
>      browser completely ignores the cookie if the flag is set.)
>
>      [ Obviously each CVE assignment is on a per-product basis, and
>        there wouldn't be a CVE about HTTPOnly if a product's design
>        relies on script access to a cookie. ]
>
>   -- does the flag interfere with plausible use cases? (An example of
>      a use case might be: script code that doesn't need to know the
>      value of a cookie, but was designed to read the cookie anyway to
>      assess whether an attack involving long cookie values is
>      occurring.)
>
>   -- are there vendors who recommend against the flag?
>
>   -- compared to the development cost in arranging for the flag to be
>      set, is it possible that the real-life benefit is too small?
>
>   -- are there other known or potential costs to setting the flag?
>      (There might not be a good example here, e.g., there probably
>      aren't bandwidth considerations where 9 or 10 more bytes is a
>      deal breaker.)
>
> If the answer to all of these questions is no, then it starts becoming
> reasonable to argue that absence of the flag is an implementation
> error.
>
> > like running SELinux (or AppArmor), running a virus scanner, and
> > having a firewall
>
> All of those seem to, in practice, have a relatively much greater
> chance of introducing new vulnerabilities because of the required
> implementation complexity.

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

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature