oss-sec mailing list archives
Re: CVE for Kali Linux
From: Kurt Seifried <kseifried () redhat com>
Date: Sun, 22 Mar 2015 22:09:51 -0600
My understanding was for software that downloads updates or other executable components over HTTP instead of HTTPS, AND there is no other protection (e.g. signed RPMs), so in effect there is nothing to protect it, then it gets a CVE since the user is essentially up the creek at that point. On 03/22/2015 07:29 PM, cve-assign () mitre org wrote:
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.
-- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Attachment:
signature.asc
Description: OpenPGP digital signature
Current thread:
- Re: CVE for Kali Linux, (continued)
- Re: CVE for Kali Linux David A. Wheeler (Mar 22)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 23)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 23)
- Re: CVE for Kali Linux Marcus Meissner (Mar 24)
- Re: CVE for Kali Linux Alexander Cherepanov (Mar 24)
- Re: CVE for Kali Linux Kurt Seifried (Mar 22)
- Re: CVE for Kali Linux Solar Designer (Mar 22)