Google turns up a CNET article from 2007 (probably because eEye was "pumping press releases left and right"):[1]
> Researchers at eEye used a standard process of code auditing in discovering the vulnerabilities, [eEye CEO Ross] Brown added. He noted that Microsoft either did not do a 'good job' with its code auditing, or it may not have had enough people working on such a task.
I don't really get this culture of racing to find a bug in another company's product, then strutting about finding one (in Microsoft Publisher of all things) and throwing shade. I guess we should all be so lucky to have a company whose "standard process" is to pull a week of all nighters testing our product.
The interesting thing to me is the stark difference between this and golang's approach.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
some fuzzing tools (libFuzzer for example) leverage LLVM's intermediate representation to provide code-coverage metrics that they feed back into their fuzzing algorithms, increasing test coverage
LibFuzzer is packaged with clang, so there is no additional installation [0]. You just have to provide an entry function and link it with a command-line flag. However, since C and C++ lack reflection, you have to work with raw bytes as input.
LibFuzzer has the option to provide callbacks that customize mutation, which can help with obtaining coverage.
I think it would go the other way where you use coverage to guide reinforcement. Crank the temperature up to increase variation and you would probably produce a model that could approximate the file format you were targeting.
fuzzing lore: https://threadreaderapp.com/thread/1799457232607985698
great read if you wanna waste 11 minutes
Google turns up a CNET article from 2007 (probably because eEye was "pumping press releases left and right"):[1]
> Researchers at eEye used a standard process of code auditing in discovering the vulnerabilities, [eEye CEO Ross] Brown added. He noted that Microsoft either did not do a 'good job' with its code auditing, or it may not have had enough people working on such a task.
I don't really get this culture of racing to find a bug in another company's product, then strutting about finding one (in Microsoft Publisher of all things) and throwing shade. I guess we should all be so lucky to have a company whose "standard process" is to pull a week of all nighters testing our product.
[1] https://www.cnet.com/news/privacy/flaw-found-in-office-2007/
Fantastic read. Funny, relatable, all the technical details, and so much heart. Thank you for sharing it!
The style of writing certainly added a lot to it.
Edit: I just checked the author, I might actually know him from IRC. The "Mantis" and "infosec" checks out.
small world we live in...
The interesting thing to me is the stark difference between this and golang's approach.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
some fuzzing tools (libFuzzer for example) leverage LLVM's intermediate representation to provide code-coverage metrics that they feed back into their fuzzing algorithms, increasing test coverage
Golang does that natively ;-)
LibFuzzer is packaged with clang, so there is no additional installation [0]. You just have to provide an entry function and link it with a command-line flag. However, since C and C++ lack reflection, you have to work with raw bytes as input.
LibFuzzer has the option to provide callbacks that customize mutation, which can help with obtaining coverage.
[0] https://llvm.org/docs/LibFuzzer.html
I proposed using reinforcement learning to guide coverage as a potential phd topic, but didn't really go down that path, no idea if it could work
I think it would go the other way where you use coverage to guide reinforcement. Crank the temperature up to increase variation and you would probably produce a model that could approximate the file format you were targeting.
Did you try making small changes to your phd proposal to see if it opened up new paths?
</fuzzingjoke>
Please tell us more!
Fuzzing is often a special case of genetic algorithms, so there is already a tiny connection to RL. I'm curious to hear what your proposal was.
I am surprised Heartbleed is not on the list, it’s very easy to duplicate.
Thank you for sharing this - very useful!!!