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..."

Comments

Re:perhaps, perhaps, perhaps.

[LostMyBeaver]

Security researchers are generally quite useless. When the report came out that OpenVPN was blessed as being secure by some high profile security researchers, I immediately went to the code base and within about 20 minutes just left as I found from a very brief review of the code an endless pile of likely attack vectors for the code. The only reason by the code was considered secure is because a security researcher ran nmap or Kali against it and it held up.

I turned up far more holes in that code through visual analysis for 20 minutes than this guy did fuzzing with far more resources. The OpenVPN code is among some of the worst code I've come across in a while. It's almost bad enough to be a VMware linux guest kernel driver.

I would have started making bug reports but honestly, that code is roughly what you'd expect from a research project for testing new ciphers. The amount of time it would take to list just the problems in their certificate code alone and provide meaningful test data would be far beyond what I'd be willing to invest in a piece of code that takes security so lightly.

I would say that OpenVPN is still many steps away from being ready for fuzzing. It would profit far more from a decent code review by people who understand programming theory, then by people who understand code security. It would help a lot if people who understood certificates AND programming looked as well.

So... while darthsilun is a bit of an ass with his wording, I'll say this, the poster begging for bitcoins for writing a 10 line script to try and crash OpenVPN really isn't being too helpful by saying "they should do this" where in reality, he should download the source code, add his test to the code, then check it in. This is how open source works.

If he believes the project should do this, then he should join the project. But simply writing a fuzzing script and tossing it at the code isn't productive. It's like standing and saying
    "Someone should help this little old lady cross the street"
    "Why don't you help her"
    "I believe it would be better if I simply stand here and watch for other little old ladies so I can say someone should help them"

OpenVPN is crap code. it's an endless pile of :
  - Linux kernel style shit C code with no input validation,
  - Absolute dependence on meaningless and generally ignored return codes
  - Spaghetti crap of "look mom, I wrote my own string compare function"
  - Function before anything else
  - Wow, we do certificates!!! Do you actually validate the certificate while parsing? Nope... we'll just assume that no one but nice people will send us certificates