> many common <programs notoriously available in binary form only> are becoming reasonably hard targets to fuzz and find interesting crashes. There are two solutions to this: write a better fuzzer (<link to source-level fuzzer>)
If you are writing a blog post and have no ideas for the introduction, please just skip it rather than crowbarring in an awkward reference to other items in the news.
AFL isn’t a source-level fuzzer. It interposes between the compiler and the assembler to add instrumentation to assembly code emitted by the compiler. Shouldn’t it be possible to do the same thing via binary rewriting or emulation in cases where source access isn’t possible? The first one would be hard and the second one would be slow, but I don’t think there’s anything about AFL’s approach that would stop this from working.
I agree that it would be completely possible in principle to make an AFL-style fuzzer for binary, and that then it would risk being either brittle or slow (depending on the instrumentation technique used to measure coverage), two properties that AFL explicitly set out to avoid. So a hypothetical AFL for binaries is not really AFL any longer until someone proves it's possible to make one with the same good behavior.
A modified hypervisor that would use the features initially intended for “replay debugging” for measuring coverage instead could be cool, though.
That introduction is not an irrelevant link. It is a link to a bug that admittedly everyone was talking about at the time, but also a bug that was in an open-source library, and that would have been found if the method that was being applied to PolarSSL had been applied to Apple's SSL implementation.
Seriously, one step of the method is “look at every snippet of code that was not visited by the analyzer and explain why it wasn't visited”. One particular usage of a multi-purpose library may always leave you with seemingly unreachable code (that is in fact only useful for other usages of the library), so the presence of such unreachable code cannot be considered a bug, but verifying a library in the way one usage of PolarSSL was verified means each instance of unreachable code is justified.
(The “goto fail” bug could have been found in many other ways, and I admit that makes my using it as an introduction slightly tangential, but it is not my job to advertise all these other ways—some of which are already recognized and easy to apply by a company the size of Apple.)
If you are writing a blog post and have no ideas for the introduction, please just skip it rather than crowbarring in an awkward reference to other items in the news.