
New flaw in Intel chips lets attackers slip their own data into secure enclave - jbegley
https://techcrunch.com/2020/03/10/new-flaw-in-intel-chips-lets-attackers-slip-their-own-data-into-secure-enclave/
======
the_duke
Could we change the link to the source?

[https://lviattack.eu](https://lviattack.eu)

It has a good explanation, videos and FAQ.

(the Techcrunch post is just horrible)

~~~
TekMol
I often think Techcrunch should be banned on HN.

When I click on a Techrunch link, it tries to redirect me to some tracking url
on advertising.com. That would probably collect data about me, set cookies and
send me back to Techcrunch. Since I do not allow that, I cannot read
Techcrunch articles at all.

Lets see what others think. I made an Ask HN from this:

[https://news.ycombinator.com/item?id=22539255](https://news.ycombinator.com/item?id=22539255)

~~~
bobobob420
How bout we first ban articles behind paywalls?

~~~
afiori
I would not know how to feel about a community that both hates advertising and
paywalls, and that also routinely causes DDoS-like spikes of traffic on
smaller sites.

~~~
ethbro
"When do we want it?" "Now!" "How much will we pay?" "Nothing!"

~~~
afiori
To be clear I admit I am in that camp, but at the very least I oppose
circumventing paywalls.

------
nneonneo
There was a CTF this weekend (UTCTF) featuring a task to exploit a program
running in a secure SGX enclave. As part of solving that task I spent some
time looking into the design of SGX, and I gotta say it doesn’t sound
promising.

The basic idea is to be able to run code on an Intel processor that cannot be
tampered with or even examined by any other part of the system, including the
OS, hypervisors, etc. The entire code and data segment of this program runs in
its own world, the “secure enclave”, in user mode (ring 3). The attack model
is that every piece of software executing on the CPU (user code, OS code,
hypervisors) and every bit of hardware outside the CPU (network interfaces,
hardware buses, memory interfaces) could be compromised and attempting to leak
data from your Secure Enclave, and the enclave code/data should still remain
tamper proof and unreadable. The SGX implementation even includes an
attestation system, using a trusted server operated by Intel, which will
attempt to verify that the CPU itself is not compromised.

The entire thing depends on a lot of cryptography. Sealing keys to encrypt
data that will be persisted to disk from the enclave. Memory protection keys
to encrypt everything going to RAM. Page encryption keys to encrypt any memory
that the OS tries to page out. Attestation keys to cryptographically verify
that the CPU measured itself to be OK. Cryptographic signatures to validate
the initial enclave code and data to protect against tampering of the initial
state. Session keys to protect the enclave’s communication with whatever
application server is providing the code/data for the enclave’s computation.
The OS and even the ring 3 application hosting the enclave have a MITM
position on absolutely everything the enclave does, so the disclosure of just
one of these keys breaks the security of the whole system.

I am not surprised at all that SGX wound up being vulnerable to a low-level
CPU attack. The attack surface is way too big and there are too many points of
failure.

~~~
warkdarrior
> I am not surprised at all that SGX wound up being vulnerable to a low-level
> CPU attack.

Most secure systems assume that the CPU is functioning correctly. It is not
clear that you can do anything securely if the CPU is buggy.

~~~
ngneer
What is correctly? You have to understand that SGX was built on an existing
infrastructure, without rebuilding the chip. Intel architects ignored side
channels for years. So the security specification was being met, except it had
ignored a crucial threat. Small comfort. My point is that "correctly" for
security can only be defined in the context of a threat model. If the model is
incomplete, then you are exposed. I am not aware of a complete threat model
for TEE design. And the reason is clear. The threats develop over time,
springing into existence as an emergent property of complex designs rewarded
by a market that is not keen on incentivizing secure design.

~~~
warkdarrior
The Intel instruction specification details which access control checks are
performed when executing instructions. In most of the speculative execution
bugs, the Intel implementors decided to skip those checks for performance
reasons. Note that this is a implementation correctness issue, not a security
issue (which is defined only for a threat model).

The SGX design was created on top of the instruction specification, not on top
of specific buggy processors. Hence the vulnerability! The threat model for
SGX did not consider incorrect processor implementation.

~~~
ngneer
I think we are on the same page. I was referring to the specific SGX
implementation that relied on existing processor infrastructure, and you are
making the argument that no system can be secure that is built on a faulty
implementation. No amount of threat modeling will help you if an
implementation does not perform its function. All threat models are built
under the implicit assumption that the implementation they will help derive
will be correct. The threat model helps to answer the question of which
function should be realized. Whether that function is in fact realized or not
is a different matter. With the speculative execution bugs, the function being
realized unintentionally deviated from the specified access checks.

------
strstr
Intel continues to get beaten up by their decision to defer access checks in
speculation. Meltdown, L1TF, and now LVI-stale-data are all rooted in one
mistake. Fortunately, the silicon fix for Meltdown appears to mitigate these
issues ("RDCL_NO"). But it also introduces LVI-NULL (which is admittedly more
restricted, but still problematic).

The Intel deep dive [0] is a pretty solid addition to the original paper [1].

It looks like Ice Lake processors are going to be the first ones that are not
affected [2]. Based on the deep dive, it sounds like these still aren't
perfect (they don't completely avoid forwarding values to dependent
instructions from faulting loads). They instead exhibit some behavior they
call "zero-at-ret", which Intel says is not expoitable in practice.

Intel does not explicitly say Ice Lake is zero-at-ret, but reading between the
lines this seems to be the case ("parts generally exhibiting Zero-at-ret
behavior... will be documented as 'not affected'.") Only Ice Lake is listed as
not affected, so they likely would not put this caveat in there if this did
not apply to Ice Lake.

[0] [https://software.intel.com/security-software-
guidance/insigh...](https://software.intel.com/security-software-
guidance/insights/deep-dive-load-value-injection#injectnonzerodata) [1]
[https://lviattack.eu/lvi.pdf](https://lviattack.eu/lvi.pdf) [2]
[https://software.intel.com/security-software-
guidance/insigh...](https://software.intel.com/security-software-
guidance/insights/processors-affected-load-value-injection)

~~~
zerkten
This is a bit of a naive question, but do the Ice Lake mitigations address any
of the performance impact from the software updates that address earlier
issues?

~~~
strstr
Depending on your risk tolerance, mostly yes:

1) You can disable kPTI without opening the door to Meltdown (which let you
directly read kernel memory as usermode).

2) You can re-enable hyperthreading while allowing virtualization (VMs)
without obvious issues (l1tf used to allow users to read kernel memory through
VMs). I don't know which, if any, distros do this, but it's the prudent thing
to do if you care deeply about security. (Linux may have the scheduling fixes
by now that also fix this, but I honestly haven't followed them, and they
didn't have them in like November when I last checked.)

Others:

1) I'm honestly unsure if you can recompile kernels without "retpoline", but
it's not a super big perf impact anyway, at least not compared to those two
mitigations.

2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how
bad the perf impact of their mitigations are, or how bad their impact is.

3) There's some TSX issues, which I'm also unfamiliar with, also probably
don't matter much perf wise.

If you are paranoid, or have a multi-tenant machine, I'd still leave these on
(and I'd particularly leave hyper-threading off, even on AMD), since we
haven't stopped seeing new side channels. Hyper-threading is basically asking
for problems on multi-tenant machines.

Honestly, if your machine is not multi-tenant, and you can tolerate some risk
(e.g. you don't care if anyone sitting at your machine can read all of RAM,
including potential malware), I'd just disable all this stuff. Unless you've
run into particular hiccups (you compile linux kernels all day and you need
the extra cores), I wouldn't do it.

~~~
lisnake
regarding 2): latest betas of ChromeOS disable hyperthreading if one enables
builtin Linux VM. Seems overzealous to me, as the OS is not multi-tenant
usually

~~~
saagarjha
I thought that Chrome OS disabled this by default, as MDS crosses privileges
boundaries in addition to the VM/host one?

~~~
lisnake
By default on my ChromeOS 81 beta HyperThreading is getting disabled only
after you start the linux vm. HT stays disabled until you reboot. There is
scheduler flag in chrome://flags, but IME it does nothing

------
bayindirh
I'm considering to upgrade my primary computer this summer and considering an
AMD system. Following is my thought process:

\- Maybe I should buy an Intel system again because of the performance
counters and other nice things.

 _Another Intel attack surfaces_

\- Yep, I shall go AMD this time...

~~~
mynameisvlad
[https://www.techspot.com/news/84309-amd-cpus-vulnerable-
seve...](https://www.techspot.com/news/84309-amd-cpus-vulnerable-severe-new-
side-channel-attack.html)

From 2 days ago, in case you weren't aware.

~~~
temac
The "new" AMD attack depends on lack of already existing spectre mitigations.
If I understand correctly, this one is a real new one that works against a
correctly patched system.

~~~
paulmd
the new AMD attack effectively breaks KASLR (the "metadata" that the attack
reveals is page table layouts) and AMD has announced they're not going to
patch it.

itself it's not a problem but if you pair it with something else it destroys a
major line of defense against that something else.

AMD is still architecturally vulnerable to some variants of SPECTRE, they just
consider it "hard to exploit", but they do recommend you run KASLR to harden
against it. Well, so much for that.

~~~
AnthonyMouse
Wasn't KASLR (really KPTI, originally a KASLR hardening technique) a
mitigation against Meltdown, which AMD isn't vulnerable to, rather than
Spectre?

~~~
chousuke
As far as I understand it, KASLR is a general hardening technique to shuffle
the kernel address space so that it's harder for attackers to use
vulnerabilities successfully to attack the kernel. I don't think it's
specifically for Meltdown.

~~~
AnthonyMouse
ASLR is a general technique to try to prevent memory corruption
vulnerabilities from being turned into code execution when the attacker can
determine the location of already-existing code in memory and use the memory
corruption to cause program flow to jump to it.

It works pretty well against remote code execution because it's hard for an
attacker who can't already execute arbitrary code on your machine to determine
the address space layout. In principle it can also be used to protect the
kernel against user processes, but that's much harder because a process that
can already execute arbitrary user code on the same machine can use a variety
of side channel attacks like this to determine the kernel address space
layout.

KPTI was originally proposed to close some of those side channels, but it's
kind of expensive. It only got enabled by default (on Intel) because it also
mitigates Meltdown, which is a much worse problem. It also doesn't handle all
of the side channels:

[http://www.cs.ucr.edu/~nael/pubs/micro16.pdf](http://www.cs.ucr.edu/~nael/pubs/micro16.pdf)

Meanwhile, if some kernel code is vulnerable to _Spectre_ (i.e. the Spectre
mitigations are not implemented properly), it could allow the attacker to read
arbitrary kernel memory. That is obviously very bad, but the ability to read
arbitrary kernel memory implies that the attacker can already determine the
kernel address space layout, so I'm not sure how KASLR would be helpful in
mitigating that.

------
roca
The headline and a lot of the writeup is very confusing. This attack does not
let you modify _architectural_ state, only speculative state. The headlines
sound like you can corrupt the values that the program actually ends up using,
but you can't. You can only modify speculative state and use those changes to
get more control over what data is leaked through side channels.

------
sf_rob
[Ignorant tangent] Is core hardware more exploited these days or are
vulnerabilities just more reported in tech news? I'd assume the former, but
I'm not a hardware person. If so is this just due to increasing
complexity/optimization going on in chip design or better tooling/methods of
exploitation?

~~~
akiselev
It's probably a bit of both. Intel started implementing speculative execution
decades ago but the first exploits like Specter/Meltdown weren't published
until a few years ago so that alone is strong evidence that there might be
ancient attack vectors that we haven't even considered yet.

On the other hand, interest in this topic among the public has definitely
grown since branding departments started getting their hands on the exploits
and Bloomberg published that sensationalist Micro story so it's a self
reinforcing cycle.

~~~
WrtCdEvrydy
Interestingly, there was a 1998 paper about speculative execution that
basically outlined all of Spectre/Meltdown.

~~~
akga
Sounds interesting. Do you have a link to it?

~~~
Kurakuan
I'm not sure if there was another paper in '98, but this one in 1995 may be
the one being referenced:
[https://web.archive.org/web/20180506083456/https://pdfs.sema...](https://web.archive.org/web/20180506083456/https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf)

------
driverdan
An 11 month embargo for a widespread security flaw like this is unacceptable.
Researchers need to refuse to comply with this. 90 days by default and an
extra 90 on request is more than enough. If they can't get their shit together
in six months they won't be able to in 12.

~~~
3pt14159
We need an industry standard shut-up-and-pay-me system. First 90 days free.
Then some sort of quadratic formula for every month after that.

~~~
yjftsjthsd-h
I'd prefer 90 days and then unconditional publishing. I grant that making
companies' desire for silence actually affect the bottom line has appeal, but
1. some companies have deep pockets, and 2. I'm not ethically comfortable with
anything of the form "pay me to not disclose this bad thing".

------
userbinator
This is a good thing when the secure enclave is user-hostile and the attacker
is the user.

Although it is unlikely, I remain wishful that this continued barrage of side-
channel attacks will usher in the return of the era where people actually own
their hardware 100%, rely on processor protections as defense against mistakes
and not malice --- as was the original intent of 286 protected mode --- and
understand that attempting to isolate trusted and untrusted code on the same
hardware is ultimately futile.

~~~
sterlind
Cloud providers already offer full blades, though they're quite expensive. I
could imagine vendors commissioning custom hardware that electrically isolates
CPU cores and caches, like a sort of hyper MMU. The challenge lies in
combining these "nodelets" together dynamically to make larger VM skus when
needed without compromising security when they're supposed to be isolated.
Plus you'd have to design a ton of new hardware which isn't cheap.

Clouds will probably stick with traditional server blades until transient
attacks are found which simply can't be defeated, even with new silicon. Even
replacing entire DCs worth of blades would be cheaper than reworking the
fundamental hardware.

(I have no inside knowledge, my opinions are my own.)

------
guerrilla
If anyone's interested, I recently started a youtube playlist collecting talks
on exploiting and securing x86 hardware and firmware:
[https://m.youtube.com/playlist?list=PL7Jsn37GlvSwYGaetkukERO...](https://m.youtube.com/playlist?list=PL7Jsn37GlvSwYGaetkukEROk9Ew8OUoHj)

Anything I should add?

~~~
Lind5
[https://www.youtube.com/playlist?list=PL4RrBxLcT1nZThUvIFjS0...](https://www.youtube.com/playlist?list=PL4RrBxLcT1nZThUvIFjS0cuR1REb_ZDJJ)

------
d--b
Do all these vulnerabilities mean that manufacturers will have to remove those
optimizations, rendering the cpu slower?

It seems to me that extracting or injecting data that way is very hard to do,
and is likely to return very little information.

Is the tradeoff something like: we should prevent the one in a hundred billion
chance that my cpu leaks a critical password to some intruder one day at the
cost of rendering all my processes 30% slower?

~~~
2J0
Can I restate the go question as "is complexity of the machine effectively
security by obscurity and effective in practice for reliance upon?"

Really how much unnecessary complexity is traversing boundaries we can shut
down or at least gate effectively?

My company has used CICS for this purpose since forever and we're not so much
a legacy that you will think about our architecture in this way if we talked
about it, but CICS is a very rare interface in this era.

~~~
ghaff
We call it serverless now :-) (I'm joking a bit but there are similarities.)

------
popotamonga
I wonder what would happen if a flaw were found that would render an entire
line of expensive CPUs useless.

~~~
metalliqaz
the closest I can think of was the famous floating point error that caused
Intel to recall lots of parts[1]. Even that didn't render the CPUs useless for
most users, only some scientific and business use cases really had problems.

[1]
[https://en.wikipedia.org/wiki/Pentium_FDIV_bug](https://en.wikipedia.org/wiki/Pentium_FDIV_bug)

~~~
alex_free
>Thomas Nicely, a professor of mathematics at Lynchburg College, had written
code to enumerate primes, twin primes, prime triplets, and prime quadruplets.
Nicely noticed some inconsistencies in the calculations on June 13, 1994,
shortly after adding a Pentium system to his group of computers, but was
unable to eliminate other factors (such as programming errors, motherboard
chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the
issue to Intel.

Can you imagine debugging this for that many months only to find out there was
nothing on your end to fix.

~~~
sarah180
I had a similar experience when doing my first serious work in a compiled
language. I found and reported a compiler bug in double-precision division (in
a commercial C compiler). It took me years to stop blaming the compiler for my
bugs.

~~~
snovv_crash
I had the same, an embedded system with GCC 3.something. Managed to get a
toolchain together with 4.something and suddenly our uptime and random
corruption issues disappeared.

------
baybal2
Quite sensational.

I think very few mortals out there use SGX, Intel apparently dropping public
tooling support for it just shows for it.

Biggest scare is coming to DRM users, but even they I think are not much
impressed as insecure trustlets for 845 in the wild already made then to give
up few years ago.

~~~
jokoon
Yes I just don't understand, most big vulnerabilities that make the headlines,
even if they involves a lot of people, the vuln scenario looks it's still
crumbs.

Of course the crumbs of many users can add up to a lot, so it's a still a
concern, it's not really nothing.

Of course what matters is the PR involved, not the actual vuln. Hardware vulns
are pretty bad since they can't be fixed. But still, it still sounds like
worse than it really is.

------
mzs
much better link [https://lviattack.eu/](https://lviattack.eu/)

------
pengaru
also [https://www.zdnet.com/article/intel-cpus-vulnerable-to-
new-l...](https://www.zdnet.com/article/intel-cpus-vulnerable-to-new-lvi-
attacks/)

------
olah_1
Signal is planning on using Intel's SGX enclaves.
[https://signal.org/blog/secure-value-
recovery/](https://signal.org/blog/secure-value-recovery/)

Not sure how much of a risk this plays in that plan, though.

~~~
kijiki
Signal already uses SGX for Contact Discovery, and has for many months.

In all cases, Signal only uses SGX to improve cases where data previously was
stored in plaintext. The idea is to change the required attack from
"compromise signal servers" to "compromise signal servers _and_ compromise
SGX".

~~~
AndrewBissell
OK, but if compromising SGX is pretty easy, that just leaves the servers
(hosted on AWS) for someone to be able to observe and decrypt all Signal
traffic, right?

~~~
v4dok
It is anything but easy. I guess that is why you get downvoted. The fact that
only this academic group was able to come up with these attacks shows the
amount of knowledge you need to have to carry them out.

~~~
AndrewBissell
OK, but how hard is it for a state-backed intelligence agency to come up with
that knowledge? The Vault 7 leaks showed that the CIA has all kinds of very
deep capabilities in this area. I'm not thinking of some random script kiddies
doing this.

~~~
v4dok
Past news should have shown that pretty much nothing is invulnerable from
state-backed intelligence services. I would be more worried about what can
realistically be hacked by random people on the internet.

------
totaldude87
[security noob here]can anyone explain this in layman terms, i.e can these be
exploited remotely, what we can do to protect etc!

In short, who should be worried, a common Windows user, a *nix system admin or
everyone who uses intel chips..

~~~
saagarjha
This vulnerability targets SGX enclaves (although I believe it would affect
all memory loads?), which run code that is meant to be isolated from the rest
of your computer and is probably currently only being used by DRM on your
computer. This is a flaw in your processor and at the moment you probably
cannot do anything to protect against this, although work is being done to
come up with mitigations. Currently, it seems like they’ll be the kind that’ll
slow down your computer.

~~~
redrabbyte
it affects all loads, but for sgx the attacker scenario is that you have
compromised the OS, which makes it significantly easier to create the
conditions (faults/microcode assists) that cause the LVI than if you were just
another userspace program (but it's not impossible there either)

~~~
saagarjha
Though I don't have much knowledge of this area, I'm waiting for someone to
make a PoC exploiting this from JavaScript ;)

------
Lind5
Good background info:New Security Risks Create Need For Stealthy Chips
[https://semiengineering.com/new-security-risks-create-
need-f...](https://semiengineering.com/new-security-risks-create-need-for-
stealthier-chips/) Determining What Really Needs To Be Secured In A Chip
[https://semiengineering.com/determining-what-really-needs-
to...](https://semiengineering.com/determining-what-really-needs-to-be-
secured-in-a-chip/)

------
gjsman-1000
I'm not a technical expert, but check out the guy who made the fake movie
trailer's channel. He has written parody songs for almost all of the Intel
execution attacks there are, which is quite hilarious.

~~~
redrabbyte
he happens to be an author/co-author of all of those papers ;)

------
MauranKilom
I understand how they turn incorrect store forwarding into an attack, but can
somebody summarize what causes the store forwarding to be wrong in the first
place?

~~~
redrabbyte
short version: only the lower bits of an address are compared at first,
because the rest might take a while to resolve so the cpu can speculate that
the rest is gonna match as well and start to work with the data, and then
either keep it or throw it away once the rest of the address is known

------
aSplash0fDerp
Would buffered connectivity mitigate what is becoming a Swiss cheese
infrastructure of hardware (security holes in everything)?

Direct connectivity (on Internet 1.0) seems to be playing with fire nowadays.

Security admins probably love the fact that they are guarding their assets
from unknown threats/vulnerabilities that major manufactures have included in
their products.

~~~
saagarjha
What is buffered connectivity?

~~~
aSplash0fDerp
Honestly, I think they need to create new categories for the protocols used
for the traditional Internet and divide it into Local Area Protocals (LAPs)
and Wide Area Protocols (TCP/IP is the defacto WAP) as well as adding a
gateway (like AppleTalk to IP gateways of yore) so that there is more than an
airgap (its a different language/protocol as well) separating your network
from from the worlds biggest venerable network.

Or, as compute power, storage and hardware get less expensive, running two
cryptoledgers for inbound and outbound communications would make it easier to
sanitize every bit that enters a network.

I like squid and other products, but I think dropping TCP/IP from the LAN or
tranfering all packets in amber (bitledger) would correct a lot of the present
shortcomings with security, privacy and unfixable manufacturer defects.

~~~
saagarjha
How would that help with this issue, which is specific to the processor
itself?

~~~
aSplash0fDerp
Really???

Needing physical access to compromise a system sounds like a much better way
to play whack-a-mole.

If the hardware cannot protect itself, moving the defense to the next layer
out sounds plausible to me.

~~~
saagarjha
Sanitizing input that you will then execute is known to be Turing-complete.

~~~
aSplash0fDerp
The bitledger-as-a-router/gateway/firewall was more of a joke, but replacing
TCP/IP on the LAN only changes how we interface with the network without
changing any of the building blocks in place.

------
kumarski
efabless becomes more and more relevant every day.

------
aibrahem
This is a shameless plug, but I'm really hoping to increase the awareness and
the level of understanding about these kind of HW bugs.

I made a blog post trying to explain the Intel ME hardware bug.

Understanding the Intel CSME Vulnerability for Mere Mortals -
[https://news.ycombinator.com/item?id=22534259](https://news.ycombinator.com/item?id=22534259)

