Crash testing at its best is hilarious business. I’ve seen people laughing out loud at internet television that has gone crazy, or a phone that refuses to send any text messages at all because of one invalid message it just could not handle. I’ve heard dozens of brilliant stories of crashed car kits (never fuzz the car audio system in the beginning until you’ve reached your destination, or you might have to endure the silence for the rest of the trip) or desperate fixing attempts of a malfunctioning Bluetooth device (no, creating an exception for one test case does not fix the problem). Watching a device come tumbling down because of the anomalous message you just sent gives a thrilling, exiting feeling that we want to share with as many people as we can.
Codenomicon’s Crash Test Party (that takes place tuesday evening) is a chance to feel that thrill and excitement. We have organized these events in cooperation with universities and corporations, allowing their students and employees to discover the fun side of crash testing.
How do we crash it: the magic of fuzzing
To be quite honest, we do not crash software just for the fun of it. Fun is just a side-effect of our proactive security testing solution.
Our main product, Codenomicon Defensics, uses fuzzing to reveal vulnerabilities in software. It means that our test suites automatically spam the target with thousands and thousands of cases of broken input, overflows, underflows, repetition, and so on to produce crashes or other abnormal responses. When the system under test does not know how to handle the broken input and does something unexpected, it means we have found a vulnerability in software.
Obviously, Defensics test suites have the leading role to play in Crash Test Parties.
What happens in a Crash Test Party?
Codenomicon provides licenses for the test suites and some training on how to use the tools. Of course, Codenomicon security experts are available during the event to help people with any problems they may have.
We also bring some test targets, typically routers, phones, set-top boxes, once even an internet television. Open source projects are always excellent test targets. Of course nothing stops people from fuzzing their own equipment in a crash test party, at their own risk of course. It is not our fault if something crashes and never recovers… There is just one rule: never, ever fuzz anything outside the test network! The last thing we want is some angry maintenance guy knocking on the door, demanding to know why we caused a DoS in their network and who is going to pay for the damage.
After that, it’s time to start crashing stuff! Pick your weapons, configure your target, and fire away. To keep the party going, we provide some drinks and snacks. For successful bug-hunters we bring some cool “Go Hack Yourself” t-shirts so you’ll have something to show for your efforts. If you are good enough, motivated enough, and lucky enough you might even make your way to CERT advisory. This is what happened with two Crash Test Party participants who found vulnerability from Oracle Solaris operating system with Codenomicon’s iSCSI Test Tool: http://www.cert.fi/en/reports/