Slashdot Mirror
Google Says Almost All CPUs Since 1995 Vulnerable To 'Meltdown' And 'Spectre' Flaws (bleepingcomputer.com)
Catalin Cimpanu, reporting for BleepingComputer: Google has just published details on two vulnerabilities named Meltdown and Spectre that in the company's assessment affect "every processor [released] since 1995." Google says the two bugs can be exploited to "to steal data which is currently processed on the computer," which includes "your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents." Furthermore, Google says that tests on virtual machines used in cloud computing environments extracted data from other customers using the same server. The bugs were discovered by Jann Horn, a security researcher with Google Project Zero, Google's elite security team. These are the same bugs that have been reported earlier this week as affecting Intel CPUs. Google was planning to release details about Meltdown and Spectre next week but decided to publish the reports today "because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."
This isn't even surprising that the problem exists in almost every CPU since a long time considering that most CPUs share the same type of logic in order to achieve the best performance. But performance and security often comes into conflict.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Shouldn't that be : Almost All Intel processors?
At the time of writing, Google believes that "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)" is affected by Meltdown. Google says it verified Meltdown only against Intel CPUs, but not ARM and AMD. Nonetheless, Intel has a market share of than 80% on desktops and more than 90% on the laptop and server markets, meaning that a large number of desktops, laptops, and servers are affected.
Did the TFA really self-link? (Try clicking "two vulnerabilities named Meltdown and Spectre")
scroll down 2 stories..
https://meltdownattack.com/
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
Can we get a direct link to Google then not to some intermediate regurgitation site?
With all these boulder abilities you would be nuts to trust your wealth to a mechanism thatâ(TM)s nothing but tech. No paper trail no fail safe. At least gold in a vault that few if anyone knows about will not be at risk of theft from someone at a computer on the other side of the world.
The fix for the original "Intel only" bug was "fuckwit" (kpti=on) and there is a patch [1] from AMD to disable kpti on AMD cpus in order to avoid unnecessary performance loss. Now does this mean the the AMD patch was short sighted and we need kpti on AMD cpus as well? Or does it mean kpti isn't a sufficient counter measure for meltdown/spectre?
[1] https://lkml.org/lkml/2017/12/27/2
Given the natural process isolation in microkernels are they immune, or at least strongly resistant, to Meltdown ?
Just patch all the CPUs so they process things introspectively, with a glass of wine and some light jazz.
... They are just reiterating what the community has known for weeks.
Leaks through speculative execution is anything but new.
Everybody that knows anything useful about CPU's has known this since the beginning of speculative execution through privilige barriers.
Every modern microarchitecture is just a security mess with side-channels, pure flaws, microarchitecture stupidness.
What are we supposed to do? Have you seen the price of Amiga and Atari ST computers on eBay? Not to mention that there's nowhere near enough to supply the whole planet!
Has anyone started working on an OS/9 port of Firefox for the Color Computer 3 yet?
#DeleteFacebook
It will be interesting to see how quickly corporations react to this. It could get expensive.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Google Project Zero
Shouldn't that be Google Project Zero Dawn?
Shouldn't ever build the wrong thing.
Time to bust out my 486!
There is no XUL, only WebExtensions...
Shall we design a CPU with these potential security flaws in them?. Shall we add these features to our CPU's, maybe some powerful agencies with lots of government money in their pockets will like them!?
And why AMD and ARM may not be vulnerable to Meltdown:
Someone at Intel has spun BeepingComputer - Google said that nearly all CPUs MADE BY INTEL since 1995 are likely to be vulnerable. Way to rescue your stock price, man. Good work from msmash and /. for repeating the lie too.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
So where are all the stories about how everyone who purchased a laptop or pc for Xmas will be returning them ASAP.
Detailed description here. LOL.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Perhaps we should entertain the possibility that the revelations of Edward Snowden scratch the fucking surface as to the deceptive power and control *that US corporations hold over the US government*.
There, fixed that for you!
If I understand the write-ups, most or all of the bugs only happens during speculative-execution or similar "do it faster" scenarios.
I wouldn't be surprised if GPUs and other non-CPU chips had similar vulnerabilities.
A solution for future chips is to have a built-in "slow and safe" mode or even a separate plug-and-play-compatible chip that had speedups and for that matter all functions that hadn't undergone exhaustive testing disabled.
Users who needed a higher guarantee of security in exchange for decreased performance could used the "slow and safe" approach.
Especially since Rust does not rely on runtime checks or tricks for its safety guarantees. It is verified "safe" by the compiler statically at compile time. If you weren't so interested in mocking "hipsters" and "millennials" and other bullshit like that and bothered educating yourself you wouldn't sound like such a douche-bag.
Health records are being digitized and moved to the cloud.
Local and state governments are moving mountains of data for easy access digitally.
Federal government has plans to move to cloud providers.
Nation states engage in espionage.
Nation states engage in cyber attacks.
What the mountain of citizen data being digitized and easily accessible mean? What recourse will be available for citizens if a government is "liable", both for lax security and for attacks? What of the banking systems (SWIFT)? Are nation states already at war (Israel, Saudi Arabia, Iran, Russia, China, Five Eyes). What of emerging state players (Catalonia)? It appears we are heading for a wary future. Privacy is a human necessity and right.
Reading through a variety of descriptions I understand the attack for Meltdown, but I'm seeing less of a discussion around how patches may work - in particular I read if your model of Intel processor supports PCID (Process-Context Identifiers) a fix may not impact performance as much, but I've not seen any description of why and would be interested to know how that helps.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
One of the things I've seen flying around, is some people are saying this can be exploited in a web browser, thanks to Javascript JIT-compiling to machine code.
I am pretty damn out of date on Javascript compilers, so I was hoping someone could explain how this is possible. Javascript doesn't have pointers. I'd think that if a Javascript programmer is capable of writing Javascript code that compiles in such a way that the programmer can create a pointer of their own making (perhaps pointing to kernel memory) and can cause code to dereference that pointer, we would all call that a severe and inexcusible compiler bug.
I mean, even if there were no processor flaw at all, but the Javascript-compiled-to-x86 code could read arbitrary memory in its own browser process, that alone would be a severe web-user-killing nightmare. How is that not a compiler bug?
Am I mistaken that a Javascript exploit is possible?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Non-tech person here. Can I get this simply by browsing the web, or does it need the user to run an executable?
Am I mistaken that a Javascript exploit is possible?
The fact that a given programming language gives you more or less freedom regarding how to deal with the memory management aspects doesn't change the fact that the generated applications rely on memory. In any case all these bugs seem fairly theoretically and very difficult to be actually exploited. It seems more a matter of making sure that computers are 100% safe at their most basic level than actually avoiding imminent threats.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
32-bit ARM may be safer, because speculative execution is much, much more difficult there.
The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.
Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.
32-bit ARM is mostly in-order for these reasons.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html
It's time for Itanium to rise again!
Amazon cloud services, Google, Azure are players in the cloud where multiple users share the same unknown processor. Would they be affected? Would they have to stop provisioning virtual machines for different users on the same physical sever? Would it increase their costs and reduce profit margin? Or would it reduce their attractiveness and people would use less cloud services?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Regarding Meltdown, specifically, since the known fix requires flushing the Translation Lookaside Buffer twice as often:
Does anyone know if Microsoft will exclude AMD systems from the Privileged Address Space unmapping workaround? It seems silly to neuter AMD systems unnecessarily just to fix it on Intel systems.
But of course the useless editors insist on being useless and the fanbois score you down for daring to ask for what should be obvious.
Just read the Spectre paper.
The attacker allocates an array and reads it to ensure that all processor cache has been overwritten. Then, they feed a crafted input to some service which they know has a certain pattern of machine instructions handling their input. That combination of machine instructions will touch specific rows of cache. Then the javascript reads back over their own array and times the access, seeing which rows of cache were evicted. As a result, they now know one byte of the target's memory. Then they repeat the attack to target the next byte.
The paper says they actually did implement the Javascript attack against it's host browser. I think (though others say not) that it could target other processes on the computer as long as it knows the exact machine instructions of that service and is able to talk to that service (which javascript generally isn't)
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
The trick is that boundary checks are performed during runtime. When you try to access outside of array, JIT generated code will catch it and return error. But if bound check needs DRAM fetch, up to 100 ticks will be executed speculatively, keeping trace in cache (and jump prediction tables).
Meltdown is trivial and in the wild, which is why everyone is hopping.
There seems to be a concerted PR effort to shine spotlight on everything rather than just Intel where it belongs.
Meltdown is basically heartbleed. This is NOT a side-channel attack. It allows an attacker to trick the processor to flat out be handed the value of memory address the attacker should never be able to access. The only linkage between it and spectre is incidental exploitation of speculative execution.
Spectre is exclusively a "side-channel" attack. To continue TLS analogy it's like using an AES cipher suite without AES blinding. Numerous side channels have existed in Intel and other processors. The use of branch predictors as a side channel specifically as a vector for compromising security has been known publically for at least a dozen years.
I was wondering the same. Everything I've seen seems to involve a side channel attach which requires use of actual ASM compiled into your program. It's bad, don't get me wrong, but it appears that one would need to run code locally on the machine at a user level. I haven't seen anything that would make me think that a drive by attack through a web browser could actually be performed. This would more be in the world of trojans, worms and other more traditional pieces of malware. Not drive by attacks.
In any case all these bugs seem fairly theoretically and very difficult to be actually exploited.
The Spectre paper documents a proof of concept in five lines of JavaScript code that works on Google's V8 JavaScript engine (ie. Google Chrome).
That doesn't appear to be merely theoretical.
-- Sometimes you have to turn the lights off in order to see.
The PROBLEM...
All Intel CPUs, BY DESIGN, give user code ring-0 access. This is the greatest and worst flaw a modern CPU can have, but is essential to allow the NSA and GCHQ to craft perfect trojan code exploits.
AMD CPUs do NOT allow user code ring-0 access by design. A fundamental hardware architecture DIFFERENCE between AMD and Intel. To 'patch' Intel's NSA back-door (partially), the kernel of all OSs must be patched is such a way, memory management and IO functions are slowed to an extreme degree, by constant state reset and flushing. An extreme solution to an extreme hardware flaw in Intel chips ONLY.
A far lesser flaw exists in ARM cores, but the patch that fixes it is performance FREE is common ARM use cases.
Zionist trolls are busy conflating this flaw with other bugs- because both Intel and AMD have thousands of CPU errata commonly fixed with trivial, perfomance free patches. Google, another NSA company (like Facebook) is assisting Intel by pushing SPECTRE- a theoretical vector of attack with only INTEL real code attack examples. Spectre hardly affects AMD, and where it does is trivially patched like all the other issues commonly found in Intel and AMD parts.
MELTDOWN is the ONLY issue of significance, and that is wholly a disaster for any computer using Intel. And Intel can't even have a fixed design til late 2019 at the very EARLIEST.
Side effects are something that is to be expected.
In case of spectre, speculative execution is happening as it shoudl, everything is having the correct behaviour.
There's no *formally wrong* behaviour to be patched in the CPU or in microcode.
There's nothing that should be patched in the CPU, the CPU works as intended, it just happens that this "as intended" produce a couple of side effects that where not noticed until recently.
It's just that researcher have noticed "yet another thing that can be timed" and thus a new side-channel that can be used to leak information.
The only novelty is it's built around a different CPU feature than other timing attacks.
It's still your gandpa's classical timing attack, only wearing a new fancy hat.
The main problem is that arbitrary externaly supplied code and sensitive data should never co-exist in the same process in the first place.
It's just problems waiting to happen.
(Seriously eBPF ? User supplied byte-code JITed in-kernel ? What could possibly go wrong ? there's a reason why that setting is non-standard)
Affected browsers (lots of them !) have basically a flawed design (running JITed Javascript code in the same context as some sensitive information reside). It just happens the spectre was the exploit that happen to reveal the flaw. But basically, it was just a problem waiting to happen.
IT NEEDS to be handled in the software anyway
(even if the CPU could suddenly stop doing speculative execution, e.g.: you switch to an Atom processor, there could still be yet another different exploit 2 months down the line that finds another way for Javascript to access all the information that reside in the process. Remove the sensitive data out of the process and you've fixed the software forever, no matter what exploits come here... well as long as the CPU respects memory protection, which is an entirely different level of wrong. Meltdown's level of wrong).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Processors with mainframe security in mind (SPARC, IBM S390, PowerPC, POWER) have been fine for a long time. ARM is kind of the unknown here impact wise.
If the defect is in the microcode and they patch it in software, isn't it still vulnerable?
The defect that is happening, is that (by careful timing of cache) it's possible to see information to which the process has full access anyway.
The stupidity of some browsers is to store sensitive information in the same process as where the remotely provided javascript is JITed and executed, relying on "well, we do array boundary checks before reading them, so we should be safe from buffer overflows" for security.
Spectre works in a few corner cases because there are situation where software has full access to it's own data, but doesn't actually want to access any arbitrary data : mainly, it wants the Javascript to only read the data inside its array, and not outside were some sensitive information would be stored.
Which would fix ?
The blunder which gives access to already accessible data ?
The stupid software which keeps sensitive data and arbitrary code within reach of each other.
The first only works in a few key cases.
The second is a problem waiting to happen. If it's not Spectre today, it might be a completely different exploit tomorrow.
Doesn't seem like it would be difficult to undo or work around the software patch to access the original defective microcode.
The quick'n'dirty software correction would be :
- disabled JIT, so the arbirary code doesn't generate a thigh compact group of machine instruction that can all fit inside the CPU pipeline.
That's going to be order of magnitude more difficult to circumvent, at the cost of performance hit specific to the formelly JIT-ed code.
(But you still have a broken software that is going to get b0rken by the next coming exploit).
The formally correct software correction would be:
- keep the sensitive data and arbitrary code separate from each other. Thus even if a different exploit happens to your system, it would still not be able to access the sensitive data. You've fixed the problem forever.
The microcode/CPU correction would be :
- completely disable speculative execution, meaning a performance hit whenever there's a conditionnal jump in the code (basically everywhere).
You computer now runs like shit, and you still have broken-by-design software sitting waiting for the next exploit.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Mapping kernel memory into userland is just an insecure software performance hack that was waiting to bite. It just did. Again! I'm referring to Meltdown--not Spectre--but that's a big reason for the immediacy of this problem.
PTKI, the "workaround" to Meltdown, is actually a commonsense security hardening measure that OS makers should have aggressively rolled out long ago. That goes double for processes hosting dangerous processes like web browsers. And, PTKI heads off many threats we don't even know about yet.
Instead,we've been wishfully tiptoeing around PTKI (e.g. kernel ASLR, etc.) hoping to avoid it. Yes, there's a performance hit but it's greatly mitigated by PCID (i.e. ~29% greater syscall overhead on Intel) which has been available since 2013. But, we've just been putting it off for another day.
Now, at least on Windows and MacOS we're going to get stuck with a rush job implementation that will kill performance in many cases. Hopefully this will work out in time as future versions of OSs get optimized, e.g. bypass PTKI for certain low-risk, high syscall frequency processes like the cores of DB managers.
Meltdown uses out-of-order execution and a side channel attack that is unique to Intel. Spectre uses speculative execution and is more generalized, with tested proof-of-concept attack code on AMD and ARM.
On the other hand, Spectre only enables access to data to which the process had access to begin with. (Meh...)
Only a very small subset of software can actually be usefully abused, mostly due to bad software design :
- Google's demo relied on a non standard setting that turns on a JIT engine that runs user-provide arbitrary byte-code in-kernel (common, in-kernel ? What could possibly go wrong ! Seriously, there's a reason why this setting is non-standard).
- There are browser with bad designs that manage to keep sensitive data in the same context as remotely-provided Javascript code.
In other words, a problem waiting to happen. Spectre just happens to be the exploit which bit them now, but any other completely different exploit could have come in a couple of months and done similar damage.
Yup, it's bad that speculative execution may lead to some side effect, but it's working as intended.
It's the software which is stupid (or dangerous options turned on, as in the kernel) and should be fixed before another problems comes again.
---
Whereas Meltdown is an entire different level of worrying.
On Intel CPU, access rights are checked way to late, by that time speculative execution has had time to do stuff which can also be timed.
Other CPU (like AMD's) work much more sanely, doing the check first and not progressing anything. It cost a tiny bit of performance, but is more formally correct and ends up protecting against such problems.
That means that on Intel CPUs the whole set of guarantee that memory protection is supposed to give don't hold true any more.
It's the whole memory protection scheme flying out of the window.
On Intel CPUs memory protection has stoped working as it should.
The software is correct on relying on memory protection for security, it's Intel's protection that suddenly doesn't work anymore.
No matter if you write correct software.
On any other CPU protection works as it should, and non-stupid software is safe.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Consider the case where the code in Listing 1 is part of a function (such as a kernel syscall or cryptographic library) that receives an unsigned integer x from an untrusted source.
Please, tell me a real-life situation where receiving an "unsigned integer from an untrusted source" is common and/or doesn't provoke many other problems (e.g., given program most likely crashing with wrong values), but this is just the start. Let's continue reading...
The process running the code has access to an array of unsigned bytes array1 of size array1 size, and a second byte array array2 of size 64KB.
if (x y = array2[array1[x] * 256];
The code fragment begins with a bounds check on x which is essential for security.
[...]
When the compiled code above runs, the processor begins by comparing the malicious value of x against array1 size. Reading array1 size results in a cache miss, and the processor faces a substantial delay until its value is available from DRAM. During this wait, the branch predictor assumes the if will be true, and the speculative execution logic adds x to the base address of array1 and requests the data at the resulting address from the memory subsystem. This read is a cache hit, and quickly returns the value of the secret byte k. The specu-lative execution logic then uses k to compute the address of array2[k * 256], then sends a request to read this address from memory (resulting in another cache miss). While the read from array2 is pending, the value of array1 size finally arrives from DRAM. The proces-sor realizes that its speculative execution was erroneous, and rewinds its register state. However, on actual proces-sors, the speculative read from array2 affects the cache state in an address-specific manner, where the address depends on k. etc.
Have you got the idea? Basically, they expect that, under extremely specific conditions, failing to check the boundaries of an array provokes a malicious execution (rather than the way much more likely crash of the program). This is what I meant with theoretical: extremely difficult to happen unless under theoretical/prepared conditions and even much more difficult to provoke a truly malign output. I am not saying that they shouldn't fix it, just that exploiting problems of this kind is extremely difficult.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Spectre is not the same thing. Multiple processor bugs were revealed.
Spectre is not a bug.
It's not suddenly accessing something which should not be accessed in the first place. It's not breaking memory protection, only giving data that the process can already read.
Speculative execution is still working as it should.
It just happens to have a side effect that got noticed now, and got used in timing attacks. (Just like any other timing attack).
But the CPU is still working as intended, it's not a bug.
Only badly designed software that keeps that doesn't properly isolates sensitive data and remotely provided arbitrary code that can be abused (some browser, some non-standard Linux kernel settings that are non-standard for a reason).
---
(This is completely different from Meltdown, where suddenly memory protection doesn't work any more. The process access things it was never supposed to access in the first place).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I meant "if (x < array1_size) y = array2[array1[x] * 256];" rather than "if (x y = array2[array1[x] * 256];".
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Well a lot of Intel fanboys were rubbing everyone's face in how fast their choices were so it's kind of karmic in the way their shortcut backfired.
Meltdown is trivial
Seriously? Care to share a link or something? Spectre seems quite tricky, take a look at my comment down this thread.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
On the other hand, Spectre only leaks information to which the process had access to begin with.
The CPU is still working as intended.
It's only badly designed software which as affected (keeping sensitive information in the same context where arbitrary code can be executed. ie.: Browsers that keep password in the same context as where the Javascript is executed, or a special non-standard linux kernel settings that enables an in-kernel JIT engine for the bytecode used by packet filtering - there's an obvious reason why this setting is non-standard !)
But basically Spectre doesn't open new access to restricted data.
Affected software should be fixed any way (i.e.: try to keep JITed arbitrary code away from sensitive data), because if not Spectre today, another different exploit coming this year could end up being just as bad. Sensitive data should just be kept away from arbitrary code execution, no matter what.
---
Whereas with Meltdown it's suddenly memory protection not working anymore as intented on Intel CPUs (they do the access rights too late, way after other side effects had time to happen), it's the CPU which is doing things wrong.
AMD isn't affected, because they did things formally correctly - mainly doing the access rights check at the beginning of the pipeline.
It's not that trivial to fix "in the wild": because of meltdown you just can't rely on memory protection anymore (the kernel isn't sage from user-land software anymore), the only possible fix are performance killer (at end of each call, the kernel must flush itself out of the space accessible by the user-land process).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Technically, Spectre only reveals data to which the process had already access to begin with.
In the Google demo, it works because all in-kernel code (here: JIT-ed bytecode) has access to in-kernel data.
There's a reason why the option is non-standard.
In the few affected browser, it works because said browsers were stupid enough to keep sensitive data (passwords ?) in the same process as where remotely provided Javascript code is JITed and executed.
(I.e.: stupid design that should be fixed anyway. If not Spectre today, there's sure to be another exploitable flaw discovered before the end of this year which could also be leaking sensitive data. Always keep your sensitive data and arbitrary code execution segregated).
But correctly designed software should be unaffected.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Spectre cannot be considered intentional tampering.
It's still speculative execution working as it should.
Only now has someone though of a way to exploit its (normal) side-effects.
But it only leaks data to which the process already had access to begin with.
Meaning that only a very tiny sub-category of software are affected, mainly software which run arbitrary code in the same context where sensitive data is stored (which is a very bad design flaw).
Google demo relies on a (for a reason) non-standard linux kernel settings, that allows user-provided arbitrary JIT-ed bytecode to be run in-kernel, that can then in turn leak in-kernel data.
And there are a few affected browser, that keep sensitive data in the same process where remotely provided Javascript is JITed and executed.
In other words : it's still a CPU working as it should, and only a tiny range of (badly designed) software affected : probably not intentionnal.
----
Meltdown is much more horrible (it's basically memory protection not working as it should. CPU doesn't work any more as supposed).
But given that Intel has done it for some tiny performance improvement (checking access rights late in the instruction pipeline is cheaper than checking it outright in the beginning as all other CPUs are doing), okkam razzor would tend to make us believe that Intel jumped at the opportunity to shave off a tiny bit of performance as they usually do, instead of some dark cloak conspiracy.
I'm not saying that government-sponsored spying doesn't exist, just that there's absolutely zero need to force Intel to jump onto some performance shaving trick that ends up being dangerous.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
We threw away Dec Alpha, MIPS, Itanium and have almost abandoned Power and Sparc. If everyone on earth shares single gene, then it takes only one virus to wipe out large population.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.
No. Nope.
nononono.
not at all.
Spectre relies on speculative execution starting to handle instruction past some software check (ie.: array boundary check and then array access) and some side-effect leaking information (e.g.: loading things into cache).
You could only consider these programs as "following best practice" only by interpreting it as "do boundary check to avoid buffer over-runs". Nothing more.
Still it's only leaking information to which the process HAD ACCESS to begin with.
Which means that only a tiny subset of programs are susceptible.
More precisely the subset of programs which are stupid enough to keep the sensitive data in the same context where arbitrary code get executed.
i.e.: the Google Project Zero worked by turning on a special option in linux that allows user-provided (!) byte-code to get JIT-ed and executed in-kernel, which then in turn obviously has access to in-kernel data.
i.e.: there are affected browsers which keep sensitive data in the same context where they JIT and execute remotely provided Javascript (something which has "what could possibly go wrong" written all over it).
At least on Linux speculative execution cannot be used to access data *across* processes, because each process has its own address space.
i.e.: There's no virtual memory address that you can point your CPU to that contain data coming from a different process (unless it was intentionally shared across processes).
On the other hand, each process has the kernel mapped in its address space (though each process might get a different random mapping, thanks to things like KASLR), because it needs to call into it for system call (e.g.: call the filesystem to read a file).
That kernel memory is shielded from userland interference by memory protection (the process isn't allowed to read/write in the kernel space).
But due to the way Intel CPU specifically handle memory protection (in case of speculative execution, the access rights check is done too late, and some measurable side effects, such as bringing things into cache, might have happened already), on Intel CPU Meltdown manages to get around memory protection and leak kernel stuff into userland.
In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.
Given that Spectre is about things downstream form a safety check being in the pipeline before the check fails, you could say that in a stretch....
Spectre is harder to exploit than Meltdown {..} However, it is possible to prevent specific known exploits based on Spectre through software patches
Well given that Spectre is about leaking stuff to which the process has read-access anyway, it hard to exploit because it requires finding software with the right mix of bad design (mainly sensitive data and arbitrary code execution in the same process).
On the other hand, it's possible to just NOT design software in such "what could possibly go wrong ?" way.
but it is also harder to mitigate
Well, given that it's just speculative execution working as it should...
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Yup exactly.
Spectre is basically a big slap in the face of all the "rust-trolls" that come out screaming for array boundary checks whenever there's a buffer overflow happening.
Speculative execution is going to start processing the instruction past the boundary check and some measurable things like loading pages into cache are going to happen anyway, even if the CPU decides to throw away any computation because it realises that the check fails and any subsequent writes dependent on it should not get executed.
That's how its exploited with JavaScript, even if that language doesn't even have arbitrary pointers to begin with.
But on the other hand, Spectre doesnt leak any data to which the process didn't have access to begin with.
So it's only useful for a small subset of targets (e.g.: stupid browsers that keep sensitivie data in the same process as where remotely provided Javascript is JITed and executed), where the software counts exclusively on boundary checks to make sure nothing bad happens, but the user can send specially crafted code (Javascript in that example) that will use Spectre to deduce what data lies in the same process beyond the boundary.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
These runtime checks is exactly what Spectre is trying to circumvent :
due to speculative execution, some instruction after the check might start to get processed, and by the time the check fails, even if the CPU throws the work away and doesn't actually write anything into memory, some measurable side effect could have happened already (like fetching a page into cache).
So it could definitely be doable in Rust (it's even proven in JIT-ed Javascript).
But it doesn't leak anything that the current process didn't already have access to (so actual real-world useful exploit are limited to badly designed software, or dangerous kernel options, that keep sensitive data in the same process as arbitrary code).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Well given that even Mozilla didn't manage to break by switching from XUL to WebExtensions~~
(obviously I'm joking)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
(BTW, thanks to the people who suggested I read the Spectre paper.)
One of the things that makes Spectre so interesting, is that we're wrong!
Long story short, is that though Javascript doesn't have pointers, it can have an array of bytes. And the compilers are amazing and apparently do a really great job of turning the Javascript into machine language.
So the Javascript basically asks for somearray[i], where i is totally out of bounds but nevertheless does correspond to some memory location that would be used, if we weren't checking array bounds. Of course, array bounds are checked, but by the time they're checked, the conditional execution has already read and used somearray[i] to touch something else. Though somearray[i] is never directly exposed, its value can be later inferred by checking to see what memory page got loaded into the cache.
Fuck. Now I see why everyone is freaking out.
If I were in charge of the Internet (heh) I'd say let's just remove all of Javascript's ability to interface with the clock, so that you can't ever figure out what was in cache vs what wasn't. No, let's not kid ourselves: my imperial directive as God of the Internet would be that web browsers should no longer ever execute any code of any kind from web pages. (Gee, I could have told myself that 20 years ago, and I probably did but I eventually had to come to accept that Javascript on the web ain't going away, no matter how much we all hate it.) You just can't sandbox things good enough.
Oh, fuckfuckfuck.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Why else would they even bother to research, let alone publish this kind of inner workings of a processor?
Software isolation techniques are extremely widely deployed under a variety of names, including sandboxing, process separation, containerization, memory safety, proof-carrying code. A fundamental security assumption underpinning all of these is that the CPU will faithfully execute software, including its safety checks. Speculative execution unfortunately violates this assumption in ways that allow adversaries to violate the secrecy (but not integrity) of memory and register contents.
(Emphasis mine).
So...if Google has known this for awhile, and they've patched their systems (Android, ChromeOS), which versions were patched and when?
On Android, there are many people locked in on their versions of OS, whether it be KitKat, Lollipop, Marshmallow, Nougat. Some people run custom variants since they rooted their devices or their hardware manufacturer is defunct or no longer provides updates, using products like Cynogen and LineageOS. Most of them are rolled from the latest Google update, but I haven't seen a table or listing saying when (and if) Google updated the earlier versions, so people can track what they have or if they are running patched already (whether official or derived).
Intel Atom Z processors are hit by Meltdown and most definitely are used in Android tablets. Even ARM was commonly used in Android devices as well, and some of those are affected by the Meltdown variant (that's supposedly impossibly to exploit, unlike the original; ARM seems to call that variant 3a, variant 3 (no letter) being Meltdown).
Sigh, did anyone actually read the spectre paper;
Exploiting Indirect Branches.
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
Okay, to go into more details :
there are two things that are call spectre, which are both based around speculative execution.
The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.
That the one to which every piece of software running on nearly any CPU (except perhaps older Intel Atoms, Intel Xeon Phis, and older ARM 32bits as those don't do speculative execution, because as a matter of fact they have way to short pipelines) is susceptible, but which in practice isn't very concerning because it basically targets software which has "please exploit me!" design flaws written all-over it.
The second things which is called "spectre", also uses speculative execution, but is an extremely specific stuff that only targets specific CPUs :
only specific Intel CPUs are concerned, only in extremely specific circumstances. AMD CPUs are not affected. And that's expected because each CPU uses an entirely different strategy to predict branches.
Just like with Meltdown, it against boils down to Intel CPU trying to be way too much clever, trading security to shave a few performance points.
It boils down to an address (here a jump target) to even being known at the time when instruction start to pour into the pipeline. Some CPUs may try to guesstimate where the execution would go next.
The way some specific Intel CPU store their estimations means there's a risk of aliasing/confusion (CPU has learned that instruction A usually jumps to point B, but when the CPU sees instruction C it get things mixed up and think that there's a high chance it will also jump to point B and start speculatively executing there, even if that ends up not being the case and C actually jumps to a different point B).
By knowing the specific make of affected Intel CPUs, and by knowing the exact way in which this aliasing and confusion happens in that specific Intel CPUs, and by allocating a shit ton of memory (so you end up with an address that can actually be confused/aliased with your target) and by the way knowing in advance the foreign address you're trageting (because, you know, ASLR gets in the way) and spending around half an hour doing stuff (according to the Google demo) in order to get the exact thing you need so that specific Intel CPU confuses the thing exactly the way you need, then you can have the CPU guess wrong and jumping speculatively to the completely random address you've asked it to jump to (until it notice it's wrong, throws nearly everything out - except the already prefetched cache - and jumps back to the actual correct execution).
This is not something that affects every speculatively executing CPU in existence, this is not a CPU still working as it should (unlike the other exploit).
This is some specific CPU (happens to be by Intel) that each take wild guesses - way too much wild guesses - and if you know exactly how this CPU takes its too wild guesses, you can abuse to make it guess wrong. No other CPU will be affect.
Given the complexity of the taks, this is not something that you're going to see a lot in the wild and automated (not in drive-by Javascript attacks). This is something that is going to be specially crafted manually, for some very specific attacks (an attacker want to break the specific hyper visor in which it's currently staying).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Intel processors Speculative execution is NOT working correctly because it can LEAK protected Kernel mode data.
There's two different things.
The "executing past a conditional" stuff that every single CPU with speculative execution is susceptible to, is still speculative execution working as it should.
It was well established that it might need to reading stuff outside bound from the first time it was introduced (back in mid 90s), it just happens that only now some researcher though a way to abuse this.
And there's the Intel-specific attacks : Meltdown (and an obscure variant of speculative execution which is also called Spectre).
Meltdown is Intel CPU not properly doing access rights checks (doing them too late in the pipeline at a time when the memory has been already accessed, and some measurable side effect like cache prefetch have happened) where any other CPU has the correct behavior (do access rights check before anything else, even if that means a bigger performance penalty).
Because of that the fundamental protection provided by memory protection doesn't hold true anymore.
That is Intel CPU being broken.
And the Spectre variant is about abusing the way some specific Intel CPU trying to be too clever to predict where a yet-unkown jump might land and get things mixed up. CPU learns that usually instruction A will jump to point B. CPU sees a completely unrelated instruction C, but gets its things confused, and wrongly guess that it jump to B too.
The general "all CPUs are affected" Spectre is still CPU working their speculative execution as expected and still processes accessing data that they already have access too.
The Intel-specific stuff, Meltdown (and an extremely specific variant of Spectre), is Intel CPUs doing stuff that should never be happening to begin with, and is broken CPUs.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Javascript doesn't have pointers.
Yeh it does. Arrays are pointers. :) If you reference an array element, you are effectively doing array_base_address + size_of_array_element * desired_index. Yeah, sure the JIT compiler inserts a range check making sure desired index is within range and that would be enough security.. traditionally... but if you've poisoned the CPU's branch predictor cache and allowed your memory access code to speculatively execute...
Have a read. Good luck, I don't quite understand it myself.
Spectre is really about poisoning the branch predictor. It's a big deal; but I think only allows access to memory that the process would otherwise have access to. (Unlike Meltdown).
SPARC is different from x86, ARM, POWER which all suffers from this bug.
https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
"While Intel systems are the ones known to have the defect, they may not be the only ones affected. Some platforms, such as SPARC and IBM's S390, are immune to the problem, as their processor memory management doesn't need the split address space and shared kernel page tables; operating systems on those platforms have always isolated their kernel page tables from user mode ones."