Trust with hardware vendors for open source systems is becoming a one-way street, where in exchange for support they offer a closed source binary solution with no provision to audit security.
"If a security vulnerability is discovered in the closed source component, how can we be certain that this issue can be fixed in any limited time frame, or for that matter, fixed at all?"
For those of you that have been following my previous columns, you'll know why I'm a big fan of open source software. Although there are certainly exceptions, I use open source operating systems almost exclusively. Whether it's FreeBSD on my personal laptop and desktop, OpenBSD on my firewall, NetBSD on an old Turbo-Channel DECStation box, or even Mandrake Linux in the office, for security I avoid closed source operating systems as best I can.
This landed me in an interesting position recently, when an 802.11B wireless access point of mine ceased functioning, and I went to look for a replacement. This time, instead of purchasing a hardware-based access point, I opted to go with the more flexible route and decided to install a fourth interface in my firewall; a wireless 802.11G card. Suddenly, I was faced with an interesting juxtaposition of two worlds; open and closed source systems.
Open source software, closed source hardware collide
This is part of a larger problem, but let's start with a simple example. For those of you who haven't travelled down this road yet, let me give you a brief run-down of the situation with regard to supporting the newer (A or G) 802.11 wireless cards on BSD (and Linux). At the time of this writing, the only cards that I'm aware of that support 802.11A or 802.11G that can work on BSD or Linux are those based on the Atheros chipset, which includes cards from several different manufacturers. Although support for some of the other chipsets is pending, the lack of cooperation from all these associated vendors means that you shouldn't hold your breath waiting for them to be supported on your operating system of choice. However, this is a can of worms that I'm not going to open; for now we'll focus on one, the supported Atheros-based cards.
The point here is that in order to use one of the currently supported wireless A or G cards, or some other types of hardware for that matter, an operating system needs to include a closed-source binary-only component provided by the chipset manufacturer.
This is a mixed blessing. On one hand, users of BSD and Linux now have the opportunity to use this new hardware, which was not previously supported by these operating systems at all. This, of course, is great news; I'm happy that the vendor has at least allowed open source operating systems to support their hardware, and even more so, I'm thankful that a developer spent the time to make it happen. They will sell more hardware because of it.
On the other hand, this support is partially provided by a closed source component. Although this doesn't put users of these cards in any sort of severe distress (provided that there are no licensing disputes) or peril, like anything in the security domain, it does have some interesting implications.
How does this affect security?
The closed-source component required to support this hardware is completely independent of the associated operating system, and as such, is also independent of the engineering team, security team, auditing process, and quality control procedures normally related to the operating system. If a security vulnerability is discovered in the closed source component, how can we be certain that this issue can be fixed in any limited time frame, or for that matter, fixed at all?
What's possibly even more disturbing, is that we're talking about a chunk of code in the operating system, running with the highest possible level of privilege (the kernel), which is supplied by a third-party vendor. This code could do anything once loaded, including leaking active WEP keys, gathering usage statistics, sniffing and disclosing traffic, and it could even introduce a subtle backdoor into the operating system itself (much the same as any device driver in a closed source operating system).
Now, if there was any strong likelihood that any of these scenario's might come to fruition, I wouldn't be using a card that requires this sort of driver. And although some of these scenarios are a little far-fetched, the possibility for them to exist is there, and it sets a precedent that may cause a whole host of problems down the road as other hardware vendors follow suit. Ultimately it becomes an issue of trust, which is a cornerstone of good security; who do you trust, and how much do you trust them?
Trust and hardware vendors - a one way street
When it comes down to it, we're not trusted with the inner details of hardware. Fair enough; there are FCC regulations, business concerns, and several other intervening issues, perhaps some that I'm not even aware of. But, on the other hand, we're forced to trust closed-source software components in order to allow hardware to interoperate with our operating system? Where is the middle ground here? Is the only option to use or not use the hardware, period? Something about that just doesn't seem right.
Ultimately, I'd like to see more hardware vendors supporting the open source community, and supporting them without restrictions. I'd like to not have to worry about chunks of potentially vulnerable closed source code in an otherwise open source operating system. In general, this mean an increase in support for the open source operating systems -- a rapidly growing segment of the market that drives new hardware purchases -- from the various hardware-producing vendors. In the end what have the hardware companies really got to lose? Developers shouldn't have to spend their time jumping through hurdles to add support for hardware to the operating systems that they program for. It's a waste of time.
In the world of Unix security, we don't have new worms to talk about every week, and as such, maybe we do tend to be a little paranoid about other issues. But, isn't a little paranoia always important for a security professional?