Kernel memory leaking Intel processor design flaw

squaleca said:

no updates still stuck on .125

It hasn't reached Windows Update servers yet, but the standalone package is available now on the Microsoft Update Catalog, link is in first post here...

Cumulative Update KB4056892 Windows 10 v1709 Build 16299.192

squaleca said:

After

Intel Core i7-2640M 3,461 User benchmarks - Average bench 41% CPU, 1 CPU, 2 cores, 4 threads Base clock 2.8 GHz, turbo 3.3 GHz (avg) Performing above expectations (68th percentile)

47.3%Average

SC Int 71.8 SC Float 76.2 SC Mixed 80.6 61% 76.2 Pts

QC Int 210 QC Float 210 QC Mixed 221 48% 214 Pts

MC Int 207 MC Float 215 MC Mixed 216 32% 213 Pts

before

Intel Core i7-2640M 3,461 User benchmarks - Average bench 41% CPU, 1 CPU, 2 cores, 4 threads Base clock 2.8 GHz, turbo 3.3 GHz (avg) Performing as expected (54th percentile)

44.7%Average

SC Int 83.2 SC Float 83.4 SC Mixed 84.4 67% 83.7 Pts

QC Int 179 QC Float 196 QC Mixed 196 43% 190 Pts

MC Int 197 MC Float 201 MC Mixed 200 30% 199 Pts

whooo i gained performance obviously not b/c of the patch but it doesnt look like it has any impact on performance???

cereberus said:

It is funny on other forums seeing mass hysteria about the possible 30% drop in
performance due to new updated expected to fix intel bug.

It shows how little the mass media understands about factors that affect performance.

Never let a good story get in way of the truth - lol.

See the following quotations from earlier in the thread

pparks1 said:

Well, for a company that utilizes AWS quite heavily, where context switching at the hypervisor level is the name of the game, the impact of this software update is going to be huge. I know we have been discussing this bug at length over the past day here at the office.

For a gamer, worried about benchmarks, probably won't feel this bug caused any noticeable change.

Everything depends upon the workload.

It's not rocket science, but before you go believing all the hype, it would help if you actually did more reading than what so-called modern journalists (aka bloggers) put out over the wires.

For a good,thorough understanding of what they vulnerabilities are and are not, go directly to the sources:

Meltdown: https://meltdownattack.com/meltdown.pdf

Spectre: https://spectreattack.com/spectre.pdf

And, just to make it a bit more easy to glean (since both of those papers get really technical really quickly), here is a transcription of a post I made in another forum:

_______________________

OK, here is some more analysis and opinion from me.

First off, Meltdown - also known as http://www.cve.mitre.org/cgi-bin/cve...name=2017-5754

Notice the reserve date? Yeah, 1 Feb 2017 - a year ago. While the disclaimer is right there saying that it doesn't necessarily reflect the discovery date, you can bet your bottom dollar that no company is gonna reserve a CVE that doesn't exist. Plus, this came to more light around July or August, and was brushed off back then as well.

Second, one of the earlier links posted (I think) made a direct mention of a patch being issues for ARM devices, but that the authors did not know anything else about the patch. That right there got me digging deeper as well.

This is not going to end well for chipmakers for 2018. Not well at all.

First, let's tackle Meltdown - it's been under scrutiny for more than a year now. From the research paper on it: https://meltdownattack.com/meltdown.pdf

Acknowledgment

We would like to thank Anders Fogh for fruitful discussions at BlackHat USA 2016 and BlackHat Europe 2016, which ultimately led to the discovery of Meltdown. Fogh [5] already suspected that it might be possible to abuse speculative execution in order to read kernel memory in user mode but his experiments were not successful. We would also like to thank Jann Horn for comments on an early draft. Jann disclosed the issue to Intel in June. The subsequent activity around the KAISER patch was the reason we started investigating this issue. Furthermore, we would like Intel, ARM, Qualcomm, and Microsoft for feedback on an early draft.

We would also like to thank Intel for awarding us with a bug bounty for the responsible disclosure process, and their professional handling of this issue through communicating a clear timeline and connecting all involved researchers. Furthermore, we would also thank ARM for their fast response upon disclosing the issue.

I knew that at least part of the new buzz from last week was regarding this issue I had already read about, twice, in fact, both last year, once early and again around July or August. And it gets tricky, quickly, because of this:

Meltdown fundamentally changes our perspective on the security of hardware optimizations that manipulate the state of microarchitectural elements. The fact that hardware optimizations can change the state of microarchitectural elements, and thereby imperil secure software implementations, is known since more than 20 years [20]. Both industry and the scientific community so far accepted this as a necessary evil for efficient computing. Today it is considered a bug when a cryptographic algorithm is not protected against the microarchitectural leakage introduced by the hardware optimizations. Meltdown changes the situation entirely. Meltdown shifts the granularity from a comparably low spatial and temporal granularity, e.g., 64-bytes every few hundred cycles for cache attacks, to an arbitrary granularity, allowing an attacker to read every single bit. This is nothing any (cryptographic) algorithm can protect itself against. KAISER is a short-term software fix, but the problem we uncovered is much more significant.

