Re: Question regarding CVE applicability of missing HttpOnly flag

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

On 06/26/2014, at 9:59 AM, cve-assign () mitre org wrote:

> It is closest to b. It would be very rare to assign a CVE for a design
> choice by a system integrator. Suppose a new operating-system
> distribution ships tomorrow without a virus scanner. Often the best
> model for this would be a set of tasks that hasn't happened. For
> example, the vendor hasn't yet investigated customer requirements for
> what a virus scanner should do. The vendor hasn't performed the
> release-engineering work of packaging a virus scanner. There are other
> tasks as well. We don't think that CVE consumers are looking for us to
> tag cases where a product lacks complete subsystem parity with all
> possible competitors.

I'm not sure that I understand or agree with this.  The above sounds to me like not having a virus scanner in an OS is 
a security flaw, but the only reason it's not being described as such is a technicality.

Virus scanners are useful proactive security, but I don't think that means the _lack_ of one exposes a vulnerability.  
The vulnerability (which should be what gets a CVE) is exposed regardless of the presence of a virus scanner -- all the 
scanner does is make detection easier and possibly prevent something from being executed that may otherwise be 
unwittingly executed (or may not, the vendor cannot make that determination).

I suppose maybe there is a CWE for not having a virus scanner, which makes sense as that could be considered an overall 
system weakness.  So I guess the next question is whether or not there is a 1:1 mapping for CWE and CVE (i.e. if 
something has a weakness (software, OS, configuration) does that automatically make it an actual vulnerability).

I'm also really confused on how any of these tasks have any bearing on what constitutes a vulnerability because they 
seem irrelevant as far as determining whether or not an actual flaw exists:

- lack of a proactive security mechanism (virus scanner, etc.)
- customer requirements (I fail to see how this impacts whether or not something is a flaw)
- release engineering work (or, possibly, "how hard is this to fix?")
- feature parity with other competitors

All of these sound like marketing issues, not factors to determine whether or not a flaw is a flaw.

-- 
Vincent Danen / Red Hat Product Security

Attachment: signature.asc
Description: OpenPGP digital signature