[ntp:security] [Bug 1331] DoS with mode 7 packets (CVE-2009-3563)

Dave Hart davehart at gmail.com
Wed Oct 7 12:52:01 UTC 2009


On Wed, Oct 7, 2009 at 12:12 PM, Danny Mayer <mayer at ntp.org> wrote:
> Dave Hart wrote:
>> Making a judgement call about which ones to drop and never log vs
>> which to reply to and log without rate limits is subject to mistake,
>> such as your initial mistake where your patch responded with an error
>> to error responses.  It is simpler and safer to drop all malformed
>> mode 7 packets and not try to be clever about which ones it's safe to
>> respond to.  There is no value in the response that I see.
>
> Then you haven't been reading my code which I updated last night nor do
> you understand what all of the tests are. Not all of the tests are bad
> packets. Two of the tests are legitimate to check the version for
> compatibility between ntpdc and the version of ntpd receiving the
> packets. There is not expected to be interoperatibility between versions
> and those get rejected.

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.  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.

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?

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.

Cheers,
Dave Hart


More information about the security mailing list