April 13th, 2007
Raising a doubt
The whole Wintel industry has a security problem you never hear about - in fact, one reason neither Microsoft nor Intel has ever seriously attacked the PC security problem may be that the continuing public uproar over their visible failures both sells product and obscures a much more fundamental security problem affecting the entire PC/x86 industry.
That problem arises from the combination of international sourcing with the use of BIOS software and privileged mode to handle hardware management functions on the same CPU used by OS and applications functions.
Prior to Intel's VT extensions getting an x86 chip to run in privileged mode required the ability to write to physical memory just below 0×0BFFF along with, of course, the provision of the relevant exploit code. In practice that was quite difficult unless you happened to be running on Unix and had the root password, in which case it was easy but pointless. As a result most of the people who looked at this ended up using network start technology to get to, and then hack, the BIOS -but then ran into the problem that there usually wasn't physically enough room to store the code needed for a useful exploit.
Intel to the rescue - in this case with its VT version of AMD's Pacifica systems virtualization support. Now, if you can flip the selection register to an unallocated value you can start your own domain and run any code you like - from the network, from ROM, or from the local disk. Either way what happens is that the machine suspends current OS execution, pops into privileged mode long enough to get your process started, and then runs that process in normal user space mode - while leaving no record of the interruption on return to the original OS and thus leaving the user organization with no means of discovering whether anything happened, and if so what.
It's very cool, particularly because "your code" could include the victim's own licensed OS running an application assembled on the fly from libs and source found on typical implementations of that OS - whatever it may be.
The reason this isn't yet a kiddie clicker thing is that it's hard to pull off - in fact, it may be possible to do this via the network but the only ways I've heard of require physical access.
On the other hand that physical access does not have to take place on the user's premises or even on a fully assembled PC. One of the side effects of having many brands of PCs made by the same people using the same materials is that a strategy as simple as adding some undocumented space, and code, to ROMs used in components like graphics boards or network cards can be used to corrupt tens of millions of PCs around the world - and that code can then be triggered by something as innocuous as the first loading of the target organisation's logo.
So what can the code do? anything its authors want it to - including calling home, reporting configurations, or selectively forwarding applications data: all through invisible tunnels created by having the the program select vulnerable gear on its way out.
And to think, it's not even Halloween.
Paul Murphy (a pseudonym) is an IT consultant specializing in Unix and related technologies. See his full profile and disclosure of his industry affiliations.
Subscribe to Managing L'unix via Email alerts or RSS.
| 04/13/07
