Re: CVE-2014-0021: chrony traffic amplification in cmdmon protocol

["Vincent Danen" <vdanen () redhat com>]

On 01/17/2014, at 17:39 PM, cve-assign () mitre org wrote:

> > With the news about the traffic amplification issue in ntpd, one of
> > our developers looked at chronyd
>
> At cve-assign () mitre 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

Attachment: signature.asc
Description: OpenPGP digital signature