SoylentNews is people
SoylentNews
Joanna Rutkowska's blog points to recent paper on a survey of the various problems and attacks presented against the x86 platform over the last 10 years. The paper does not present new exploits but does cover: the BIOS (UEFI) and booting; peripherals; the Intel Management Engine; and several other aspects of x86 insecurity. Some of the problems appear insurmountable as described.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
TOO BAD YOU CAN'T BUY a voodoo globe so that you could make the earth spin
real fast and freak everybody out.
-- Jack Handey, The New Mexican, 1988.
(Score: 4, Insightful) by Thexalon on Friday October 30 2015, @02:44PM
- Is there an alternative platform that has completely solved these problems? Yeah, I didn't think so.
- Are these problems best solved by the CPU? For example, if the risk is overwriting the BIOS firmware, then the solution would seem to me to be putting the BIOS through much more rigorous testing than it currently gets, and perhaps even going from firmware to an old-school ROM.
- Since some of these attacks require physical machine access, what's to prevent such an attacker from swapping out the presumably invulnerable new hardware with vulnerable old hardware?
- How real versus how theoretical are these attacks? As in, are these approaches that are commonly used, given how easy it is to pwn systems at the application or OS level instead?
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @02:50PM
They use "x86" not as the name of the CPU, but as the name of the platform.
Indeed they explicitly note that the CPU provides everything needed to make an OS secure, but that the existing operating systems don't make use of that.
(Score: 2, Funny) by Anonymous Coward on Friday October 30 2015, @02:54PM
Windows would require re-activation. ;-)
(Score: 1, Insightful) by Anonymous Coward on Friday October 30 2015, @03:25PM
and perhaps even going from firmware to an old-school ROM
You have hit on it right there. We want field up-gradable firmware. Yet do not want to add in a jumper to make it read only.
If your utility can write to it then someone else can too.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @05:02PM
And instead of solving problems like BIOS malware with a simple jumper, the industry resorts to horribly over-engineered solutions like secureboot.
(Score: 2) by NCommander on Friday October 30 2015, @05:40PM
Most EEPROM chips have a write-lock which is tripped by most firmware to prevent it from being updated. This is standard on UEFI systems where the environment can take a capsule file, and then flash it to the ROM chip without making said EEPROM writable by the operating system.
Still always moving
(Score: 0) by Anonymous Coward on Friday October 30 2015, @07:32PM
I'm not an electrical engineer but AFIK, it's possible to create a set-only volatile flags which once set can prevent the overwriting of the chip in the physical circuitry even by the BIOS itself. This would allow to ensure that only uncompromised firmware code can update itself as long as the flag is always set before executing the boot loader, for example, by ensuring that the user must always actively confirm the update when flashing through software.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @08:53PM
The Free Software Foundation tells [fsf.org] us that "AMD chipsets do not contain anything like AMT. Note, however, that there are other comparable problems in hardware from both Intel and AMD." There's a laptop they recommend [soylentnews.org]; it sounds like the purveyor faced great difficulty [fsf.org] in removing the spyware from the BIOS.
AMD has been participating in the development of standards for remote managemhttp://www.dmtf.org/standards/smashent called DASH [dmtf.org] (for desktop and mobile computers) and SMASH [dmtf.org] (for servers). The specifications, at least, are supposedly open.