Good thing Apple is moving to M1; no more of that Intel crap. and stick with AMD for Linux.
do you think the M1 doesn't have security bugs?
Apple's M1 too supports Spectre.
>The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.
I can't get with justifying one serious security problem using another. Attackers increasingly combine local privilege escalations to move laterally, but only need one RCE to get in.
Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ab…
I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”.
The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There are things that even root can’t do even though “hey if you have root the game is lost”. The point of the game is to never lose even in very adverse environments.
This would still break SGX/remote attestation, no? The chip can correctly say it's running some piece of assembly but if "ret" has been redefined to do whatever I want...
I would love ability to redefine call/ret to profile an app without compiler generate diff code.
Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ab…
I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”. The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There…
The assumption on Intel is that there are no barriers once you're in the ME. You can't defend against a hostile ME. The security model is already violated. Maybe there should be a barrier between the ME and the CPU, but as can be seen here Intel feel that the ME should be in a position to put the CPU in debug mode so shrug.
The followup tweet indicates that the CPU has to be in an unlocked state before this is possible, which on a typical system requires there to be a Management Engine vulnerability first. Given what we currently know, this is going to be interesting for people interested in researching the behaviour and security of Intel CPUs and might well lead to discovery of security issues in future, but in itself I don't think thi…
Plot twist: there’s been a few ME vulnerabilities. And who knows what other purposeful ME backdoors there may or may not be.
No, no! You've got it wrong. It's a backdoor when Huawei does it. When Intel does it, it's just a vulnerability/oversight/mistake. /s
Plot twist: there’s been a few ME vulnerabilities. And who knows what other purposeful ME backdoors there may or may not be.
Sure, which is why this is useful to researchers. But the access someone needs to your system in order to exploit the ME vulnerabilities is sufficiently extreme that if someone achieves it you probably have other things to worry about.
There are more productive ways to view the probabilities of security. Low probability may imply low risk but is not guaranteed to imply low priority to fix.
Subtly change the RNG implementation so there’s a predictability only you know.
That’s one of the reasons why operating systems provide a proper CPRNG instead of trusting RDRAND.
How would an OS seed an RNG in the cloud? How would you seed an RNG on a headless server in a VM? What about when that VM is copied, possibly while running, in order to duplicate server functionality? There are vulnerabilities and threats here that your comment does not take into account.
The previous publicly known mechanism required signed updates. This mechanism allows anyone to twiddle the bits.
> This mechanism allows anyone to twiddle the bits. This remained unclear to me. Other comments say the CPU needs to be in red unlocked state, whatever that is. The screenshot shows UEFI. So one could guess the CPU is in such state before the operating system gets loaded. But the operating system typically loads a microcode update, after that the CPU should no longer be in unlocked state. So for "everyone can fiddle…
By "anyone", I mean not Intel. Previously only Intel had the private key for signed microcode updates, and no one else even knew the format of microcode. Even with control of the machine you couldn't play with the microcode or know what it did. This allows read/write access for researchers.
Back in the day they were though. Full schematics, microcode listings, and a flow chart to understand the microcode.
Can you give an example of a processor whose microcode was publicly documented? (Barely-public documents like patent filings don't count.)
Pretty much every Dec and IBM machine up until the 80s.
Bitsavers has the documentation for the PDP-11/40 I used to have here. http://www.bitsavers.org/pdf/dec/pdp11/1140/. It includes microcode listings both assembled and as flow charts. My PDP-11 had actually been modified before I got it with the microcode ROMs in ZIF sockets, as someone had been writing their own microcode.