Modernizing Authentication — What It Takes to Transform Secure Access
Date: 12/14/2017 @ 1 p.m. ET
For us in the security world, summer also brings with it vulnerability season. Perhaps its the students on break; perhaps its the popular Blackhat and Defcon conferences; perhaps its 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 Apples 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 elses? Did they even accomplish what the videotape claimed?
Well, for starters, this attack requires no action on the victims behalf, other than simply running a device driver with this sort of vulnerability in it. But thats 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 theres plenty more privileged code running in just about any system these days, you say?
While thats true, device drivers present a particularly difficult situation. Theyre 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, thats the case with tons of software, right?
Also true, but theres one more bit that makes this especially bad. Its been my experience that software developers, by and large, underestimate the threats that their code will face. Although were 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 dont take user input. They only handle data thats 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. Cs string and memory-handling system calls alone, such as strcpy() and memcpy(), are ripe for attack.
Thats 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. Weve 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.