RE: fuzzing NTPsec with afl

2016-11-21 Thread Dan Poirot 
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-boun...@ntpsec.org] On Behalf Of Royce Williams
Sent: Monday, November 21, 2016 5:35 PM
To: Kurt Roeckx <k...@roeckx.be>
Cc: devel@ntpsec.org
Subject: Re: fuzzing NTPsec with afl

On Mon, Nov 21, 2016 at 2:18 PM, Kurt Roeckx <k...@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.

Royce
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: fuzzing NTPsec with afl

2016-11-21 Thread Royce Williams 
On Mon, Nov 21, 2016 at 2:18 PM, Kurt Roeckx  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.

Royce
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Re: fuzzing NTPsec with afl

2016-11-21 Thread Kurt Roeckx 
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.


Kurt

___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel