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

Danny Mayer <mayer@pdmconsulting.net> Wed, 05 June 2019 18:35 UTC

Return-Path: <mayer@pdmconsulting.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D869E120222 for <ntp@ietfa.amsl.com>; Wed, 5 Jun 2019 11:35:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz2bDlJbT_3l for <ntp@ietfa.amsl.com>; Wed, 5 Jun 2019 11:35:51 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A861200FD for <ntp@ietf.org>; Wed, 5 Jun 2019 11:35:44 -0700 (PDT)
Received: from l34097ous.rpega.com (unknown [198.22.153.34]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 45JyCg6NVKzL7N; Wed, 5 Jun 2019 18:35:43 +0000 (UTC)
To: Watson Ladd <watsonbladd@gmail.com>
Cc: NTP WG <ntp@ietf.org>
References: <CAN2QdAGS20q=7+r+qMFEBBu4gNmSDR9-vYDbvgC=ZnqWLEU-6w@mail.gmail.com> <739c2eaa-05f1-0b30-4b64-fc5d3f91ce5b@pdmconsulting.net> <a3a545cf-d83d-a2c7-ad6c-3e349de78615@si6networks.com> <9f75e400-cf2f-053f-ed06-f4d6df415eaf@pdmconsulting.net> <CACsn0ck8w=sZ19QJYuSL1Bi2XdDjPW6ruPAWYtMuDxWNRXZ1mA@mail.gmail.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <8e3f7027-ea04-3e33-274f-0c65f499af7d@pdmconsulting.net>
Date: Wed, 05 Jun 2019 14:35:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CACsn0ck8w=sZ19QJYuSL1Bi2XdDjPW6ruPAWYtMuDxWNRXZ1mA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/3oMeSOzYYQkQK0pZX4E5s9mP-BE>
Subject: Re: [Ntp] Details of the fragmentation attacks against NTP and port randomization
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2019 18:35:53 -0000

On 6/5/19 10:40 AM, Watson Ladd wrote:
> On Tue, Jun 4, 2019 at 7:41 PM Danny Mayer <mayer@pdmconsulting.net> wrote:
>> 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.
> >From the paper: "Our measurements(Section VI-G) confirm that there are
> ten of thousands of NTP servers in the wild that do this." Clearly
> tens of thousands of servers are fragmenting below minimum MTU in
> response to PMTUD messages.

Yes and those O/S's clearly need to be fixed. Fix the underlying problem
and it will be fixed for more than just NTP.

>
>> 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!
> I find this level of opposition (it doesn't close all the barriers so
> why bother) remarkable. Why not randomize the ports? Doing so would
> also simplify dos protection: src=123 is a problem. I agree we should
> all move to NTS.

The opposition is due to the fact that randomizing the ports doesn't
solve the underlying security issue. If I'm an attacker off-path and can
get to the target system, I can just run nmap and find out all of the
open ports leaving just a few ports to check. Randomizing ports by
itself solves nothing here.

What is really needed is a draft to improve the security of unprotected
NTP servers. NTS helps but will take a long time before many servers are
using it so getting NTS rolled out should be on everyone's list.

Danny