Arbor Networks: Security to the Core

In our shrill world of paranoia where vendors clench their general counsel’s arm tight enough to powder walnuts, it’s not surprising that End User Licensing Agreements (EULAs) continue to grow in absurdity. With the continued prevalence of free OS’, hardware vendors are undoubtedly under increased pressure to either disclose sufficient information for drivers to be developed, or devote the time and expense to create their own drivers. Though the market share held by industry giants dwarfs the share held by alternative OS’, alternative OS’ are not going away and their market share will only continue to improve over time.Unfortunately, many vendors still have not quite grasped the concept of alternative OS’. At this point, I am sure you are all collectively gasping at the notion of alternative OS’. I often wonder what would hear if I was a fly on the wall of a conference room within one of these fearful vendors. Perhaps questions and exclamations such as, “What is this so called Linux? Where did it come from? Why, I’ve never heard of it before, it must have popped up overnight!”

As we’ve evolved into a highly litigious society, hardware vendors have become increasingly fearful of lawsuits stemming from patent violations. With thousands of hardware patents issued, the potential for infringement is quite high. By documenting their hardware and providing information on how it’s implemented, they expose details that can lead to a patent lawsuit. Whether or not they know they’re in violation of a patent, documentation provides details.

There are, of course, other reasons hardware vendors don’t want to release information on their devices. Some vendors test only the common usage of their devices and don’t fully implement their device to meet the PCI specification. By allowing others to implement drivers they risk embarrassment, which can affect their bottom line. If it isn’t immediately clear that these behaviors impact security, keep reading.

The practice of keeping all this information private is actually creating an environment in which reverse engineering is occasionally the only means available to add support for a hardware device to an OS other than Microsoft Windows. Of course reverse engineering a hardware device may or may not be entirely legal, depending on your Federal District court’s interpretation of the Digital Millennium Copyright Act. Particularly in the case of open source OS’, section 1201(f)(3) of the DMCA created an additional gray area affecting collaborative, distributed software development such as open source development.

Presuming that criminals will continue to be criminals and spend their time trying to find new ways to subvert security systems and exploit vulnerabilities for profit, is it wise to create an environment in which they’re the only experts on hardware reverse engineering (excluding of course our friends at Fort Meade and the vendors themselves)? Taking into account the reluctance of some vendors to share information, the looming threat of costly litigation, and lengthy EULAs a potential developer must agree to before downloading an existing driver, I occasionally find it surprising that we’re still seeing continued open source driver development.

The more knowledge available regarding anything they’re trying to protect to the individuals and organizations that are trying to protect you, the better the protection. As hardware becomes increasingly complex and increasingly programmable, such as programmable microcode running on PC network cards, it becomes a more viable target for attack. Software vendors held all the cards until full disclosure became the mechanism by which pressure was placed upon software vendors. In most cases, pressure is no longer needed and full disclosure occurs well after a vendor has been notified and given time to correct the problem. Should hardware vendors be allowed to continue holding all the cards?

Hardware vendor-supplied open source drivers and documentation avoids making criminals out of developers who wish to develop drivers and those individuals and organizations that in turn develop that products that keep hardware vendors safe. Considering all the time and energy spent on drafting EULAs written in the most dense of legalese, one is forced to wonder if that time and energy shouldn’t be spent writing open source drivers, providing documentation and performing patent searches so that this entire issue might become moot, or at least diminished.

This entry was posted on Thursday, July 13th, 2006 at 7:30 am and is filed under Hardware, Legal, Malware, Reverse Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.