by TwoBit on 4/27/2020, 12:56:16 AM
by thechao on 4/27/2020, 1:50:06 AM
> The fix for this was fairly straightforward - I just made the library keep a record of the previously visited IFDs and bail out if it found a loop.
If you just want to detect loops, keep a “+1” pointer that you use to increment through the data; also, keep a “+2” pointer that is advanced twice each time your “+1” pointer advances: either your “+2” pointer hits the end, or it becomes equal to your “+1” pointer — in which case you have a loop.
by bhaak on 4/27/2020, 12:17:34 AM
If you haven't read the whole article, you should do that.
There's a funny plot twist at the end.
3 bug reports by discovering 1 bug. What a bargain! :-D
by oweiler on 4/27/2020, 9:17:32 AM
In university we had to write a simple fuzzer which extracted options from man pages and ran the corresponding command with randomized but valid options. Didn't take long until we found the first bug in one of the tested commands.
by Psyladine on 4/27/2020, 3:06:45 PM
"A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone."
by pfdietz on 4/27/2020, 8:22:23 AM
A very funny thing about fuzzing is how random input testing used to be so looked down upon by the software testing community. Read old (1970s) testing books and you'll see comments like "random testing is the worst kind of testing". I still saw this even as recently as a decade ago.
by snazz on 4/27/2020, 12:09:39 AM
Fuzzing is fun! If you're doing it on your personal computer (as opposed to a cloud VM somewhere), I'd suggest putting the testcase output directory on a spinning-rust hard drive that you don't care about instead of your (presumably much more expensive) internal SSD. It creates an impressive number of disk writes.
I've been thinking about fuzzing JavaScript code (not attacking V8 or SpiderMonkey, but the JS code itself). While JavaScript might not be vulnerable to buffer overflows and format string vulnerabilities, it certainly can have logic issues, unhandled exceptions, and DoS vulnerabilities that are exposed by fuzzing.
I took a look at the most-depended-on NPM packages. I'll try writing test harnesses on functions that take user input. Does anyone have any ideas for packages that could use some fuzz testing?
by jansan on 4/27/2020, 9:40:44 AM
It can be difficult to evaluate the result of a test. We solved this by using an existing (of course inferior) library that uses a different algorithm for the same task (different algorithm so it fails at different tests). We would run the same test with both libraries and compare the results. If they were different, we had to find a way to decide which library failed or maybe evaluate those failed cases manually.
by jansan on 4/27/2020, 8:55:25 AM
I have used fuzz testing to make my Bezier intersection library more robust against edge cases. The test would try to find all intersections between a random pair of curves that lie within certain bounds (you probably know that there can be up to nine intersections between two cubic Bezier curves). At the beginning it failed at approx. 1 in 100,000 randomly generated curve pairs, now I am at a point where there is not a single failure in a billion test.
My problem was how to decide if a test failed, because this would not be a crash, but failing to find an intersection between the curves. So I compared against an existing library which uses a completely different algorithm, which means the other library fails at other test cases than my own library. If the results in a test case were different, one must have failed and by testing against the found intersections I could easily decide which one.
by luord on 4/27/2020, 2:03:45 PM
I love case studies like this. They are the best way to show why the subject matter at hand is important and worth investing time into.
by ToFab123 on 4/27/2020, 1:54:54 AM
Interesting. Is there any fuzzing libraries for c#?
by mebr on 4/26/2020, 10:44:10 PM
My summary of this blog post: plenty of random input data can reveal code bugs. The kind of bugs that would take probably a lot of time of think of and write unit tests for, in advance.
by WrtCdEvrydy on 4/26/2020, 11:41:02 PM
It just gets worse and worse....
My favorite personal fuzzing story is from 1987 when a friend said his x86 graphics drawing program was solid, and I said OK and smashed both hands on the keyboard and it insta-crashed.