On 6 Feb, 2014, at 07:39 , Danny Mayer <[email protected]> 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 6, though. 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. Dennis Ferguson _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
