Go Fuzz Testing
blog.fuzzbuzz.io
Go Fuzz Testing
1–10 of 23 posts
Re: Go Fuzz Testing
#2Neat, Andrei. Good luck with this venture!
Re: Go Fuzz Testing
#3What’s the rationale behind bundling a fuzzing library in the language instead of as a separate library?
Re: Go Fuzz Testing
#4 go test fuzz v1
string("000000000000000000000000000000Ö00000000000000000000000000000")
rune('\u0083')
int(60)
Re: Go Fuzz Testing
#5What’s the rationale behind bundling a fuzzing library in the language instead of as a separate library?
Probably to encourage a standard fuzzing library for the language. Like the same way go fmt is part of the language.
Re: Go Fuzz Testing
#6go test fuzz v1 string("000000000000000000000000000000Ö00000000000000000000000000000") rune('\u0083') int(60) Interesting that the minimization engine wasn't able to shrink this further.
I noticed that as well - most fuzzers will have a maximum duration or number of iterations they're allowed to attempt when minimizing so as not to starve out actual inputs. It could be that the fuzzer hit that limit, or potentially prioritizes readable inputs over small inputs.
Re: Go Fuzz Testing
#7What’s the rationale behind bundling a fuzzing library in the language instead of as a separate library?
It does instrumented fuzzing. The older https://github.com/dvyukov/go-fuzz would rewrite your sources to inject the instrumentation and pass the rewritten sources to the compiler, but it didn't really work with Go modules. This is something that probably makes sense to integrate with the compiler toolchain, same as `go test`'s coverage testing.
Re: Go Fuzz Testing
#8Curious if fuzzing is a common thing in network programming, does fuzzing plays nicely with binary inputs?
Re: Go Fuzz Testing
#9What’s the rationale behind bundling a fuzzing library in the language instead of as a separate library?
To do guided fuzzing (graybox, like afl or libfuzzer) you need to instrument the binary. To instrument the binary, you need to be part of the building process.
Since Go has a bespoke compilation toolchains and AFAIK doesn’t have compiler plugins, external fuzzing tools had to either fork the toolchain or perform extensive pre and post processing (couldn’t tell you what go-fuzz did but many article about go-fuzz note that the building process can take a while).
As such, building fuzzing into the standard toolchain and maintaining it as part of the project makes a lot of sense. It also gives fuzzing a much higher level of visibility (because sadly there will always be a population for whom an external / third-party tool will be suspicious).
Re: Go Fuzz Testing
#10Curious if fuzzing is a common thing in network programming, does fuzzing plays nicely with binary inputs?
Along side file parsers it’s a pretty major fuzzing target, as it tends to be exposed to malicious inputs.
Fuzzing works primarily on binary data, “structured” fuzzing is somewhat rarer.