As I write this, the dog days of summer are nearly over for those of us in the northern hemisphere.

For us in the security world, summer also brings with it vulnerability season. Perhaps it’s the students on break; perhaps it’s the popular Blackhat and Defcon conferences; perhaps it’s just karma. This summer has been no exception, with several interesting vulnerability announcements hitting the streets in the past couple of months.

As a newcomer to Apple’s Macbooks, I was particularly interested in one of the Blackhat briefings in which the authors (John Ellch and David Maynor) claimed to have uncovered a device-driver vulnerability that enabled them to install malicious software on a Macbook Pro in a matter of seconds.

Or so it seemed. Rampant speculation has taken place since the pair aired their videotaped attack at Blackhat. Was it an Apple device driver or some third-party driver? Was it an Apple WiFi card or someone else’s? Did they even accomplish what the videotape claimed?

None of those questions (or their answers) matter. There’s a much bigger issue here than what’s been covered in the popular trade press. Who cares if it was an Apple driver (well, other than Apple)? The real issue is that they exploited what appears to be a buffer overrun attack in device-driver space and managed to execute arbitrary code on a victim system. So what, you say?

Well, for starters, this attack requires no action on the victim’s behalf, other than simply running a device driver with this sort of vulnerability in it. But that’s not the big deal, either. The big deal is that the attack was against a driver. Device drivers, by their nature, run in kernel space with (usually) full privileges. Software security defects there are significantly magnified in their impact. But there’s plenty more privileged code running in just about any system these days, you say?

While that’s true, device drivers present a particularly difficult situation. They’re often supplied by third-party vendors. They run in privileged mode. Few people do any sort of verification of their drivers prior to installation. Still, that’s the case with tons of software, right?

Also true, but there’s one more bit that makes this especially bad. It’s been my experience that software developers, by and large, underestimate the threats that their code will face. Although we’re making progress on that front, device-driver developers tend to think their code is particularly isolated from many of the user problems that plague much of our software these days. After all, they don’t take user input. They only handle data that’s passed to and from infrastructure components (e.g., disk drives, networks, operating systems). Why should they be concerned with buffer overrun problems?

Further, device driver software needs to be “lean and mean.” Drivers are often written in C or even assembly language to maximize performance and minimize their memory footprints. Both languages (if you even want to call assembly a “language”) are prone to buffer overruns. C’s string and memory-handling system calls alone, such as strcpy() and memcpy(), are ripe for attack.

That’s the big deal. Device drivers are a soft underbelly of our operating systems that have been ignored for far too long, and those that would attack us are paying attention to the weaknesses inherent in them.

We can no longer afford to treat device-driver software with any less of a security priority than any other software. We’ve got to hold our vendors to a higher standard. And that means vendors far beyond Redmond, Portland, and Cupertino. It means every device vendor that provides a driver CD with his product.

Enjoy the Autumn.