Comments on: Fuzzing for correctness

By: tqft

tqft — Fri, 03 Aug 2007 23:13:51 +0000

Not sure if this is what you are looking for – but hinky code designed to break on being broken could be fun.

http://isc.sans.org/diary.html?storyid=3219
“After downloading the JavaScript file it was obvious that all function and variable names are complete random. Further to that, the deobfuscation function used the well known arguments.callee.toString() trick in order to prevent modification of the code (so you just can’t replace the final document.write() call to something else as this will break the deobfuscation function body – attempts such as this one typically throw the function into an endless loop).”

I am sure the people at isc.sans.org would send you some samples to throw in. Asking for stuff that has been designed not to be compiled might flush out a few corner cases and raise the temp in the arms war a bit more.

By: Fredrik

Fredrik — Fri, 03 Aug 2007 09:43:18 +0000

Of course. Though “weird” in my mind doesn’t necessarily mean “out of domain”, Carrot Top is still (well, arguably) a human being.

The goal would naturally be to try and isolate cases where a crash is highly unpredictable and means that it could either go boom, elevate privileges or cook you a steak dinner. From what I read about the ActiveX fuzzer (I’ve misplaced the link, there was something about it on SecurityFocus, though) it found some really nasty things no one expected. In the scope of these things, that would be a really good thing.

By: Jesse Ruderman

Jesse Ruderman — Fri, 03 Aug 2007 09:13:28 +0000

I think it’s reasonable for an object’s code to crash if the object is given input that’s inconsistent with invariants stated in its interface. There are some “internal” objects that would be great to fuzz, but just because something is an XPCOM object doesn’t mean it needs to be paranoid.

By: Fredrik

Fredrik — Fri, 03 Aug 2007 08:47:46 +0000

I’d been thinking about fuzzers for Mozilla-the-platform but wasn’t aware of your work. My thoughts were geared more towards an XPCOM fuzzer, after reading about ActiveX/COM fuzzers finding heaps of bugs in IE. (It seems like a logical vector, COM being what it is.)

Generally, I think it would be very beneficial to bulk-test all XPCOM interfaces with weird input data to catch any systemic or local problems arising from that. It needn’t be that they’re accessible from the web or that they are part of privilege escalation, but interface correctness and avoiding “garbage in — crash-go-boom out” I suppose is always a high priority. (I’m unsure how much testing goes into XPCOM interfaces to begin with, it may be redundant to call in the fuzz.)