Researcher Finds Critical OpenVPN Bug Using Fuzzing (zdnet.com)
"Guido Vranken recently published 4 security vulnerabilities in OpenVPN on his personal blog," writes long-time Slashdot reader randomErr -- one of which was a critical remote execution bug. Though patches have been now released, there's a lesson to be learned about the importance of fuzzing -- bug testing with large amounts of random data -- Guido Vranken writes:
Most of these issues were found through fuzzing. I hate admitting it, but...the arcane art of reviewing code manually, acquired through grueling practice, are dwarfed by the fuzzer in one fell swoop; the mortal's mind can only retain and comprehend so much information at a time, and for programs that perform long cycles of complex, deeply nested operations it is simply not feasible to expect a human to perform an encompassing and reliable verification.
ZDNet adds that "OpenVPN's audits, carried out over the past two years, missed these major flaws. While a handful of other bugs are found, perhaps OpenVPN should consider adding fuzzing to their internal security analysis in the future."
Guido adds on his blog, "This was a labor of love. Nobody paid me to do this. If you appreciate this effort, please donate BTC..."
ZDNet adds that "OpenVPN's audits, carried out over the past two years, missed these major flaws. While a handful of other bugs are found, perhaps OpenVPN should consider adding fuzzing to their internal security analysis in the future."
Guido adds on his blog, "This was a labor of love. Nobody paid me to do this. If you appreciate this effort, please donate BTC..."
Fuzzing is essentially harnessing the power of our modern computational power in a brute force fashion, combined with the knowledge that many errors (especially crashes), by nature, can be leveraged into an exploit.
In my own scripting language project, I have two fuzz tests I perform - I first fuzz a set of source scripts, and in another test, I fuzz a set of compiled bytecode, which exercises both the lexer/parser and runtime interpreter phases. I didn't even bother with a library either, just a small routine that randomly swaps and corrupts source from the original. It's really amazing how simple something like that will catch so many bugs.
Honestly, I was implementing this just for the sake of robustness. No one but me is using the library yet, and it's just for local use in my game engine. But if you're connected to the internet in any way, there's really no excuse these days for not having a set of fuzzing tests you regularly run during your normal regression testing, and there are some great libraries available to help do this. You can even leverage Google's massive computational resources for testing for free (perhaps even get paid a small bounty) if your project is important enough, which OpenVPN certainly is. Hopefully the OpenVPM devs/maintainers take note of this and make this happen, and we'll all be more secure for it.
BTW, if you ever want to read about an incredibly comprehensive test and regression suite, check out SQLite's description of their testing methodology: https://www.sqlite.org/testing...
Irony: Agile development has too much intertia to be abandoned now.
...perhaps OpenVPN should consider adding fuzzing to their internal security analysis in the future."
This is FOSS software. If someone is doing fuzzing testing, they should jump in and contribute it. I can't imagine that the OpenVPN project, or any other FOSS software project would say no to such a contribution.
Those who stand around and offer lame suggestions like "$project should do this" are useless IMO.
I'm currently paid to work on FOSS software. There's a lot of things we need to do. There aren't enough resources to do all of them. One thing we definitely don't need are "helpful" comments like this from the peanut gallery.