fuzzing NTPsec with afl

Dan Poirot dtpoirot at gmail.com
Tue Nov 22 02:55:04 UTC 2016

I have been using Synopsys Defensics with over 250,000 discrete
'generational' NTP Server and NTPv2, NTPv3, and NTPv4 Server Control tests
on NTPsec for some time now. 

(NTPsec doesn't answer back as v0 or v1)

Hacking the Network Time Protocol to take the 'network' out is clever! 

UDP, IP and Ethernet aren't changing in this domain. Fuzzing the Linux
TCP/IP stack is a waste of time.

- Dan Poirot, CISSP

-----Original Message-----
From: devel [mailto:devel-bounces at ntpsec.org] On Behalf Of Royce Williams
Sent: Monday, November 21, 2016 5:35 PM
To: Kurt Roeckx <kurt at roeckx.be>
Cc: devel at ntpsec.org
Subject: Re: fuzzing NTPsec with afl

On Mon, Nov 21, 2016 at 2:18 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> On Mon, Nov 21, 2016 at 02:11:12PM -0900, Royce Williams wrote:
>> If those minimal changes are turned into a compile-time option, this 
>> would enable adding fuzzing to the rolling test suite, perhaps using 
>> some of Susan's resources.
> Google also provides resources via oss-fuzz. If you can read from 
> stdin, it should also be easy to fuzz with other fuzzers like 
> libfuzzer.

Indeed. And my understanding is that stdin is often much faster than
equivalent network-level testing, which translates to a lot more coverage
per wall-clock hour (which is important for this kind of fuzzing).

Ideally, we could enable some kind of basic coverage for both methods
-- stdin and network-based. This would more closely model the actual threat
landscape and attackers' capabilities.

But between the two, stdin would be the best bang for the buck.

devel mailing list
devel at ntpsec.org

More information about the devel mailing list