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.
Related Stories
Submitted via IRC for TheMightyBuzzard
Since the launch of AMD Ryzen, a small piece of hardware that handles basic memory initialization as well as many security functions has been the center of some controversy. Called the Platform Security Processor (the "PSP" for short) it is essentially an arm core with complete access to the entire system. Its actions can be considered "above root" level and are for the most part invisible to the OS. It is similar in this regard to Intel's Management Engine, but is in some ways even more powerful.
Why is this a bad thing? Well, let's play a theoretical. What happens if a bug is discovered in the PSP, and malware takes control of it? How would you remove it (Answer: you couldn't). How would you know you needed to remove it? (answer, unless it made itself obvious, you also wouldn't). This scenario is obviously not a good one, and is a concern for many who asked AMD to open-source the PSPs code for general community auditing.
Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.
Previous:
The Intel Management Engine, and How it Stops Screenshots
Intel x86 Considered Harmful
Of Intel's Hardware Rootkit
Intel Management Engine Partially Defeated
EFF: Intel's Management Engine is a Security Hazard
Malware uses Intel AMT feature to steal data, avoid firewalls
(Score: 3, Insightful) by Anonymous Coward on Friday October 30 2015, @02:07PM
A researcher (Ms. Rutkowska) with the balls to say what lots of other people have been muttering in their offices over the years. And the research chops to back it up.
(Score: -1, Offtopic) by Anonymous Coward on Friday October 30 2015, @02:11PM
Bit below the belt there!
Everyone is agreed Intel ME / AMD PSP are unwanted, so what are the viable alternative platforms for equivalent workloads?
(Score: 1, Insightful) by Anonymous Coward on Friday October 30 2015, @02:15PM
I'd like to see MIPS64 make a comeback. PowerPC seems to have been tried and failed.
(Score: 0, Offtopic) by Anonymous Coward on Friday October 30 2015, @02:27PM
Also (this is to SN Mods), what is with the stupid beards men choose to wear these days?
Those guys need to be punched in the face!
(Score: 0) by Anonymous Coward on Friday October 30 2015, @02:37PM
Progressive sexism is still sexism dear. Is there something else relevant to your example that would exclude a trans-woman from having a stupid beard and needing a punch to the face?
(Score: 2) by FatPhil on Friday October 30 2015, @03:03PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Informative) by Anonymous Coward on Friday October 30 2015, @02:13PM
I will save you the 44 pages of drivel and show you the half-a-page summary:
We have seen that the Intel x86 platform offers pretty advanced isolation and
sandboxing technologies (MMU, VT-x, VT-d) that can be used to effectively
de-privilege most of the peripheral devices, including their firmware, as well as
their corresponding drivers and subsystems executing as part of the host OS.
This allows to build heavily decomposed systems, which do not need to trust
networking or USB devices, drivers and stacks. This does require, of course,
specially designed operating systems to take advantage of these technologies.
Sadly most systems are not designed that way and instead follow the monolithic
paradigm in which almost everything is considered trusted.
But one aspect still presents a serious security challenge on x86 platform: the
boot security. Intel has introduced many competing and/or complementary
technologies which are supposed to solve the problem of boot security: support
for TPM and TXT, support for SMM sandboxing, finally Boot Guard and UEFI
Secure Boot. Unfortunately, as we have seen in the first chapter, none of these
technologies seem satisfactory, each introducing more potential problems than it
might be solving.
Finally, the Intel Management Engine (ME) technology, which is now part of
all Intel processors, stands out as very troublesome, as explained in one of the
chapters above. Sadly, and most depressing, there is no option for us users to
opt-out from having this on our computing devices, whether we want it or not.
The author considers this as probably the biggest mistake the PC industry has
got itself into she has every witnessed.
(Score: 2) by Runaway1956 on Friday October 30 2015, @03:23PM
Thank you for that. I did wade through a lot of verbiage, and still couldn't figure out what she was saying. Your summary helped a lot.
(Score: 5, Insightful) by tangomargarine on Friday October 30 2015, @03:46PM
But one aspect still presents a serious security challenge on x86 platform: the
boot security. Intel has introduced many competing and/or complementary
technologies which are supposed to solve the problem of boot security: support
for TPM and TXT, support for SMM sandboxing, finally Boot Guard and UEFI
Secure Boot. Unfortunately, as we have seen in the first chapter, none of these
technologies seem satisfactory, each introducing more potential problems than it
might be solving.
How would one go about "solving the boot security problem?" It seems like a chicken-and-egg situation to me. Either you accept some amount of risk that if somebody gets their physical hands on your machine, you're boned, but it's easier for you, the customer, to use; or you add crazy anal probes like Secure Boot (I rather doubt the version now is their endgame...hardware whitelists and TPM, anyone?) that make it much harder for you, the customer, to tinker with your stuff, but secure it for...somebody else.
Can somebody give an example of boot security done "right"?
Security, especially in this situation, boils down to fail-secure or fail-usable.
1) OS security can be avoided by booting something else on the same machine and then just reading the hard drive to ignore permissions.
2) So make it so you can't boot anything but the installed OS by locking the BIOS.
3) But you can reset the BIOS by pulling the cell battery.
4) So do something else so that you can't do that.
If you make it impossible to circumvent, then of course you're boned if you forget your own password.
Just talking out of my ass here.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Saturday October 31 2015, @10:59AM
3) But you can reset the BIOS by pulling the cell battery
The coin cell on your motherboard keeps your CMOS from losing its marbles.
BIOS is a completely different chip.
-- gewg_
(Score: 2) by tangomargarine on Sunday November 01 2015, @04:35AM
Complementary metal-oxide semiconductor, or CMOS, typically refers to a battery-powered memory chip in your computer that stores startup information. Your computer's basic input/output system (BIOS) uses this information when starting your computer.
You may notice on the initial start up screen, called the POST screen, an option is available to enter the BIOS or CMOS setup. When you enter this setup area, you are entering the CMOS setup, not the BIOS setup. The BIOS chip and program cannot be updated directly by a user. The only way to update the BIOS is using a BIOS flash program called a BIOS update, which updates the BIOS to a different version.
So it's where your BIOS settings are stored, not the BIOS itself? Which in this case is exactly what we care about--the password.
I guess I don't follow your point. Other than perhaps being technically correct.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(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.
(Score: 0) by Anonymous Coward on Friday October 30 2015, @02:59PM
UltraSPARC IV. "IV Ever."
https://en.wikipedia.org/wiki/UltraSPARC_IV [wikipedia.org]
Too bad that whole line is trapped in the dungeons of Oracle/Mordor.
(Score: 2, Funny) by Anonymous Coward on Friday October 30 2015, @03:24PM
Mordoracle?
(Score: 2) by turgid on Friday October 30 2015, @07:04PM
Sun open sourced a lot of the SPARC design so anyone can use it if they want. UltraSPARC IV was very late and therefore slow. It's replacement, project Millennium, was killed in 2005 ie 5 years late and no product. Rock flopped. That's why they went with Niagara (T1) and Fujitsu SPARC64.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Friday October 30 2015, @03:26PM
IME is THE security flaw of the decade.
(Score: 2) by Bot on Friday October 30 2015, @04:27PM
> security flaw
*backdoor with plausible deniability.
I can't believe somebody can design that stuff for the sake of end user's security.
Want secure boot? formally verify the simplest bootloader you can think of, and make it redscreen with the hash of the payload whenever it detects it's changed, requesting the user to agree. Coreboot could pull this off, why can't INTEL? BTW, intel: nomen omen.
Account abandoned.
(Score: 3, Interesting) by Techwolf on Friday October 30 2015, @03:53PM
This is one reason i am happy to see ARM taking off like it is. Best part is anyone can make them. No Intle monipoly.
Slightly off-topic, but how did the horriable memory mapping come about? ROM shoulda started at 0x00 and RAM after that. Then RAM coulda been expanded beyound current bit with without having to hack it in. 0 Is allways 0, even 00000000.
Example:
ROM 0000 to 0100 increased to xx bits, 00000000 to 0000100.
RAM 0100 to ffff increased to xx bits, RAM 00000100 to fffffffff.
(Score: 4, Informative) by NCommander on Friday October 30 2015, @05:38PM
As someone who worked with ARM, trust me, it's not better from a security perspective. Its essentially the same as x86 minus the backward compatibility.
ARM32 and AArch64 (ARM64) both come with trustzone built onto the die which allows you to run a hypervisor transparently to the main operating system. On AArch64, your processor comes out of reset in EL3 , and can thus hide things from lower privilege levels. Furthermore, at least on AArch64, ACPI has become a standard, which requires the ACPI runtime baked into the kernel (which must run unsandboxed and capable of running any command itlikes)
Still always moving
(Score: 2) by LoRdTAW on Friday October 30 2015, @07:06PM
Thanks to Microsoft's craptastic Windows 8 and 10. Otherwise there would be no need to port such a broken system management setup to ARM.
(Score: 2) by NCommander on Friday October 30 2015, @11:40PM
There were technical justifications for why ACPI won over flattened device tree, specifically because FDT is a descriptive only environment. A properly coded ACPI table allows a LOT of hardware to just work without individually written drives. Most fan systems are controlled by a I2C chip. Withotu ACPI, you'd need to know where the I2C chip is on the system bus, a specific driver for said chip, and then a driver for fan control. With ACPI, you can define the standard fan control methods and it "just works".
I'm not saying ACPI is genius, but if you're dealing with a vendor who actually tests their ACPI implementation against something that isn't just Windows, and follows the spec, you'd be amazed on how Linux can "just work" for the most part. A lot of the enablement of Linux for x86 laptops on an OEM side is mostly fixing the ACPI tables, and then making sure the right firmware is cooked in.
Still always moving
(Score: 4, Interesting) by novak on Friday October 30 2015, @08:43PM
The only mitigation to ARM's many woes is that at least we have multiple vendors producing them and the BIOS is sometimes open. x86 is rapidly becoming intel only, and nearly every x86 board ever made runs proprietary BIOS and firmware.
Going to another architecture- even one not much better- could still be a massive step in the right direction as the amount of devices running open firmware skyrockets. Allowing modification of firmware and BIOS at least helps clear up glaring backdoors like IPMI and badUSB which have been standing wide open for years.
novak
(Score: 2) by NCommander on Friday October 30 2015, @11:42PM
ARM mostly uses the same UEFI base (TianoCore) as x86 for anything that isn't embedded.
I'm not kidding when I can say with a straight face it was an improvement in increasing the "just works" factor over u-boot. Unfortunately, TianoCore isn't GPL, so its not required that vendors post their firmware source.
Still always moving
(Score: 4, Interesting) by unzombied on Friday October 30 2015, @09:02PM
Has anyone tried Rutkowska's Qubes [qubes-os.org]? Looks useful even though susceptible to the same hardware/firmware exploits.
(Score: 0) by Anonymous Coward on Saturday October 31 2015, @12:53AM
at getting rid of IME (and other intrusions): http://puri.sm [puri.sm]
(Score: 2) by Subsentient on Saturday October 31 2015, @02:04AM
Nowadays I just don't. I care more about locked bootloaders, operating system restrictions, and limitations on consumer choice.
I'll be happy with ARM, MIPS, x86, whatever, as long as I can do what I want with the thing.
Now with Windows 10's UEFI updates, it's becoming like with smartphones that are boot locked and will only run the OS they ship with, or updates thereof.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti