[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5FE3BA37-EA93-41FA-817E-36863E27705C@redhat.com>
Date: Fri, 17 Jan 2014 17:47:26 -0700
From: "Vincent Danen" <vdanen@...hat.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-0021: chrony traffic amplification in cmdmon protocol
On 01/17/2014, at 17:39 PM, cve-assign@...re.org wrote:
>> With the news about the traffic amplification issue in ntpd, one of
>> our developers looked at chronyd
>
> At cve-assign@...re.org, we've received a number of reports that have
> protocol descriptions, and ask for CVE assignments for amplification
> attacks. We've declined making assignments for those. One of the
> criteria we're currently using is:
>
> - cases in which a vendor of a UDP protocol implementation announces
> that they made a security-relevant mistake by having configuration
> or code elements that allow amplification attacks, and publishes
> a fix for this mistake
>
> One of the other CVE Numbering Authorities was also receiving similar
> reports. We coordinated with them and learned that they were looking
> at CVE eligibility in much the same way.
>
> The "in which a vendor of a UDP protocol implementation" above was
> what we had for the CVE-2013-5211 ntpd issue (with some definition of
> "announces"). We don't know the ultimate outcome of how amplification
> attacks will interact with the scope of CVE, but we did want to point
> out that this CVE-2014-0021 assignment seemed inconsistent with what
> we've been doing.
Is this not a same/similar case? chronyd, much like ntpd, has some commands that allow for amplification, just like ntpd does.
I'm not going to argue (I didn't assign it, I'm just reporting that it was assigned), but it struck me as being essentially the same type of flaw. So if ntpd received a CVE for essentially the same thing, I can see why this one was assigned as well.
I'm not sure which part is inconsistent here. Granted, chrony does not yet have a published fix, but my understanding is that is in the works. In other words, there will be a fix of some sort (to at least reduce the amplification quite substantially). Is that the part that seemed inconsistent? The lack of a published fix?
--
Vincent Danen / Red Hat Security Response Team
Download attachment "signature.asc" of type "application/pgp-signature" (711 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.
