Some recent articles (including one that I already pointed to in a
previous blog post) about research I did, links below, all missed the
point. The big picture is that, when it comes to software security,
code quality is the most critical factor. The fact that it’s a complex
factor means that many techniques must be brought to bear. The littler
point is that one of those techniques – fuzz testing – remains
under-utilized.

I must briefly digress to explain the first part. First, note that code
quality is not the only factor in a secure deployment. But it is the
most important one.

Second, observe that the production of software is a challenging
endeavor. Obtaining and maintaining high code quality even more so.
What is high-quality code? No needless abstractions, no unnecessary or
undocumented features, well-commented and easy to read, smartly designed
and written based on a reasonable analysis in choice of language and
underlying technology. There are other factors. It’s a complicated
concept even to just describe!

Now, to bridge the gap between code quality and code security. While,
in my experience low quality code is more likely to be insecure,
high-quality code isn’t necessarily without security flaws. For the
software industry as a whole, the obstacles to consistently writing
secure code are numerous. For example, the threat landscape is
constantly changing: what was considered acceptable before may now
represent a major risk. And secure coding is a difficult concept to
teach, if an attempt is even made at all (for example, at the collegiate
level or on the job).

Furthermore, and partly for reasons already cited above, software
security is its own field. So, much as it may be attractive to expect
experts in GUI design or network communication to also be experts in
software security, it just isn’t realistic to do so. Yes, everyone
should know the basics, but the basics are never enough.

Software tools vendors (referring mostly to compilers and commercial
libraries) play an interesting role here, because they are both part of
the solution and part of the problem. That is, all of the challenges
above affect them as well: how to attract, retain, and continuously
retrain developers who can consistently produce not only high-quality
but also highly secure code? And everyone downstream is partly
dependent upon the tools vendors to keep up with the moving target of
security threats. I say ‘partly’ because the true responsibility for
the security of an software application lies with the vendor of that
software – that is, whatever brand name that would be on the front if it
came in a box. Attempts to blame the compiler vendor, or the vendor of
a special library with which the program links, don’t cut the mustard.

It’s not my intent just to pound on developers here; testers play a
critical role as well.

Indeed, testing is the current frontier in software security. I’m not
saying the development/code-generation side is solved, just that the
latest technologies (tools, libraries, platforms) are sufficiently more
secure than what’s actually in wide deployment, and that testing
methodology hasn’t kept up. When it comes to quality, the test team -
Q/A as it’s frequently called – is the last line of defense. Time to
improve that defense.

Fuzz testing is a technique that’s easy to understand and totally
under-utilized. It is not a panacea. Deployed correctly and against
the proper components (parsers, mostly, and there are probably more of
those out there than you think), it is likely to find bugs, probably
significant ones with security impact. That’s partly because of the
randomness involved, and partly because it pounds on the kind of code
that tends to be complex.

Once a fuzzer has been written, deployed, and the related bugs found and
fixed, it becomes another piece of the automation to ensure that
something previously fixed doesn’t become broken again. Just like your
API test, just like your GUI test. Then it’s on to the next technique
or the next component.

But few shops have reached that point, and the tools vendors haven’t
caught on either. It’s time to invest in software security testing:
better tools, better techniques, and more widespread use of the
techniques we already know about.

http://www.jwsecure.com/dan/2008/03/14/look-mom-im-on-dark-reading/

http://www.darkreading.com/document.asp?doc_id=148438&WT.svl=news1_1

http://www.theregister.co.uk/2008/03/18/vista_smartcard_hack/

http://www.heise-online.co.uk/security/Vista-with-smart-card-hacked–/ne

ws/110330

http://msdn2.microsoft.com/en-us/magazine/cc163313.aspx

No Comments »