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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