[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150323012924.0F2336C0018@smtpvmsrv1.mitre.org>
Date: Sun, 22 Mar 2015 21:29:24 -0400 (EDT)
From: cve-assign@...re.org
To: kseifried@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
-----BEGIN PGP SIGNED MESSAGE-----
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. http://openwall.com/lists/oss-security/2015/03/22/20 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
http://openwall.com/lists/oss-security/2015/03/03/10 suggests that
"==" isn't the case. Some issues of this type will receive CVE IDs but
others will not. For example,
http://openwall.com/lists/oss-security/2015/03/03/10 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
https://www.kali.org/downloads/ to obtain their initial set of
software, including the package signing key. Packages apparently are
later updated using http://security.kali.org with automatic signature
verification before any installed software is replaced. The
https://security.kali.org 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 https://security.kali.org 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 http://cygwin.com/setup-x86.exe case.
Finally, if there is a need for extra security properties on
https://www.kali.org (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:
https://www.debian.org/distrib/ explicitly uses the http scheme in a
link to a .iso file, and
https://www.debian.org/releases/stable/amd64/ch03s01.html.en 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. http://openwall.com/lists/oss-security/2015/03/22/22 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVD2t7AAoJEKllVAevmvms90QH/09Whael260L0jzRG4psYDOW
bpk7Y6bLR20/ubWbKBZnkqlbHI/QBLz5IWVYYJk5T8gpFL1XdpgU9wxDvefmVXKE
qFdE4P0M7kOv0bcROnawrAstHsU0oti5iU3k/KVrMKYuSYSPJ9S6+N2Sv10W7wWr
m9zXucC1ICLqCaOLcCwWZsmJPz+09ysANVe83VNhs2S3BTv1rBoQZNWf65UcjZ10
TBEmhbzzwwyCp4Obum3+GWe+3itYWPj61kKCOttPq05aOWo5XriHKVPXWGolUzvm
agKdLy/zOIio/8LmIrNyhuLzKnz5TS/9bs8Jd9qrWXccpRTqeo4tB9nJ5uTNPGk=
=c1gK
-----END PGP SIGNATURE-----
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.
