News Serious security flaw in Intel processors

[Michkov]

So how long do I have to hold off building a new PC for now?

 

[Face]

So how long do I have to hold off building a new PC for now?

Meltdown will be patched in the OSes, I think. You might get lower performance, but that's it. Spectre is the more general exploit that shows that the side-band effect of cache state manipulation in speculative execution can be used for malicious attacks.

For fixing the later, I think there is not even planing yet. Could well be into a year until we see a superscalar processor hardened against this.

 

[MeDiCS]

So how long do I have to hold off building a new PC for now?

No idea. It may take years for the first affordable and performant CPUs to come with these bugs fixed because it sounds like it's a pretty fundamental flaw in their designs, regardless of manufacturer.

 

[Xyon]

[/COLOR]ELI5 (I'm still reading the papers): there are two attacks: Meltdown and Spectre. Both of them rely on the fact that modern processors execute code before it knows if it should or not, for performance reasons (Speculative Execution). That is usually not a problem because if, in the end, that piece of code shouldn't have been executed, the CPU simply discards all the work it did like nothing happened. However, that fact is that code did run and just from that fact, the CPU's cache is modified because it works independently from the part that deals with speculative execution.

The attacks goes like this:

1. Force the CPU to speculatively execute a piece of code that reads something it wouldn't normally

2. The CPU rolls back all the effects of that invalid operation, as it should

3. Read that piece of data that is now in the cache where it shouldn't

The difference between Meltdown and Spectre is that Meltdown can be exploited with simple code to read protected data from the OS, while Spectre must manipulate the OS (or another program) in a specific way to steal the data.

I'm being facetious, I know, but my five-year-old doesn't know words like "CPU", "Cache" and "Speculative".

 

[jedidia]

Admin edit: Fair warning, the page behind this link contains an acronym which spells out a rude word.

Whoops, completely forgott about that :lol:

 

[Artlav]

Crap, this is bad.
I forgot that modern browsers use JIT compilers (meaning your JS is running on actual hardware), sot this IS exploitable remotely by code in a browser - https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript

 

[MeDiCS]

I'm being facetious, I know, but my five-year-old doesn't know words like "CPU", "Cache" and "Speculative".

Almost all computers fail to hide all the naughty things it does behind your back, so bad guys can force the computer to say things it must never say ever.

---------- Post added at 02:45 PM ---------- Previous post was at 02:35 PM ----------

Crap, this is bad.
I forgot that modern browsers use JIT compilers (meaning your JS is running on actual hardware), sot this IS exploitable remotely by code in a browser - https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript

Yes, which is absolutely bonkers. In the Spectre paper, they mentioned a proof-of-concept JS snippet which would let any random website retrieve all the browser's memory, which would include things like cookies, browsing history, saved passwords, current tabs... From there it could potentially read everything in your computer's memory.

In theory, a random JS script from a random website could read any encryption keys and passwords in memory if it knows where to look, and there's not much that can be done to prevent that. I read there are mitigations though, including one Linux patch which degrades performance by a further 1.5%.

---------- Post added at 03:47 PM ---------- Previous post was at 02:45 PM ----------

https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

https://www.amd.com/en/corporate/speculative-execution

---------- Post added at 04:15 PM ---------- Previous post was at 03:47 PM ----------

Running Linux 4.14.11 (the first stable version to have the Meltdown patch aka KPTI) and I am seeing very perceptible slowdows with heavy IO workloads. Normal usage seems fine.

 

[jedidia]

I forgot that modern browsers use JIT compilers (meaning your JS is running on actual hardware), sot this IS exploitable remotely by code in a browser - https://www.react-etc.net/entry/expl...via-javascript

Oh
That puts this entire thing into a whole new ballpark :facepalm:

 

[RisingFury]

Besides JavaScript, what do we have to watch out for? It seems to me that the attack is only possible if some piece of code runs on your computer, but doing that isn't that easy these days.

So I have a few questions:

- Suppose you don't want to disable JavaScript, is there a way to disable the JIT compiler? Would that matter at all?

- What other points of attack should I guard against besides "don't download files from sites you can't trust"?

- To what degree can a typical anti-virus / firewall software protect me?

 

[MeDiCS]

Besides JavaScript, what do we have to watch out for? It seems to me that the attack is only possible if some piece of code runs on your computer, but doing that isn't that easy these days.

So I have a few questions:

- Suppose you don't want to disable JavaScript, is there a way to disable the JIT compiler? Would that matter at all?

- What other points of attack should I guard against besides "don't download files from sites you can't trust"?

- To what degree can a typical anti-virus / firewall software protect me?

Yes, a malicious program or script must be running in your computer. I don't know if JIT is completely required for Spectre JS attacks, but what it does require is a fairly accurate timer. Mozilla is nerfing exactly that to mitigate Spectre and I'm sure all other vendors will apply something like that in their browsers, so I don't think any action is required at all except keeping your browser up to date.

Right now, the only other mitigation is to keep your OS up to date. There are already patches to close up Meltdown for Windows 10, Linux, and MacOS. Android and iOS patches should be available shortly if they are not already. AFAIK, the only real solution is a new CPU that doesn't have those bugs, which none exist ATM (unless you want to run an old Pentium-era CPU).

Firewalls won't help directly, and neither will anti-viruses most of the time. The problem is way deeper.

 

[Urwumpe]

And we have now things like asm.js, which makes things way more complicated now than before, when Javascript was just a way to make web pages annoying.

https://en.wikipedia.org/wiki/Asm.js

 

[Artlav]

- Suppose you don't want to disable JavaScript, is there a way to disable the JIT compiler? Would that matter at all?

Not that i know of, but it might appear in the future.
In practice, with JIT disabled you would only get low performance on ads, web games and abusive sites made by designers.
I.e. try a heavy JS program like my software OpenGL demo ( http://orbides.org/apps/superslow.html ), it should run fluidly on JIT compiler and always in slow motion on non-JIT.

- What other points of attack should I guard against besides "don't download files from sites you can't trust"?

Anything that can run more or less native code, which this days is a lot of stuff, from images to *fonts*. What exactly can or can not exploit it is a wide open question i can't really answer without a lot of trying to do the exploiting.

In general anything that is fully emulated (Bochs VM, non-KVM Qemu, non-JIT Java/C#/JS, Excel macros, fonts, etc) should be safe, while things that are heavily optimized (virtualization of all sorts, JIT compiled stuff of all sorts, things that run native or native-translated code from somewhere else rather than just data, etc) can be vulnerable.

- To what degree can a typical anti-virus / firewall software protect me?

Zip, zilch, none, nada.
Antiviruses these days are essentially a scam, and even when they are not they can only protect against specific, already-known samples of malware, give or take slight variations.
They are useful in septic environments like offices with windows computers ran by clueless users, but they can't do anything against high grade exploits in the hands of curious kids.

Firewalls are not relevant at all, since it's not something that comes from outside but rather something that you come towards.

 

[Face]

If I understood the Spectre paper right, you need quite some knowledge about the target's inner working. In addition, there also needs to be some code path in the target that enables the exploit. So in essence it will be some kind of arms race between e.g. browser coders and hackers.

What makes me skeptical that this will be as bad as it sounds, is the fact that the exploit needs quite some time to determine the values of the memory, because it needs to test the page in question for cached state (the highest through-put micro-architectural side-channel as it seems) by means of measuring access time. As a side note, I guess this is also the reason why decreasing the browser timer's precision artificially is a way to mitigate the problem: it will make it harder to write attacker code that measures cache state.
Somewhere in the paper, I read about reading speeds of around 0.5MB/s. This is not terribly fast, especially if you take into account that the CPU is quite busy in that time. A mere brute-force approach with just dumping the browser memory and sending it in for later inspection is then easily detected, if you take into account that even my session here with nothing but O-F running takes around 200MB. That would mean a practically stalling script running for almost 7 minutes, not counting the time needed to pack the info into an upload container and send it in. If you try to hide it by doing it in incremental steps, you risk longer overall times, therefore preemption or detection.

IMO it would need a tailored attack to use Spectre on browsers efficiently, and given that the word is out on it now, I bet most coders will have a look out for "gadgets" in their code base.

So yeah, I'm a bit skeptical on the real impact it will have, but certainly interesting times ahead. After all, people now know about micro-architectural side-channels *evil grin*.

 

[jedidia]

So yeah, I'm a bit skeptical on the real impact it will have, but certainly interesting times ahead.

I think individual users will barely notice a thing. For the industry as a whole, however, the economic damage from having the hardware slowed down due to the meltdown fix will be substantial. As I understand it, especially database servers will be affected significantly by the slowdown.

 

[tl8]

I think individual users will barely notice a thing. For the industry as a whole, however, the economic damage from having the hardware slowed down due to the meltdown fix will be substantial. As I understand it, especially database servers will be affected significantly by the slowdown.

Postgres was a couple of percent. We generally use MySQL at work so it will be interesting how that goes.

Annoyingly, we were looking at getting new servers soon.

 

[RisingFury]

I'm getting the impression that this attack is not as significant as first reported:
- The attack has to be run on your computer - that's not easy.
- The attack has a tricky time of reading the memory - and whatever it reads is just whatever the CPU happens to have loaded.
- Once you read the memory, it's up to you to decode what the data actually means.


If I understand correctly, there are two things you can do to mitigate this attack:
- Update your OS and browser.
- Engage in safe browsing practices.

 

[jedidia]

and whatever it reads is just whatever the CPU happens to have loaded.

No, it's what the CPU currently has cached. If you're browsing, this is pretty much guaranteed to include browser cookies.

I agree however that spectre seems very difficult to exploit, and the fuzzy time fix they're putting into browsers should make it very difficult. Meltdown, however, is a serious risk for a lot of infrastructure. Not anymore after all the OSes have been patched, but then that infrastructure will suddenly need more hardware... That will be the main impact of this bug.

 

[MeDiCS]

If I understood the Spectre paper right, you need quite some knowledge about the target's inner working. In addition, there also needs to be some code path in the target that enables the exploit. So in essence it will be some kind of arms race between e.g. browser coders and hackers.

What makes me skeptical that this will be as bad as it sounds, is the fact that the exploit needs quite some time to determine the values of the memory, because it needs to test the page in question for cached state (the highest through-put micro-architectural side-channel as it seems) by means of measuring access time. As a side note, I guess this is also the reason why decreasing the browser timer's precision artificially is a way to mitigate the problem: it will make it harder to write attacker code that measures cache state.
Somewhere in the paper, I read about reading speeds of around 0.5MB/s. This is not terribly fast, especially if you take into account that the CPU is quite busy in that time. A mere brute-force approach with just dumping the browser memory and sending it in for later inspection is then easily detected, if you take into account that even my session here with nothing but O-F running takes around 200MB. That would mean a practically stalling script running for almost 7 minutes, not counting the time needed to pack the info into an upload container and send it in. If you try to hide it by doing it in incremental steps, you risk longer overall times, therefore preemption or detection.

IMO it would need a tailored attack to use Spectre on browsers efficiently, and given that the word is out on it now, I bet most coders will have a look out for "gadgets" in their code base.

So yeah, I'm a bit skeptical on the real impact it will have, but certainly interesting times ahead. After all, people now know about micro-architectural side-channels *evil grin*.

Yes, it's hard to exploit Spectre but the problem is that now everyone knows there's an unfixable side-channel for anyone to use it. The throughput is pretty low, so what I think we'll start seeing is Spectre being incorporated into the malware toolbox to extract specific pieces of useful data. Doesn't matter if the maximum throughput is 0.1MB/s if the password I'm looking for is only 16 bytes in length. Suddenly password-protected local databases and other similar services (e.g. local X servers relying on token authentication) can be wide open to surgical attacks.

AFAIK, all cache extraction methods rely on very precise timing info (in the Flush+Reload paper they mention that in their tests ~80 CPU cycles is the minumum delay that separates cached and uncached lines), so fuzzing that (if possible, like in sandboxed JITed or intepreted languages) can be a very effective mitigation. Sounds like the game is over if malicious code is run natively because, on the x86 at least, any unpriviledged program has access to high precision timers.

---------- Post added at 09:02 AM ---------- Previous post was at 08:54 AM ----------

No, it's what the CPU currently has cached.

No, it's potentially most of you have in memory. The cache is just a roundabout way to get to whatever you want to read.

 

[Linguofreak]

No, it's what the CPU currently has cached. If you're browsing, this is pretty much guaranteed to include browser cookies.

Not exactly. The cached data used in the attack is not the data the attack is trying to retrieve. To my understanding, the attack is using an address in the kernel as part of an index into an array in userspace. This access will fault, but the processor begins executing it speculatively before the fault comes along and causes the instruction to be aborted. This causes data from the userspace array to be brought into cache. By determining access latency for various addresses in the array, the attacker can find the value of the kernel address that was used to index the astray.

 

[RisingFury]

Computerphile on the subject: