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

"Majdi S. Abbas" <msa@latt.net> Wed, 05 June 2019 16:09 UTC

Return-Path: <msa@latt.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 E44191201CF for <ntp@ietfa.amsl.com>; Wed, 5 Jun 2019 09:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 eaLom4Sq51yD for <ntp@ietfa.amsl.com>; Wed, 5 Jun 2019 09:09:54 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD581201B5 for <ntp@ietf.org>; Wed, 5 Jun 2019 09:09:54 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 504) id CEEDD540DBB; Wed, 5 Jun 2019 12:09:52 -0400 (EDT)
Date: Wed, 05 Jun 2019 12:09:52 -0400
From: "Majdi S. Abbas" <msa@latt.net>
To: Ask Bjørn Hansen <ask@develooper.com>
Cc: Danny Mayer <mayer@pdmconsulting.net>, ntp@ietf.org
Message-ID: <20190605160952.GA20381@puck.nether.net>
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> <E3F91EE1-4EE8-4D3C-95E9-135D1CB1DF8A@develooper.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E3F91EE1-4EE8-4D3C-95E9-135D1CB1DF8A@develooper.com>
X-Message-Flag: Follow up
User-Agent: Mutt/1.11.4 (2019-03-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/kbobMxXI-Dndlxna77KPLyJ1INY>
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 16:09:56 -0000

On Wed, Jun 05, 2019 at 10:45:14AM +0800, Ask Bjørn Hansen wrote:
> This doesn’t seem right. There are much much less NTP servers in the 
> world than there are clients. Even an attacker wildly guessing will 
> have a limited scope of guessing (versus “every possible IP”).

	You're still going to have to guess the entire set of servers
the client is using, get them to accept small fragmented packets, with
an invalid of zero checksum...and do this for a minimum of 8 poll 
intervals in order to fool the discipline filters.  So you have to 
correctly predict the timing, and try to send additional fragments...
while the host is still processing the UDP frame.

	This does not appear to be anything but a very theoretical 
attack at this point -- does anyone have a proof of concept?

	Additionally: Can anyone think of a reason an implementation
should accept an additional fragment if the MF bit was not set in the
first packet?  (Particularly an overlapping fragment, when we are not
expecting any fragments at all?)

	And does that behavior exist in the wild?

	Thanks,

	--msa