
Fuzzing a DNS parser written in Go - jgrahamc
https://blog.cloudflare.com/dns-parser-meet-go-fuzzer/
======
artursapek
CloudFlare has a constant stream of quality articles about Go, I've really
been enjoying them.

~~~
brobinson
They are probably pushing more traffic through Go than any other group on the
planet. It's nice of them to share what they come across, and it's also good
PR for them. Hell, even I want to work for them now.

~~~
eastdakota
We're hiring in San Francisco, London, and Singapore:

[https://www.cloudflare.com/join-our-team](https://www.cloudflare.com/join-
our-team)

~~~
outworlder
On that note:

Hypothetically speaking, what would take for a wanna-be candidate that knows
Go but doesn't have relevant work experience on CloudFlare's area of expertise
to get up to speed?

~~~
jgrahamc
Apply. We have a very diverse team of backgrounds. Getting up to speed isn't a
problem.

~~~
nindalf
Hi. Could I speak to you about this?

------
dkubb
I'd also recommend introducing mutation testing in addition to fuzz testing.

There is some overlap between the two techniques, but they approach the
problem from completely different directions. Fuzz testing randomly generates
inputs and uses that to find bugs where the input is improperly handled.
Mutation testing randomly changes the code to make sure the tests themselves
cover all the code that is written.

A good approach is to use mutation testing to make sure the existing code is
fully covered by the tests. Then use fuzz testing to identify new failing test
cases that need to be written. Once the implementation handles the new test
cases, mutation test _that_ code to make sure there aren't any untested code
paths.

I used this same approach on an Relational Algebra + SQL generator lib I wrote
a while ago and the result was something that was very stable -- the only bugs
were due to flaws in my own understanding of the specification, not bugs in
the implementation.

~~~
eru
I'd be interested to read a more detailed write up of the process.

------
amichal
It's amusing that one of the bugs they found and fixed was a buffer reuse bug
-- similar to what caused heartbleed -- will help in my 'memory safe languages
are not magic bullets' rebuttals.

~~~
hueving
So is your rebuttal that since there are some reuse bugs, reading out of
bounds is ok?

~~~
tedunangst
How does one go from "memory safe languages are not magic bullets" to "reading
out of bounds is ok"? That's not a type safe argument.

~~~
pcwalton
I think the point is just that "memory safety is a magic bullet" is a straw
man version of the actual argument, "memory safety improves security
significantly over not having it".

~~~
wtracy
I've seem people believe that memory leaks can't happen in programs written in
garbage-collected programs. So, yeah, the belief that garbage collection
and/or bounds checking is a magic bullet really needs to be addressed.

~~~
eru
They are damn good bullets. Just not silver bullets.

Restricting mutability would help somewhat. (Another bullet.)

------
haberman
Never listen to anyone who tells you that parsers are easy.

Parsers that work on simple input are easy. Parsers that get all the edge
cases and diabolical input right are stupidly difficult.

~~~
tomjakubowski
> Parsers that work on simple input are easy. Parsers that get all the edge
> cases and diabolical input right are stupidly difficult.

Not to mention parsers which work on a vague and totally unspecified grammar -
like "real world" HTTP and HTML parsers, which have to account for misbehaving
clients and servers or malformed web pages (is this what you meant by
'diabolical input'?).

~~~
haberman
> is this what you meant by 'diabolical input'

Not exactly what I meant, but that's a good point too!

By diabolical input, I mean things specifically designed to stress the parser,
like ("{" * 100000) in JSON.

------
_paulc
For dnslib [1] I use a much simpler fuzzer as part of the test suite [2] -
this is nothing like as sophisticated as afl-fuzz or go-fuzz in terms of
understanding and exercising code paths (just takes a DNS record and randomly
mutates it - though still found a number of bugs).

Does anyone know if there is anything similar to afl-fuzz/go-fuzz for python?

[1] [https://bitbucket.org/paulc/dnslib/](https://bitbucket.org/paulc/dnslib/)
[2]
[https://bitbucket.org/paulc/dnslib/src/22cff0cd3e13098c00107...](https://bitbucket.org/paulc/dnslib/src/22cff0cd3e13098c001076cbb5cdcfa0a08d9c3f/fuzz.py?at=default)

~~~
foote
[https://bitbucket.org/jwilk/python-afl](https://bitbucket.org/jwilk/python-
afl)

------
thomseddon
There really aren't many freely available DNS servers that have seen serious
production usage - I'm really excited to see RRDNS open sourced as previously
hinted at, does anyone know if there is a timeline for this?

------
jrv
A Prometheus contributor also fuzzed our query language parser using go-fuzz
and amongst other things discovered a really interesting Unicode-related
parsing bug:

[https://twitter.com/PrometheusIO/status/626187068356624384](https://twitter.com/PrometheusIO/status/626187068356624384)

------
Arnavion
Is there anything available to fuzz parsers written in JavaScript? (I found
tunz/afl-fuzz-js and some others but they seem to be for fuzzing parsers _of_
JavaScript.)

