I didn't know about fuzzers before this whole imbroglio -- not denoted as such, at least.

If you know `crashme` you already know one fuzzer, which "intended to test the robustness of Unix and Unix-like operating systems by executing random machine instructions." See https://en.wikipedia.org/wiki/Fuzz_testing

As a good app-sec'er you seem to need to be deeply steeped in fuzzer lore. Matasano: "We'll have you write a fuzzer. Everyone here writes fuzzers." http://www.matasano.com/careers/

(I'm obviously not replying to tptacek, just highlighting a bit. ... And basking in the good glow, yes.)

What about the relative ease and speed with which the bug was fixed? Fuzz testing could certainly find the bug in closed source software, but patching it is a different story, especially if the person or group that controls the source code is slow, uncooperative, or extinct.

I'm not so sure about the fuzzer. We have several good symbolic fuzzers around by ourselves, like fuzzgrind, but not so many open symbolic bug finders, like BAP, MAYHEM, EXE, forensic, cmbc. It could also be that they just added symbolic annotations like with Frama-C (as done with portalssl) and found bugs thereby. openssl nor gnutls is not in the shape to add something like this by themselves.

It's much easier to come up with workable exploits in decent time with symbolic input and the stp or z3 solver than with simple fuzzing.