[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550F920F.10007@redhat.com>
Date: Sun, 22 Mar 2015 22:09:51 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com
Subject: Re: CVE for Kali Linux
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@...re.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
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
