[ntp:security] [Bug 1331] DoS with mode 7 packets (CVE-2009-3563)
mayer at ntp.org
Thu Oct 8 01:27:40 UTC 2009
Dave Hart wrote:
> Your update last night occurred about the same time I sent the email
> to which you're replying, so it's hardly surprising I had not reviewed
> your third attempt at that point.
Actually it didn't. I just committed the change at that time. I had
changed it hours before.
Having looked at it, the only
> difference in the last day is you moved the ISMORE test from the "log
> and respond" bin to the "don't log and don't respond" bin. The only
> two remaining in the "log and respond" bin are the version checks,
> which you say are "legitimate". I don't believe we need to make a
> value judgement about what's white hat vs. what's black hat here. The
> version checks you say are to check for ntpdc compatibility are in no
> way such. They are generic NTP header version checks the same as
> elsewhere in ntpd, and they include all versions of ntpdc in one lump,
> as the test is for version less than 1 or greater than 4.
And for a NTP V5 it would fail as would ntpdc v4 with xntp V3. The mode7
packets are private and are not guaranteed not to change between major
versions and that's why the test is there. This is an interoperability
issue not an attack or security issue.
> In your latest revision, you are still replying to malformed packets
> (with incredible versions). Granted, as long as you're not responding
> to responses, the primary problem is resolved. But why reorder tests
> and change the meaning of log entries? Why be different from mode 6
> and mainline handling of similar packets by replying to packets with
> incredible versions?
The test order has nothing to do with it and is private to each version
of the nptd daemon. The failure number is only logged on the server and
can never be seen on any client so it really does not matter.
I'm ignoring mode 6 packets. That's not the issue here. Interoperability is.
> If it were not for the need to keep patches simple and focused, I
> would say all the INFO_ERR_FMT responses should be eliminated from
> process_private(), dropping each without response.
Which means that you are ignoring legitimate errors thereby throwing out
legitimate error responses.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the security