20 ms·
Intel x86 Root of Trust: Loss of Trust
- mindslight 7y agoThis is great news! Undermining remote attestation is a win for the open web and free society. And perhaps it means we can get Libreboot on something newer than Ivy Bridge.
- Karunamon 7y agoThis was my first thought as well. It seems these management engine tools have only two uses in the real world: enterprise IT, and various forms of DRM. Both exist to treat the user as a hostile entity.
- mindslight 7y agoWell it would be nice for cloud servers, so that you wouldn't have to trust the hosting provider. But given the choice of needing to trust (cloud: intel, home: intel), and (cloud: intel+provider, home: nobody), it would be foolish to not choose the latter! At the individual level, remote attestation has a particularly terrible end game. Think of all those websites that attempt to enforce their desired business whims client-side, that we rightfully laugh at - browser fingerprinting, image save as, anti-adblock, etc. Now imagine they're successful!
- anonymousDan 7y agoCloud computing (SGX).
- baybal2 7y agoGiven the presence of 4k web-dls (original, not reencoded content,) somebody must have the key, or they must have managed to pwn the DRM on an even deeper level, like tapping the memory (which is even worse.) Another possibility is still a source leak, where 4k content gets lifted off Netflixes own internal content storage.
- jandrese 7y agoOr a simple HDMI defeat and re-encode. It only takes one guy to put it out on the net. DRM is an inherently flawed concept.
- deleted 7y ago[deleted]
- sounds 7y agoThe content is watermarked by the time it is available on HDMI. The guy who re-encoded it would get a knock on the door.
- kevin_thibedeau 7y agoXOR frames captured via two different accounts.
- wizzwizz4 7y agoWouldn't you need three? Or, better still, do a bitwise 3 of 5 / integer median on the pixel values.
- herogreen 7y agoExcept if the watermark is terribly designed, that will not work. There is a lot of information that you can hide from the eye in a video.
- effie 7y agoWhat would that accomplish? If you want to exclude differences, use AND.
- mschuster91 7y agoNo. HDMI/HDCP does not do watermarking or any other modification to content. Cinema DCP packages, however, do - it's either watermarked at the DCP distributor or in the decryption module, but that stuff is out of reach for most warez crews.
- holtalanm 7y agowhat about drive encryption? I'm a little un-versed in hardware related to security, but my understanding of the article was that, given the ability to essentially MitM the TPM, anyone could unencrypt the contents of an encrypted drive, potentially even remotely. if so, that is definitely not a good thing.
- Karunamon 7y agoThe problem with drive encryption at the mainboard level is that it comes with a free side order of vendor lock-in. Apple is a good example here. You can't even touch the internal storage whether you want it encrypted or not, because all access to the onboard storage is gated by their black box security processor. I'd rather just forego the silicon and do it all in software, since there's no way to ensure that the OEMs aren't being bastards. Another reason is that the hardware vendor is in a great, centralized position to be backdoored either by hackers or the bad guys with badges.
- Avamander 7y agoRemote attestation is often the only way to do secure computing on platforms with unknown security. For example things like i-voting would immensely benefit from a secure, anti-tamper computing environment. DRM is another thing however, yes.
- mindslight 7y agoIndividuals being able to choose their operating system when accessing bank websites, and being able to keep secrets to themselves, has much more bearing on every day life than "internet voting". Also note that voting etc could easily be implemented with smart cards (eg SIMs, credit card chips, etc). These are still trusted computing, but are at least limited in scope. Top-down control has no place in general CPUs if we wish to remain an open society.
- M2Ys4U 7y agoVoting using computers is such a terrible idea even in principal that a trust breach like this is irrelevant.
- justincredible 7y agoCan you explain why it's a terrible idea in principle? That is, assuming uncrackable software with foolproof authentication, why is it a terrible idea?
- Avamander 7y agoI find the potential lack of voter supression would be worth exploring the field. I mean, I can see US's terrible governmental IT systems and where the scepticism comes from, but I think it/IT could be done well.
- jnwatson 7y agoI, too, prefer not to know when my box has been blue pilled. Remote attestation is required for many privacy-preserving activities. It isn't just DRM.
- mindslight 7y agoI prefer my box to not be blue-pilled, rather than merely knowing if it has been double blue-pilled. I didn't say it was just DRM. Remote attestation creates a vulnerability whereby remote entities demand that you attest to running a software environment that they control. It's possible to do boot verification and attestation without baking in privileged manufacturer keys. If the attestation key were generated and installed by the owner, they could prove everything to themselves remotely, without being forced to prove anything to hostile parties. If this were the case here, I wouldn't be cheering.
- pb82 7y agoDo you mean Coreboot? Because as far as i know Libreboot still only supports Core2 era hardware. Ivy Bridge would be a huge upgrade in comparison.
- mindslight 7y agoOops, yes. What I actually meant is blob-cleaned coreboot (ie Thinkpad X230). FWIW Libreboot proper does run on IvyBridge-era Opteron 6300.
- floatboth 7y agoThe blobs you have to include in Coreboot for modern CPUs don't have much to do with technical restrictions. A pwnage of the ME does not do the reverse-engineering-and-rewriting effort on the FSP for you.
- sounds 7y agoIntel claims they were already aware of this vulnerability in CVE-2019-0090. ptsecurity believes there is more work to do here though. To me it sounds like Intel is not thrilled with ptsecurity's work, and may not be awarding ptsecurity a bounty or recognition for this. But that's just my two cents. ------>8------ quoting from the article ------>8------ We should point out that when our specialists contacted Intel PSIRT to report the vulnerability, Intel said the company was already aware of it (CVE-2019-0090). Intel understands they cannot fix the vulnerability in the ROM of existing hardware. So they are trying to block all possible exploitation vectors. The patch for CVE-2019-0090 addresses only one potential attack vector, involving the Integrated Sensors Hub (ISH). We think there might be many ways to exploit this vulnerability in ROM. Some of them might require local access; others need physical access. As a sneak peek, here are a few words about the vulnerability itself: 1. The vulnerability is present in both hardware and the firmware of the boot ROM. Most of the IOMMU mechanisms of MISA (Minute IA System Agent) providing access to SRAM (static memory) of Intel CSME for external DMA agents are disabled by default. We discovered this mistake by simply reading the documentation, as unimpressive as that may sound. 2. Intel CSME firmware in the boot ROM first initializes the page directory and starts page translation. IOMMU activates only later. Therefore, there is a period when SRAM is susceptible to external DMA writes (from DMA to CSME, not to the processor main memory), and initialized page tables for Intel CSME are already in the SRAM. 3. MISA IOMMU parameters are reset when Intel CSME is reset. After Intel CSME is reset, it again starts execution with the boot ROM. Therefore, any platform device capable of performing DMA to Intel CSME static memory and resetting Intel CSME (or simply waiting for Intel CSME to come out of sleep mode) can modify system tables for Intel CSME pages, thereby seizing execution flow. ------>8------ quoting from the article ------>8------
- amluto 7y ago> Intel CSME firmware also implements the TPM software module, which allows storing encryption keys without needing an additional TPM chip—and many computers do not have such chips. And that was the real error. The TPM should be a TPM. It could be on die, but it should be an entirely isolated device with its own RAM, no DMA, no modules, and no other funny business.
- deleted 7y ago[deleted]
- lima 7y agoInternal TPM is more secure for attestation. You can MitM the LPC bus with an external TPM, faking PCRs.
- lxgr 7y agoThat sure is an interesting decision, given that other big players (Apple with the Secure Enclave, Google with Titan) have been moving into the opposite direction.
- indolering 7y agoYeah, but that would cost money! Intel hasn't suffered major economic repercussions for any of their other security issues ... so why bother? At ~400 million chips/year, a $0.10 increase in component cost would translate to $40 million in lost profits.
- londons_explore 7y agoTL;DR: There is a tiny window during bootup when any hardware can DMA code or keys in/out of RAM. That allows complete compromise of all protections offered by the chipset, including secure boot, TPM key storage, etc. It is not fixable via a firmware update. The researchers have not demonstrated a complete end to end attack, but it seems likely one exists. While this could likely be pulled off easily as a local attack, in some cases it might also be possible to do as a remote attack depending on being able to program other hardware devices to exploit the flaw during a reboot.
- deleted 7y ago[deleted]
- blendergeek 7y agoIt looks like finally users may have complete control over their Intel computers without Intel having the final say. I, for one, am quite happy about this.
- shiblukhan 7y ago"the scenario that they feared most", yet the scenario everyone was sure would happen.
- jjoonathan 7y agoI wasn't sure it would happen, but I'm sure happy it has!
- ghostpepper 7y agoDoes this announcement mean it's finally possible to run FOSS firmware like Coreboot on modern Intel hardware? If so, this is a huge finding
- gentleman11 7y agoLooks like it could make it easier to get around DRM also?
- zelphirkalt 7y agoThat's what I am wondering too! Perhaps Libreboot can make progress and we could have completely free systems with more up to date hardware after all? That would be so great.
- wmf 7y agoCoreboot already runs on modern Intel hardware. This vulnerability doesn't eliminate the blobs or the need for the ME to initialize hardware before Coreboot runs if that's what you're thinking of.
- ghostpepper 7y ago
- paxswill 7y agoI'm curious if Apple's work on hardening their secure boot process on x86 affects this at all? For this unaware, this [0] video covers it over about seven minutes. Basically they claim to be enabling the IOMMU with a basic deny everything policy so that when the changeover to executing from RAM occurs and PCIe devices are brought up the IOMMU is able to deny possible malicious access to the firmware image. It sounds from the end of the article that there are separate DMA/IOMMU processes for the CSME, but I'm not familiar enough with stuff this far down to know for certain. https://youtu.be/3byNNUReyvE?t=124 https://youtu.be/3byNNUReyvE?t=124
- morpheuskafka 7y agoIt is their proprietary T2 chip that controls things like FileVault (fulldisk encryption) and Touch ID. So a vulnerability on Mac would not be nearly as severe as on Windows, where the this can eventually compromise the fTMP used for BitLocker encryption (dTMPs wouldn't be vulnerable, but their integrity protection can be bypassed by messing with their physical connections to the CPU). The T2 chip has its own Secure Enclave and immutable BootROM, and it supposedly verifies the Intel UEFI ROM before it is allowed to load, and then the CPU reads this from the T2 over SPI. So it would seem that this boot process is not weakened by a compromise of the Intel key, as only Apple can sign UEFI updates to be loaded onto the T2 chip. Source: https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/apple-platform-security-guide.pdf https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app... (long PDF)
- osy 7y agoRelated: I’ve wrote a (maybe not 100% accurate) low level summary of the x86 secure boot model here a while ago https://osy.gitbook.io/hac-mini-guide/details/secure-boot https://osy.gitbook.io/hac-mini-guide/details/secure-boot
- baybal2 7y agoAs I pointed before, lifting any "secret" key of any chip is quite trivial to a semiconductor professional. It's part of a job of an IC engineer to be able to tap arbitrary metal layer on the device with microprobes to "debug" it, and this is something quite routine in a process of a microchip development. Any such measures can only deter people without access to an IC development lab.
- DoofusOfDeath 7y agoCool! Out of curiosity, do these debugging tools keep pace with the recent process shrinks? I would imagine it's really hard to connect a logic probe to, for example, a processor built on TSMC's 7nm process.
- sounds 7y agoThe metal layer interconnects usually are _not_ that small. I can't share the exact specs for TSMC's 7nm process but here's an example that should give you some idea: https://web.stanford.edu/class/ee311/NOTES/Interconnect%20Scaling.pdf https://web.stanford.edu/class/ee311/NOTES/Interconnect%20Sc...
- baybal2 7y agoGate size on 7nm processes is still 30nm, and even the lowermost M0 metal is way, way bigger. Even if doing so requires destroying, and reconstructing some tracks around the probe, 7nm shouldn't be much different from how it was done back a decade ago.
- chinhodado 7y agoNot sure if I understand correctly, but are you saying secrets kept in hardware like console encryption keys (PS4 etc.) can be trivially extracted with the right tool?
- baybal2 7y agoYes, but signing can't be defeated unless you modify the IC itself.
- vzaliva 7y agoIn my opinion, critical code like this must be formally verified.
- vardump 7y agoNot sure how formal verification would have helped here. DMA access is allowed at boot up, game over.
- AnimalMuppet 7y agoIn principle, you could consider validating the system, not just the software. It might reveal such a gap. Note well: I am not claiming that the tools exist currently to do this.
- qubex 7y agoSome time ago I had considered (and rejected, due to a bad review due to a freak bad sample, apparently) equipping my unit with POWER9 systems from Talos. I am now reconsidering the idea. https://www.raptorcs.com/TALOSII/ https://www.raptorcs.com/TALOSII/
- guerrilla 7y agoFor people who know nothing about this and want a tl;dr in video form: https://www.youtube.com/watch?v=5syd5HmDdGU https://www.youtube.com/watch?v=5syd5HmDdGU
- qubex 7y agoAnd for anybody interested in the previous Hacker News discussion on the topic: https://news.ycombinator.com/item?id=14956257 https://news.ycombinator.com/item?id=14956257
- shiblukhan 7y agoA vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME). A reference to the specific vulnerability would be nice. CVE? Conference presentation? El Reg? Sketchy blogspam? Maybe I've been living under a rock, but it would still help the reader out.
- notpeter 7y agoThe article mentions CVE-2019-0090 and Intel acknowledges the author (Mark Ermolov of Positive Technologies) in their advisory. You haven't been living under a rock, this is a primary source and the first public suggestion of the grave severity of the vulnerability. "CVE-2019-0090 was initially found externally by an Intel partner and subsequently reported by Positive Technologies researchers. Intel would like to thank Mark Ermolov, Dmitry Sklyarov and Maxim Goryachy from Positive Technologies for reporting this issue." https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0090 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0090 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00213.html https://www.intel.com/content/www/us/en/security-center/advi...
- dmitrygr 7y agoIt is telling that not a single comment here sees this as a bad thing. Maybe Intel should take the hint. Users want to own their hardware!
- wmf 7y agoPeople commenting on this thread are a very self-selected group.
- dmitrygr 7y agoa potentially fair point. Please provide one or two reasons as to how this development is not absolutely great for users
- lxgr 7y agoSee my comment further down. Not all trusted computing is user-hostile. Don't confuse the technology with its (primary early) applications.
- sounds 7y agoTrusted computing is such an ambiguous term. Intel alone controls the certificate chain for the CPU I own? I don't trust it, and it's user-hostile. Users won't know that it's because of Intel that, for instance, their legacy apps don't run any more. Or their Mac's NVMe drive cannot be recovered (though, yes, this is Apple's Trusted Computing chip, not Intel's). I take it as the tech community's responsibility to clearly point out who violated their trust on this one. Trusted computing could be "not user-hostile," or perhaps that's what "user-friendly" means? But to not be user-hostile the certificate chain must be surrendered at point of sale. It's ironic that sysadmins for large corporations _are_ enabled by Intel's management tools, and _are_ aware of the purpose of these trusted computing tools. But end users _are_ _not_ enabled, _are_ _not_ aware, and are thus treated hostilely by Intel and cannot do the things they absolutely need to do with their own PC.
- 7y ago
- holtalanm 7y agoim guessing not, but does this affect AMD CPUs/chipsets?
- morpheuskafka 7y agoNo. The ultimate potential of this attack is the complete compromise of all Intel signing authorities over affected models. Naturally, that signing key does not have any value on AMD systems, nor can this vulnerability in itself be used on them.
- holtalanm 7y agoI figured as much. thanks!
- morpheuskafka 7y agoupdate - it has now been confirmed that the T2 chip is vulnerable to the checkm8 vulnerability which made version-agnostic jailbreaks available for all iOS devices up to A11 CPUs. So, it would seem that Apple is only slightly in a better position. AFAIK, the Secure Enclave stores the actual disk encryption keys and Touch ID data, so that should be safe. But the secure boot validation, firmware password, startup security policy, etc. can now be bypassed (once a full exploit to do so is written). Also, it is quite possible that the Intel ME and UEFI firmware validation can be bypassed by simply disabling that part of the T2's bridgeOS code.
- monocasa 7y agoIN addition to what's been said below, the early boot process is totally different on AMD. They've got a little ARM core called the PSP babysitting the main core complex(es).
- wmf 7y agoThat's not that different. The PSP is basically AMD's ME.
- unnouinceput 7y agoFor my upgrade, due to having lesser vulnerabilities, I decided this year (after 20 years of only using Intel) to go with AMD. Had my doubts, but this article made me decide it's time to go AMD route.
- lxgr 7y agoI have not looked into AMDs efforts in this area recently: Is there an AMD-equivalent to, for example, Intel TXT? If so, is it actually more secure, or has it simply not been scrutinized as much as Intel's version by security researchers?
- Reelin 7y agoUnfortunately, AMD has PSP. [1] ARM has TrustZone. [2] You'd have to get a system with a POWER9 [3] chip, such as the Talos II from Raptor. [4] That has quite a price tag though, on account of not being mainstream. [1] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.wikipedia.org/wiki/AMD_Platform_Security_Processo... [2] https://en.wikipedia.org/wiki/ARM_architecture#Security_extensions https://en.wikipedia.org/wiki/ARM_architecture#Security_exte... [3] https://en.wikipedia.org/wiki/POWER9 https://en.wikipedia.org/wiki/POWER9 [4] https://www.raptorcs.com/TALOSII https://www.raptorcs.com/TALOSII
- dmitrygr 7y agoIt should be noted that ME and PSP are both (a) a technology to implement a super-root over your entire system and (b) an implementation of said super-root environment that you do not control and cannot out out of. Trust Zone is only (a). Trust zone just defines a technology that may be used to implement such a thing, but it itself is harmless and does not actually do anything. There are chips you can buy that do not come with any TrustZone code, and you may write your own to put in there, if you so wish
- unnouinceput 7y agoThank you for these links, I'll look into them. And yeah, I do plan my upgrade to be quite expensive. For me, the work horse, has to be a beast to support virtualization, gaming and quite some editing - so in the end the price tag is not my main criteria.
- einpoklum 7y agoThe "trust" here is a complete misnomer. "Trusted computing" should be called "traitorous computing", where your computer has a module which might be controlled by (fundamentally antagonistic) remote third-parties. _They_ can trust your system to _betray_ you in their favor. Traitorous computing should not exist and a pox be upon the heads of everyone who let such modules make it into our computers.
- lxgr 7y agoThis assumes the absence of a sandbox. Trusted computing can happen with our without a sandbox, much like "regular" computing. If your system is running unsandboxed, untrusted third party code, that's pretty bad, regardless of the presence or absence of a trusted platform. As an example: FLOSS systems are definitely capable of running malware. On the other hand, a reproducible build of open source software might well be what runs in (and relies on the attestation provided by) a trusted computing platform. I do see one practical concern with integrating trusted computing on a general purpose computer: If an implementation depends mostly on security through obscurity to achieve the desired attestation capabilities, this makes it much harder to audit it for vulnerabilities or backdoors. But I don't see how that is a fundamental property of a trusted computing system.
- sounds 7y agoA reproducible build is very different than cryptographically attesting the binary state of especially the kernel. If I can't produce a binary with the same "reproducible state" as the one you had because your _kernel_ was one that I don't run (especially because maybe I don't _want_ to run it), that destroys all the value of a reproducible build. A reproducible build should not _undermine_ software freedoms, specifically those protected by a Free Software license. But trusted computing always undermines software freedoms: that's by design. It's intentional. It's all about locking 100% of the users into a single monoculture where there is minimal freedom. And that's fine in a managed IT environment such as a corporation. But it's not ok when I buy hardware and the manufacturer refuses to hand over the certificate chain to me.
- 7y ago
- pjf 7y agoCan someone please explain the implications in layman terms?
- stevefan1999 7y agoThere is no trust. Apple used to trust their phone with bootrom. And guess what, a buffer overflow and UaE bug called checkm8 was eventually found and is almost universal to all iDevices
- thatiscool 7y agoBACKDOOR 5 years of Intel CPUs and chipsets https://arstechnica.com/information-technology/2020/03/5-years-of-intel-cpus-and-chipsets-have-a-concerning-flaw-thats-unfixable/ https://arstechnica.com/information-technology/2020/03/5-yea...
- fps_doug 7y agoFrom a practical standpoint, how easy would it now be to e.g. create a "signed" bootloader (say, custom GRUB) that will boot on those affected chips with the default secure boot configuration? Or is this just for information exfiltration?
- bogomipz 7y agoThe post states: >"This vulnerability jeopardizes everything Intel has done to build the root of trust and lay a solid security foundation on the company's platforms. The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets." Could someone explain what a Mask ROM is? This is the first I've heard of this. How is it different that a regular ROM?
- zozbot234 7y agoIt's not different. It's meant to disambiguate "regular" ROM from EEPROM or Flash firmware like the sorts of "roms" you would download for a mobile device.
- consp 7y agoA Mask ROM is read only memory which is build from the silicon mask which in very simplistic terms is the image of the chips to be printed to make the cpu. These 'images' are called masks, giving the Mask ROM. These rom's are cheap, simple and small but can in no way be changed since that would require changing the chip. Sometimes it includes also non masked rom which cannot be altered. Regular rom can be many things, rewritable like (E)EPROM or flash, disks like cd(-rom) or chips like PROM (which is write once, read many).