Further to my recent blog, I notice that Dan Raywood of SC Magazine has flagged the imminent opening of the CanSecWest 2010 conference, with particular reference to the promised presentation on fuzzing by Charlie Miller, who has made something of a speciality of stress testing (in a somewhat imprecise sense) Mac software in order to see what breaks.
Fuzzing is one of those slightly imprecise words (like virus, malware and vulnerability) that tends to mean what the person who uses it wants it to mean. A reasonable starting point for understanding the concept is offered by Sutton, Greene and Amini in a book called “Fuzzing: Brute Force Vulnerability Discovery” (Pearson, 2007): “…a method for discovering faults in software by providing unexpected input and monitoring for exceptions.” Though the sub-title of the book perhaps makes the point more dramatically and understandably for those without a coding background.
The article in SC Magazine quotes two main sources. One is a live Threatpost chat on Mac OS X, Pwn2Own and Writing Exploits: the whole thing is at http://threatpost.com/en_us/blogs/transcript-charlie-miller-mac-os-x-pwn2own-and-writing-exploits-031810 and well worth a read. Also worth looking at is an article by Andy Greenberg at Forbes.com. I quote:
“The moral of the story is that if Apple wants to keep its products secure, it needs to be doing what I’m doing,” says Miller. Until then, it seems, he’ll just have to keep hacking their products for them.
My understanding is that he’ll be talking primarily about his approach to fuzzing on this exercise, though I suspect an awful lot of people will be more interested in his results than his methodology.
Apparently he wrote a short Python script to change one randomly-selected bit of a PDF or PowerPoint file at each test iteration, and fed it to the target application to see if it crashed. He claims to have found “nearly a thousand unique ways” to make Adobe Reader, Apple Preview, Microsoft Power Point or Oracle’s OpenOffice crash. When he looked through the data to see which vulnerabilities were exploitable he claims to have found 20 exploitable bugs in preview compared to three or four in each of the others.
It sounds as if he’s keeping at least some of those vulnerabilities to himself for now, so as to see how promptly the vendors address them without a third-party giving them chapter and verse on what they are. I hope the vendors in question will be looking over his shoulder to ascertain what his methods are, because I’m pretty sure lots of other researchers will be, and not everyone who adopts them will have benevolent intentions.
David Harley FBCS CITP CISSP
Small Blue-Green World
AVIEN Chief Operations Officer
ESET Research Fellow & Director of Malware Intelligence