[ntp:questions] CVE-2013-5211 and xntpd
dennis.c.ferguson at gmail.com
Thu Feb 6 22:05:42 UTC 2014
On 6 Feb, 2014, at 07:39 , Danny Mayer <mayer at pdmconsulting.net> wrote:
> On 2/6/2014 9:26 AM, Brian Utterback wrote:
>> I recently received a question from a customer about CVE-201305211, the
>> monlist amplification attack. Specifically they asked if the attack
>> affected xntpd. They had another vendor that said no, that the attack
>> only affects ntpd. This surprised me since as far as I know the monlist
>> mechanism is the same in xntpd. I thought the vendor was merely
>> incorrect. However, I then read the CERT and NIST versions of the CVE
>> and there is no mention of xntpd. Indeed, a literal reading of the CVE
>> does indeed imply that xntpd is not vulnerable.
>> I don't think I am wrong about xntpd being vulnerable. If I am, please
>> correct me. But if I am not, we should probably see about getting the
>> CVE amended.
> If this is about NTP v3 then that version hasn't been supported in
> something like 15 years. I believe that it is very likely vulnerable but
> noone is going to go into the code to look assuming that they can find
> the source for something like that. I believe it was Dennis who wrote
> the mode 7 code and tools, so NTP v2 is likely vulnerable as well but
> that's not in the CERT either.
xntpd claimed to be NTP v3 from its inception, and had both xntpdc and ntpq
by the time anyone other than me saw it. It was implemented from a
moving-target draft of the NTP version 3 standard that was available as
early as 1988 (i.e. before the NTP version 2 RFC was published; that was
done late since there was resistance to the postscript format). Fuzzballs
also claimed to be version 3 by then too, though there was an existing Unix
daemon called "ntpd" implementing NTP v2 only, this being the reason that
xntpd got an 'x'. The mode 7 protocol was implemented as a debugging tool
during development, the mode 6 protocol was implemented after that got added
to the version 3 draft and supported by the fuzzball servers, so you could
ask fuzzballs about their peers too.
That said, when I stopped work on xntpd there was no "monlist" query since
there was no monitor list. If you wanted to know who your clients were it
used a much heavier duty (but cheaper to implement) method, a knob telling
it to keep peer state for all peers rather than just the configured ones.
When I left it, I don't believe there were any queries in either protocol
which would result in more than one response packet per query packet, and
I had tried to keep responses under 520 bytes of payload (or whatever
the number was which guaranteed no fragmentation then) for mode 7 since I
lived at the end of a very overloaded Internet connection and it worked
better with single packet request/responses. I had less control over mode
If there's something called xntpd which supports monlist it must have been
added after me, but before the name of the program was changed to ntpd. I
don't know when that was.
More information about the questions