How to break everything by fuzz testing
chameth.com
How to break everything by fuzz testing
1–10 of 39 posts
Re: How to break everything by fuzz testing
#2My 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.
Re: How to break everything by fuzz testing
#3My 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.
The kind of bugs that would take probably a lot of time of think of and write unit tests for, in advance.
Would it? Maybe it's because I've had a "low-level upbringing", but whenever I'm writing parsing code for a file format, "assume any byte of data you read can have any value" is the norm. The rest of it follows from there.
Re: How to break everything by fuzz testing
#4It just gets worse and worse....
Re: How to break everything by fuzz testing
#5Fuzzing 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?
Re: How to break everything by fuzz testing
#6If 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
Re: How to break everything by fuzz testing
#7Fuzzing 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 itse…
> 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.
Even better, use the /dev/shm RAM disk if your memory is more than enough (although you should probably create an additional RAM disk with a size limit if you don't want a runaway program to accidentally drain your RAM). On a modern development machine, taking 2 GiB out for testcase issue is usually not a problem, and there's often a significant acceleration.
Re: How to break everything by fuzz testing
#8My 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.
Re: How to break everything by fuzz testing
#9> 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.
Re: How to break everything by fuzz testing
#10Interesting. Is there any fuzzing libraries for c#?