Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Mar 2015 21:29:24 -0400 (EDT)
Subject: Re: CVE for Kali Linux

Hash: SHA1

We've read the "CVE for Kali Linux" messages and haven't yet found a
real case that can have a CVE assignment. We also believe it's
infeasible to make a comprehensive statement about every hypothetical
case and whether a CVE assignment would occur.

A few general comments:

1. says:

  it's only recently (e.g. the last 6 months or so?)
  that we've moved the security bar to:

  downloads of updates via HTTP with no other protection == CVE

We didn't understand this. The last paragraph of suggests that
"==" isn't the case. Some issues of this type will receive CVE IDs but
others will not. For example, is about an
unusual case where people interested in file integrity had the option
of paying $10 for https.

2. For Kali Linux, users are apparently supposed to start at to obtain their initial set of
software, including the package signing key. Packages apparently are
later updated using with automatic signature
verification before any installed software is replaced. The site doesn't exist and therefore there isn't
an opportunity to "fix" anything with a one-character change. Even if
there were widespread agreement that is
required to meet their users' reasonable expectations, there still
would not be a CVE because the issue is site-specific (a missing
security property on a vendor-controlled server). Somewhat similarly,
there could not be a CVE for the case.
Finally, if there is a need for extra security properties on (e.g., HSTS if it doesn't yet have it), there
would again be no associated CVE or CVEs.

3. We're typically uninterested in assigning CVE IDs based on a
likelihood that users don't follow instructions. For example, suppose
a community Linux distribution publishes complete open-source software
for generating and operating a mirror site. These mirror sites offer
an ISO with only an http URL, but with clear instructions to verify
the ISO checksum against a sufficiently reliable checksum listing. One
might argue that an https .iso URL would be better because many users
actually won't ever visit that checksum listing. However, a
counterargument is that the community Linux distribution might be
trying to emphasize the concept that endpoint security on the mirror
sites is unknown and unsupported. A person doing a download may not
realize that the mirror sites are completely untrusted and some might
be controlled by attackers. There might be persons who would have
verified the checksum after an http download, but wouldn't bother to
verify the checksum after an https download. In other words, depending
on the psychological model of the users, http might be better if https
provided a false sense of security.

4. The Debian case is perhaps interesting: explicitly uses the http scheme in a
link to a .iso file, and perhaps
has a missing step "3a. Verify (somehow?) the file integrity of the
installer software." If this actually is a security problem, it is
site-specific and can't have a CVE ID. At the time that the
documentation is used, the documentation isn't a file that has been
distributed to the customer's system.

5. asks 'if a
vendor explicitly tells people not to check them ("download over http
and check sums published over http") is that CVE worthy?' The general
answer is that there can be a CVE ID for a missing
integrity-verification step, either a step that is missing in
distributed documentation or a step that is missing in distributed
code. As an example, if an integrity-verification step goes to an http
checksum page but was intended to go to an https checksum page, and
the root cause is that the author's keyboard had a bad 's' key, then
that's a vulnerability and can have a CVE ID. If there's a new product
and the root cause of skipping an integrity-verification step is that
checksum generation is still being debugged and won't be live until
the next release, then typically that would not have a CVE ID.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

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.