andrei

just link to the real thing :) [0]

[0]: https://twitter.com/nealagarwal/status/1747284257582506102

facepalm I read that paragraph, but my brain skipped that sentence for some reason. Thanks for clarifying

How is this different than just turning your TV off? I feel like I'm missing something

Somewhat relevant: https://tonsky.me/blog/disenchantment/

As of go 1.18, fuzzing is built into the toolchain itself, and is what we're using in this post.

We go over the basics here [0], if you'd like to start at the beginning

[0]: https://blog.fuzzbuzz.io/go-fuzzing-basics/

It's much more common than you may think - especially at larger organizations where engineers go "off-script" frequently.

That being said, we wanted to highlight an example of how fuzzing can be applied to a typical (albeit, toy) API to find logic bugs, and figured SQL Injection would be something that resonated with most (all?) developers.

A lot of folks we talk to think fuzzing is only useful for finding memory leaks in C++ programs, so we wanted to show how adding a single fuzz test to your API can find SQL injection and other logic bugs.

Would love to hear others' experience with Go fuzzing now that it's been out for a few months.

> 2. What measures is Oven taking to proactively detect and mitigate vulnerabilities? (e.g.: fuzzing, audits, bug bounties)

We're huge fans of bun at Fuzzbuzz (waiting for it to get a bit more production-ready). If Jarred's interested, we'd be happy to donate some compute to support fuzzing Bun.

<hn username> @ fuzzbuzz.io

I've heard this talked about before, and I believe there's a phrase for it, but I don't remember. Do you happen to know?

Good catch :) fixed!

It does! Fuzzing actually started off as a tool built by security researchers to find vulnerabilities in parsers, and other complex codebases, usually written in C/C++ (looking for memory bugs). So anything that deals with untrusted binary data is a prime candidate for fuzz testing.

Go’s fuzzing framework supports `[]byte` arguments as well as all of the standard Go primitives, so you should be able to test netcode this way.

If you're looking for a C/C++ solution, my recommendation is libfuzzer [0]. We've also built our own C/C++ fuzzing engine at Fuzzbuzz [1].

[0] https://llvm.org/docs/LibFuzzer.html

[1] https://docs.fuzzbuzz.io/docs/getting-started-in-c-or-c++

This was a big reason for why our entire eng team moved to linux

I think this downplays things quite a bit. I grew up as a middle class immigrant in Canada. My parents have office jobs, but basically 0 connections (certainly not the ones you're implying you need to raise).

In university (which I paid for myself through internships + loans), my cofounder and I just started coding on an idea, which got us into YC, which helped us get in front of a bunch of VCs, which allowed us to raise $3m in seed funding. No connections, just lots of googling and talking/pitching to anyone that would pay attention to us.

It could've been the 5% luck you're talking about, but certainly don't think that coming from a well-connected family is the only way to fundraise in 2021.

Part 1 here: https://sthbrx.github.io/blog/2021/03/04/fuzzing-grub-part-1...

Should add the date to the title: (2017)

No reason to be ashamed, it's still a fairly niche concept. We're huge fans of it though. We'll definitely be writing an in-depth post about it in the coming weeks/months.

>Sure, but one thing I don’t understand is why fuzzing is not used more often for testing basically any pure function [...]

Agreed 100%, and is actually what we encourage people to do. Since this is an intro article though, we wanted to keep things simple, and everyone understands the danger in accepting inputs over a trust boundary. Your suggested method is what the fuzzing community calls differential fuzzing [0]. It’s been incredibly effective at finding bugs in crypto libraries [1], and is currently being used to fuzz different Ethereum node implementations [2]. There are other ways you can fuzz functions, and we sort of hint at this in the post when we say:

“If you can define a property that must hold true for any given input (also called an invariant), then the fuzzer will look for inputs that break your invariant”.

Usually this translates into writing assertions the same way you might when you’re writing property-based tests [3]. In fact, I think the fuzzing community has a lot to learn from property based testing. These are more advanced topics though, that we hope to cover in a later post, and why we omitted these details from this one.

>This list of issues seems sort of manufactured [...]

Developer friendliness means different things to different people depending on their area of expertise, years of experience, or interest levels. While the list may seem manufactured, we’ve found that unfriendly tooling and uncertainty about what to tackle first can turn developers off even trying to write a fuzz test at all. Understanding what makes a good fuzz test, instrumenting your code properly, running many fuzz tests at scale, and triaging and interpreting the results of a fuzzing run can make fuzzing prohibitively difficult for a new engineer to set up. This is what we’re focused on solving.

>Advertising a product without saying anything about it is off-putting to me [...]

Fair enough. Fuzzbuzz isn’t quite ready for public access yet, so that’s why we’re a bit vague here, but the intention was not to advertise our product (and is why we only wrote a couple paragraphs at the bottom). We were just excited to write a post about fuzz testing, and figured anyone who’s interest was really piqued could get in touch. We hope to expand this post and use this as an educational resource long-term.

[0]: https://en.wikipedia.org/wiki/Differential_testing

[1]: https://guidovranken.com/2019/05/14/differential-fuzzing-of-...

[2]: https://github.com/sigp/beacon-fuzz

[3]: https://hypothesis.readthedocs.io/en/latest/stateful.html?hi...

Argh, this is the paper I meant to link: https://arxiv.org/pdf/2008.06537.pdf

(Updated the above comment as well)

Basic fuzzers can surprisingly go a long way. Barton Miller (the professor who first coined the term fuzzing), actually wrote a paper last year [0] where he just ran a very basic fuzzer against a bunch of common UNIX tools. Even after all these years of testing/usage, they still managed to find a ton of issues.

[0]: https://arxiv.org/pdf/2008.06537.pdf

literally dozens of us!