The importance of languages for the professional developer

I started to write that this was not the usual sort of blog post, but I haven’t actually written on the same subject twice. So, more accurately, this is not really a security blog post. Having said that, I’m going to start with a brief description of the security problem that inspired the post.

 

Earlier this year, I had the need for a custom fuzzer and the corresponding test harness. For non-security folk, a fuzzer is simply a tool for generating malformed data and providing it to a software component under test.

 

There are four steps involved in effective fuzzing. First, we need to generate the actual attack data. This can be done by malforming legitimate examples of data, or by using some sort of heuristic to create data from scratch. Second, we need to deliver the data to the software component we’re trying to break. Third, we need to be able to actually detect failure cases. And fourth, we’ll ideally want some mechanism for triaging failures so that we can go through them efficiently.

 

The above description pretty much ends the security-specific part of this. But in writing the suite of tools I needed for those four steps, I realized that there was an aspect to the development that I wanted to talk about.

 

Hammer and Screws
Copyright: tdoes / 123RF Stock Photo

There is an old truism that “if all you have is a hammer, everything looks like a nail.” The corollary to this is that if you are a devout hammer advocate, you’ll go around insisting that everything is in fact a nail, something the cat will find enormously confusing and possibly a bit threatening. For a professional software developer, languages (and their related libraries or other components) are the tools we use. If you only know one or two languages, you are deeply at risk of trying to hammer in a woodscrew. It may work, but it isn’t ideal.

 

In building this suite, some of the components could be written in anything, while others were strongly constrained.

 

The actual generation of the malformed data could have been done in any language. I chose to write it in F# because I really like F#, and I could write it quickly and effectively. Since I’m the only developer for this project, I didn’t have to worry about picking a language in which everyone on the team was fluent, but that is a real consideration on larger projects.

 

The lines of demarcation in the next two components do get a little blurry, since there are three pieces handling two functions. Since this fuzzer is built for looking at browser attack surfaces, one of those components is going to have to serve web pages.

 

The actual web server is again written in F#, and is tightly integrated with the fuzzing logic. This is paired with a client-side instrumentation written in JavaScript, which provides feedback to the server.

 

The instrumentation is a case where you don’t really have a choice. JavaScript is, for all intents and purposes, the native language of the web. The JavaScript is also a glue component; the feedback it provides both informs the fuzzing and serves as part of the monitoring of the test cases.

 

The second part of the monitoring is written in Python. Specifically, it is a relatively short program that uses Pykd to launch and monitor the browser processes. There were other options here; I could have tried to write scripting inside of WinDbg, or I could have written a wrapper in C++ that hosted WinDbg and handled the monitoring. But writing the Pykd wrapper took a pleasant weekend morning in the local coffee shop; writing a COM-based wrapper in C++ would have been far more difficult and taken at least a week, probably more.

 

The last component allows us to triage our detected crashes so that we can categorize them by importance and filter out duplicates.  The tool we’ll use for this is the !exploitable Crash Analyzer. Normally, I would not count this since it is a readily available open-source tool, but since I wrote it while at Microsoft, I’m going to go ahead and include it as an example. For this component, you pretty much have to use C++; it is a DLL extension for WinDbg. You could have written it in some other native compiled language, but really, this is a case for C++.

 

Four problems, five components, and four languages. For two components the language choice was tightly constrained, one had a couple of options but one that was clearly superior, and for two of them I could have used anything. Programming languages are fundamental tools for developers; the more you know well, the more options you have.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.