"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."


The firmware files do not run in the host operating system (BSD, Linux, etc.). To those operating systems, the firmware is data, not executable code. That data is transferred to the target device; it executes in the device.

This is a cost reduction method; the alternative is for the vendor to include a PROM or flash on the device. The risks in either case are essentially the same. However, it can be argued that because problems can be easily a quickly corrected by the vendor in downloaded firmware, using that method increases security.

This code cannot leak data from the host system, unless the host system supplies that data to the device. In the case of a wireless interface for example, it cannot "leak" user data other than that supplied for transmission. In fact its function can be described as leaking data -- it broadcasts whatever information is supplied to it by the connected operating system. If the host is supplying it encrypted material for transmission (i.e., a VPN or SSH connection is in use), what it leaks is not of use to a third party.

The interface between the device and the operating system (PCI bus, IEEE1394, USB, etc.) is likewise secure; the device cannot request data that it is not authorized to access.

As a result, this seems to be a non-issue.

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/281/29381#29381