[HN Gopher] Fuzzing 101
___________________________________________________________________
Fuzzing 101
Author : udev4096
Score : 246 points
Date : 2024-10-05 05:51 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| raister wrote:
| Thank you for sharing this - very useful!!!
| michaelmure wrote:
| 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.
| greybox wrote:
| 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
| michaelmure wrote:
| Golang does that natively ;-)
| csb6 wrote:
| 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
| ackbar03 wrote:
| 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
| lolsowrong wrote:
| Did you try making small changes to your phd proposal to see
| if it opened up new paths?
|
| </fuzzingjoke>
| daghamm wrote:
| 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.
| carom wrote:
| 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.
| mixtureoftakes wrote:
| fuzzing lore:
| https://threadreaderapp.com/thread/1799457232607985698
|
| great read if you wanna waste 11 minutes
| johnisgood wrote:
| 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.
| mixtureoftakes wrote:
| small world we live in...
| chrisweekly wrote:
| Fantastic read. Funny, relatable, all the technical details,
| and so much heart. Thank you for sharing it!
| SloopJon wrote:
| 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/
| SamuelAdams wrote:
| I am surprised Heartbleed is not on the list, it's very easy to
| duplicate.
| mtlynch wrote:
| The tutorials here all use local files or local data rather
| than network-based fuzzing, so I think that's why it doesn't
| appear.
___________________________________________________________________
(page generated 2024-10-06 23:01 UTC)