Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization

[Danny Mayer <[e-mail]>]

On 6/4/19 2:39 AM, Fernando Gont wrote:
> On 4/6/19 06:09, Danny Mayer wrote:
>> On 6/3/19 2:24 PM, Watson Ladd wrote:
>>
>>> Dear all,
>>>
>>> The debate over client port randomization is missing an important
>>> fact: off-path attacks against NTP are not prevented by the origin
>>> timestamp due to the OS handling of fragmentation. In
>>> http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf we see that sending
>>> a properly crafted IP fragment can selectively overwrite NTP packets,
>>> thus allowing an attacker to modify received data without overwriting
>>> the origin timestamp. I would recommend we adopt port randomization
>>> to handle this problem.
>>>
>>> Sincerely,
>>> Watson Ladd
>> Actually if you read Section VI you will see that the last sentence of
>> that section states that they do not consider it to be a sufficient defense.
> Wasn't Your argument that the timestamp was enough to mitigate off-path
> attacks?
>
Yes and no. The draft you wrote requires using random ports to avoid
off-path attacks. The paper demonstrates that for at least some O/S's an
off-path fragmentation attack succeeds regardless of the port number.
This is at a layer below NTP. So randomizing the ports doesn't matter
for this attack according to the paper. The proper way to deal with this
fragmentation attack is to fix the underlying O/S behavior as has
already been done for most of them. The NTP basic payload is only 48
bytes so there is no reason to allow fragmentation in the first place.

If you can't attack that way then your off-path attacker cannot guess
the origin timestamp which is a 64-bit quantity. Furthermore the
attacker doesn't know the server being used by the NTP client so the IP
address of that server will be invalid as well. The client should have
enough information to ignore the packet.

So RFC6056 doesn't really apply as a mandate. You can certainly ask to
update draft-ietf-ntp-bcp to recommend randomizing the port for outgoing
queries. In any case RFC6056 is about randomizing ports and is not
really a security document. If it were then it would have made a very
basic recommendation concerning the port: if you have received your
response and it is valid then close the port immediately and the next
time you want to make a new request open a new random port to perform
the request. That way the off-path attacker will have no way of knowing
what the new port number will be.

In the case of NTP you don't want to trust a single server, The draft
NTP BCP recommends at least 3 different servers and preferably 4 to
allow for the loss of one server. See section 3.2. If you are really
concerned about security you should arrange with your server providers
to include either a MAC at the end of the packet or use the new NTS
security mechanism to validate and secure the packets returned. If you
are concerned about attacks you should be employing firewalls anyway.
Lastly you can get yourself a GPS unit and use that to get your clock
information. For the really paranoid, get an atomic clock!

Danny