These are attacks on computer systems and networks based on exploiting hardware design or manufacturing bugs, or "not playing by the rules" in dealing with the hardware. The idea of violating the "rules" by freezing the semiconductors or overwriting Ethernet firmware data seems analogous to the very common software vulnerabilities caused by not fully validating user input. Well, maybe not just analogous, maybe we should consider frigid liquids or Firewire signals or Ethernet signals as user-supplied input just like packet contents or form data submitted to web servers.
What makes these different is that we don't generally have control of the hardware design and manufacturing. Yes, you could choose to buy an Ethernet card or CPU or motherboard from a different manufacturer, but you have to choose from what the existing market.
Furthermore, while there are some interesting open-source hardware projects, they are the exception and do not generally provide the features and performance needed. Enthusiasts must not forget that the features required by corporations and government agencies include a well-known and trusted hardware manufacturer.
Turn off the NX bit while running:
Modify the TPM (Trusted Platform Module) chip:
Modify the processing hardware:
Freeze the memory:
Break in through the Firewire port:
Break in through the network interface hardware:
There have been stories of counterfeit hardware from
Cisco modules down to integrated circuits for some time.
The first thing I noticed explaining just how these parts
get into the parts supply stream was this
Business Week
article,
"Dangerous Fakes",
subtitled
"How counterfeit, defective computer components
from China are getting into U.S. warplanes
and ships".
Given the horror stories it contains of entirely unmonitored suppliers chosen for U.S. military parts based largely if not entirely on their status as "disadvantaged", "woman and minority owned", and so on, I can see why the government didn't explain the details immediately....
All AMD processors made during 2000-2010 included a secret debugging feature well outside the standard x86 architecture definition. All processors starting with the Athlon XP have a firmware-controlled feature that can put the CPU into debugging mode. See the article the The Register for an overview, the announcement by the discoverer for far more details, and this list of undocumented Machine Specific Registers in AMD processors.
If the hardware won't even do what it's supposed to, there are big problems!
There were some interesting short articles about Intel Core 2 bugs, see here and here for the articles, and also see the background on Intel's quiet patch release. Affected CPUs were the Core 2 Duo E4000/E6000, Core 2 Quad Q6600, Core 2 Xtreme QX6800, QX6700, and QX6800.
Historical notes:
VirtualBox is a virtualization product that used to be from Innobox, which was purchased by Sun, which was purchased by Oracle.
See this message from the OpenBSD project leader reporting that CPU registers become corrupted under VirtualBox. "We don't know how other operating system products continue running when the userland ecx register gets clobbered on a return from a page fault, but at least people should be aware that there is likely some security risk from running that product. That VM does not emulate the x86 correctly, (either)."
|
|
|
|||||||||
|
|||||||||
|
| © Bob Cromwell Feb 2012. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache. Root password available here, privacy policy here. |