oss-security - Re: Re: Question regarding CVE applicability of missing HttpOnly flag

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <53AC07D1.3070301@canonical.com>
Date: Thu, 26 Jun 2014 06:45:21 -0500
From: Jamie Strandboge <jamie@...onical.com>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com
Subject: Re: Re: Question regarding CVE applicability of missing
 HttpOnly flag

On 06/25/2014 06:07 PM, cve-assign@...re.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/


Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.