We expect several more performance optimizations in modern CPUs which affect the microarchitectural state in some way, not even necessarily through the cache. Thus, hardware which is designed to provide certain security guarantees, e.g., CPUs running untrusted code, require a redesign to avoid Meltdown- and Spectre-like attacks. Meltdown also shows that even error-free software, which is explicitly written to thwart side-channel attacks, is not secure if the design of the underlying hardware is not taken into account.

With the integration of KAISER into all major operating systems, an important step has already been done to prevent Meltdown. KAISER is also the first step of a paradigm change in operating systems. Instead of always mapping everything into the address space, mapping only the minimally required memory locations appears to be a first step in reducing the attack surface. However, it might not be enough, and an even stronger isolation may be required. In this case, we can trade flexibility for performance and security, by e.g., forcing a certain virtual memory layout for every operating system. As most modern operating system already use basically the same memory layout, this might be a promising approach.

Meltdown also heavily affects cloud providers, especially if the guests are not fully virtualized. For performance reasons, many hosting or cloud providers do not have an abstraction layer for virtual memory. In such environments, which typically use containers, such as Docker or OpenVZ, the kernel is shared among all guests. Thus, the isolation between guests can simply be circumvented with Meltdown, fully exposing the data of all other guests on the same host. For these providers, changing their infrastructure to full virtualization or using software workarounds such as KAISER would both increase the costs significantly.

Even if Meltdown is fixed, Spectre [19] will remain an issue. Spectre [19] and Meltdown need different defenses. Specifically mitigating only one of them will leave the security of the entire system at risk. We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.

This is not good stuff at all. But it gets worse. Spectre is way, way worse. From the Spectre paper: https://spectreattack.com/spectre.pdf

Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim’s process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.

Uh, that pretty much covers everything. Everything from computers to PDAs to cell phones to IoT devices to cloud servers to you name it.

And the solution?

While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.

Yeah, probably gonna be putting off my build as long as possible now. If re-imagining the CPU can happen in an appropriate timeline to eliminate this type of a vulnerability (but who is to say that, in trying to work around this one, hey don't create one that is much worse?).

The practicality of microcode fixes for existing processors is also unknown. It is possible that a patch could disable speculative execution or prevent speculative memory reads, but this would bring a significant performance penalty. Buffering speculatively-initiated memory transactions separately from the cache until speculative execution is committed is not a sufficient countermeasure, since the timing of speculative execution can also reveal information. For example, if speculative execution uses a sensitive value to form the address for a memory read, the cache status of that read will affect the timing of the next speculative operation. If the timing of that operation can be inferred, e.g., because it affects a resource such as a bus or ALU used by other threads, the memory is compromised. More broadly, potential countermeasures limited to the memory cache are likely to be insufficient, since there are other ways that speculative execution can leak information. For example, timing effects from memory bus contention, DRAM row address selection status, availability of virtual registers, ALU activity, and the state of the branch predictor itself need to be considered. Of course, speculative execution will also affect conventional side channels, such as power and EM.

As a result, any software or microcode countermeasure attempts should be viewed as stop-gap measures pending further research.

So, basically, we're screwed if this ever makes it into the dark web - which it just did.

And this sums it all up:

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. As a result, a broad range of software isolation approaches are impacted. In addition, existing countermeasures to cache attacks for cryptographic implementations consider only the instructions ‘officially’ executed, not effects due to speculative execution, and are also impacted.

The feasibility of exploitation depends on a number of factors, including aspects of the victim CPU and software and the adversary’s ability to interact with the victim. While network-based attacks are conceivable, situations where an attacker can run code on the same CPU as the victim pose the primary risk. In these cases, exploitation may be straightforward, while other attacks may depend on minutiae such as choices made by the victim’s compiler in allocating registers and memory. Fuzzing tools can likely be adapted by adversaries to find vulnerabilities in current software.

As the attack involves currently-undocumented hardware effects, exploitability of a given software program may vary among processors. For example, some indirect branch redirection tests worked on Skylake but not on Haswell. AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based on past runs” [3, 5], implying even more complex speculative behavior. As a result, while the stop-gap countermeasures described in the previous section may help limit practical exploits in the short term, there is currently no way to know whether a particular code construction is, or is not, safe across today’s processors – much less future designs.

A great deal of work lies ahead. Software security fundamentally depends on having a clear common understanding between hardware and software developers as to what information CPU implementations are (and are not) permitted to expose from computations. As a result, long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform.

More broadly, there are trade-offs between security and performance. The vulnerabilities in this paper, as well as many others, arise from a longstanding focus in the technology industry on maximizing performance. As a result, processors, compilers, device drivers, operating systems, and numerous other critical components have evolved compounding layers of complex optimizations that introduce security risks. As the costs of insecurity rise, these design choices need to be revisited, and in many cases alternate implementations optimized for security will be required.

Let the games begin.

eddward said:

Since June
(https://meltdownattack.com/meltdown.pdf)

No, it was disclosed to Intel then. The associated CVE was reserved in February, and the Meltdown PDF shows that researchers were already working on the bug to verify it back in 2016.