You've heard of it. All the cool kids are doing it. If you're not doing it, you're living under a rock. C'mon, just try it. The girls will start noticing you if you do it. You'll start meeting all sorts of cool people, and get invited to all the 1337-est parties. No, I'm not talking about cigarettes. I'm talking about fuzzing.

Fuzzing is the process of providing random data (the "fuzz") to the input of a program. Anywhere that input is received into a program, a fuzzer would allow you to test the robustness of your platform. A network fuzzer would be able to construct a random packet of a given type and throw it to an open port. File fuzzers create random files to be opened in a given program. Hopefully, you get the idea. The concept here is not new, but it seems that there has been an increased buzz for fuzzing in the last few years.

This last weekend at Defcon 15, there was a presentation on a network fuzzer called Funk. Fuzzing for me has never been able to draw me to it the way others have clinged to it. Some of that probably has to do with my lack of interest in hardcore security. However, I was drawn to this fuzzer because it was written in Chicken Scheme. Scheme is a great little language from what I've experienced, but I was having a hard time seeing an actual use for the language. So as I sat in the talk, I checked out that code and took a gander. It was a cool idea, and I've already got a little bit of a contribution patch that I'm preparing to submit to the project.

At the BlackHat Briefings in Las Vegas last week, Mozilla released a Javascript fuzzer designed to help browser developers to "fuzz" their browsers to find security vulnerabilities before releasing their products. The media can spin it how they like, but I am glad to see them opening up their tools, and providing documentation on using them. I especially find it useful because Opera, a competing browser, has now used the tool to find at least four bugs in their browser and release a new build. Hooray for communities!

Let's face it, every piece of software has its bugs. However, in the use case that Mozilla is using their fuzzer (and many other companies use their fuzzers), the fuzzing is equal to some great tests. As a web developer by day, I quickly learned that input should ALWAYS be sterilized, no matter how much you "trust" the users of your platform. It's hard, however, for me to find attack vectors in my own software, mostly because I've designed it around one use case, i.e. the one given to me by the "higher-ups." In my mind, I would say "If only I had a tool that would give me some real world use cases," in hopes to cover both stupid users (creating good error reporting) and malicious users (sterilizing the data or failing silently). Creating a good fuzzing tool would fit this bill exactly.

I'm sold on fuzzing now

O'Reilly's OnLAMP blog had an interesting article this morning entitled The Broken Metric of "Intuitive to the Uneducated" Language Syntax which I found very interesting. chromatic is a Perl programmer, and his argument comes from that background. I'll admit that I'm among those developers who say things like "I don’t like to read punctuation" but at the same time, I'll completely agree with him. The basis of a language should not be how easy it is for an unskilled user to pick up and use. And no, this is not about my worries for job security by some "silver bullet" programming language making everyone a programmer

The basic idea of the O'Reilly post is this: In english, I can say "Get out of here!" Depending on my intonations, my facial expression afterwards, and my body language, that phrase could mean many things. It's about the semantic application of the syntax that allows for proper handling by recipients.

Here's a great example: I work everyday in PHP. I work in web applications, and while I write in many other languages in my spare time, I feel most experienced with the standard web application languages (PHP, CSS, XHTML, JavaScript). With minimal training, anyone can learn to develop applications with PHP. It's easy. There's not much linking, compiling, and general headache that most compiled languages require, and there's NO learning curve when it comes to using outside libraries. It's just a simple include('foo.php'). The vast array of builtins also means that whatever you want to do is probably already at your disposal. The problem with PHP is exactly those things that make it so easy to work with as well. All of those modules, builtins, and tools all live in the same namespace. Many functions are merely aliases for other functions. The barrier to entry to PHP development is low, but the amount of expression is also low.

Until I decided to venture out of the php world though, I didn't realize any of this. I had no understanding of character encodings or proper design patterns. Why? Because PHP takes care of it all for you. Put your markup and logic in one file, who cares? Shoot, I care. My brain's context switching between HTML and PHP is taxing. PHP takes care of so much stuff for you that you never really know what you're actually saying.

I've been going through the MIT OpenCourseWare recently, and the first class they teach you in the Computer Science department is all about expressing algorithms in computer code. They start you out with Scheme, which I had heard many zealots talk about, but have never felt to go out and learn it. Now that I am learning it, I see it's power. Scheme allows expression, but the syntax is incredibly simple. You simply cannot become an expert in Scheme by becoming an expert in its syntax. That's not where the power is. Bob Poweruser definitely couldn't just pick up Scheme (or any variant of Lisp) and figure it all out in a few days. The simple lack of a for loop would stop even the most advanced un-programmers.

Learn another spoken language, and this will make even more sense. The ability to express what you're saying is more important than just saying it. Having that flexibility will prove incredibly helpful in the long run.