Info Meltdown and Spectre Vulnerabilities Information

[juanrga]

So what does this mean for AMD users????

AMD says their CPU's are not vulnerable!

But security researchers already demonstrated AMD CPUs are vulnerable. Further info in the spectreattack and meltdownattack sites. Also available on Google security blog entry of yesterday:

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html?m=1

 

[-Fran-]

Linus being brutal is a sight for sore eyes.

I wonder if the hardcore developers that actually have the ears of the management line will actually listen to him this time, so Companies put some pressure onto Intel.

Also, I wonder when the first lawsuit against Intel will appear. Big Cloud-oriented data centers I'm sure are pissed off at this, since it's a publicity catastrophe for them. Also, a wake up call for companies that put all their eggs in cloud-based solutions.

Sometimes, brown stuff needs to hit the fan for people to realize the simplest of things.

Cheers!

 

[Darkbreeze]

Well, you can be sure of one thing, brown stuff IS hitting the fan. In large quantities and at very high speeds.

 

[goldstone77]

Spoiler

Linux Will End Up Disabling x86 PTI For AMD Processors - Update: Now Disabled
Written by Michael Larabel in Linux Kernel on 3 January 2018 at 12:45 PM EST.

Update: Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.

Kernel developer Thomas Gleixner wrote in the pull request of disabling KPTI on AMD hardware, "Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead."

Edit: Additional Information
https://meltdownattack.com/meltdown.pdf

6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.

Continue reading after the part that you bolded, concretely the part that says "our implementation might simply be too slow and a more optimized version might succeed."

That is the reason why the Meltdownattack site writes:

Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Yes, I did read it, and that is why I included the whole paragraph. I highlight the reasons Ryzen use in their statements that they are secure. This is a cyber security lab using non public information trying to employ these exploits. Their toy experiment showed a vulnerability, but the lab was unsuccessful in exploiting the vulnerability on AMD and ARM processors. They were successful on Intel processors, which led to the windows and linux patch.

3 A Toy Example
In this section, we start with a toy example, a simple
code snippet, to illustrate that out-of-order execution can
change the microarchitectural state in a way that leaks
information. However, despite its simplicity, it is used as
a basis for Section 4 and Section 5, where we show how
this change in state can be exploited for an attack.

Edit: AMD's statement addressing this

"Our CPUs don't speculate using memory references pointing to locations restricted to higher privilege levels than the running code"

 

[goldstone77]

So what does this mean for AMD users????

AMD says their CPU's are not vulnerable!

But security researchers already demonstrated AMD CPUs are vulnerable. Further info in the spectreattack and meltdownattack sites. Also available on Google security blog entry of yesterday:

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html?m=1

The Project Zero researchers discovered three methods (variants) of attack, which are effective under different conditions. All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc.

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

It is important to understand how the speculative execution vulnerability described in the research relates to AMD products, but please keep in mind the following:

The research described was performed in a controlled, dedicated lab environment by a highly knowledgeable team with detailed, non-public information about the processors targeted.
The described threat has not been seen in the public domain.
When AMD learned that researchers had discovered a new CPU attack targeting the speculative execution functionality used by multiple chip companies’ products, we immediately engaged across the ecosystem to address the teams’ findings.

The research team identified three variants within the speculative execution research. The below grid details the specific variants detailed in the research and the AMD response details.
Variant One Bounds Check Bypass Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.

Edit: Note that all the information pertaining to the blog is located here https://spectreattack.com/

 

[Darkbreeze]

Well, this just keeps getting better and better. (No, it doesn't)

http://www.tomshardware.com/news/meltdown-spectre-exploit-browser-javascript,36221.html

 

[juanrga]

Vulnerability Note VU#584653
CPU hardware vulnerable to side-channel attacks

AMD	Affected	-	03 Jan 2018
Apple	Affected	-	03 Jan 2018
Arm	Affected	-	03 Jan 2018
Google	Affected	-	03 Jan 2018
Intel	Affected	-	03 Jan 2018
Linux Kernel	Affected	-	03 Jan 2018
Microsoft	Affected	-	03 Jan 2018
Mozilla	Affected	-	03 Jan 2018

https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/

Intel has developed and is rapidly issuing updates for all types of Intel-based computer systems — including personal computers and servers — that render those systems immune from both exploits (referred to as “Spectre” and “Meltdown”) reported by Google Project Zero. Intel and its partners have made significant progress in deploying updates as both software patches and firmware updates.

Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. In addition, many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services.

 

[logainofhades]

Yea this is going to turn into a PR nightmare for Intel.

 

[juanrga]

First Spectre patches for AMD are also being developed:

An update that fixes one vulnerability is now available.

Description:

This update for kernel-firmware fixes the following issues:

- Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)

This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html

 

[juanrga]

Google, ARM, Microsoft Issue Statements Regarding Discovered Security Flaws

ARM
This method requires malware running locally and could result in data being accessed from privileged memory. Our Cortex-M processors, which are pervasive in low-power, connected IoT devices, are not impacted.

Google
The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible. For example, an unauthorized party may read sensitive information in the system's memory such as passwords, encryption keys, or sensitive information open in applications. Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.

As soon as we learned of this new class of attack, our security and product development teams mobilized to defend Google's systems and our users' data. We have updated our systems and affected products to protect against this new type of attack. We also collaborated with hardware and software manufacturers across the industry to help protect their users and the broader web. These efforts have included collaborative analysis and the development of novel mitigations.

We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming.

Microsoft
We're aware of this industry-wide issue and have been working closely with chip manufacturers to develop and test mitigations to protect our customers. We are in the process of deploying mitigations to cloud services and have also released security updates to protect Windows customers against vulnerabilities affecting supported hardware chips from Intel, ARM, and AMD. We have not received any information to indicate that these vulnerabilities had been used to attack our customers.

 

[randomizer]

Interesting that Intel claims to have rendered its CPUs immune to Spectre, contrary to what the researchers claim was possible for any CPU (except on an application by application basis).

 

[goldstone77]

https://spectreattack.com/spectre.pdf

8 Conclusions and Future Work
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.

I believe this is why AMD claims a near zero chance of exploit.

As the attack involves currently-undocumented hardware
effects, exploitability of a given software program
may vary among processors.

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.

 

[juanrga]

I believe this is why AMD claims a near zero chance of exploit.

Malicious Spectre code has already been run on AMD CPUs.

Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.

A fix for linux kernel has discussed in a former post from mine. The fix consist on disabling branch prediction on Zen CPUs.

 

[goldstone77]

I believe this is why AMD claims a near zero chance of exploit.

Malicious Spectre code has already been run on AMD CPUs.

Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.

A fix for linux kernel has discussed in a former post from mine. The fix consist on disabling branch prediction on Zen CPUs.

That is a fix for:

Spectre Attack named side channel attack

https://www.suse.com/security/cve/CVE-2017-5715/

 

[goldstone77]

Intel Hit With Three Class Action Lawsuits Related to Security Vulnerability
Alex Cranz
4 minutes ago

Plaintiffs in three different states disagree. As Law.com first noted, a class action complaint was filed January 3rd in United States District Court for the Northern District of California. Since then Gizmodo has found two additional class action complaints filed today (just eleven minutes apart)—one in the District of Oregon and another in the Southern District of Indiana.

All three complaints cite the security vulnerability as well as Intel’s failure to disclose it in a timely fashion. They also cite the supposed slowdown of purchased processors. However that is still up for debate. In a press release today, Intel claimed it has “issued updates for the majority of processor products introduced within the past five years.” Moreover, it says the performance penalty is not as significant as The Register initially claimed.

Intel continues to believe that the performance impact of these updates is highly workload-dependent and, for the average computer user, should not be significant and will be mitigated over time. While on some discrete workloads the performance impact from the software updates may initially be higher, additional post-deployment identification, testing and improvement of the software updates should mitigate that impact.

This claim—of things not being as dire as they seemed—was seconded by Google today. In a post on its Security Blog, Google claimed “we have found that microbenchmarks can show an exaggerated impact,” which seems to suggest that localized attempts to benchmark affected processors before and after the fix has been applied may not yield reliable results.

You can read the class action lawsuits in their entirety on the website.

 

[goldstone77]

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

AMD adds a new graphic to the security update page.

Information Security is a Priority at AMD

I think they are trying to say something here!

 

[goldstone77]

Kaiser security holes will devastate Intel’s marketshare
Analysis: This one tips the balance toward AMD in a big way
Jan 4, 2018 by Charlie Demerjian

Charlie is just blasting away with a double barrel!

 

[-Fran-]

Nah, that won't happen. For all I wish AMD would turn some heads from Intel's way, they won't.

There's more at play in big purchases than technical merit.

Cheers!

 

[goldstone77]

Nah, that won't happen. For all I wish AMD would turn some heads from Intel's way, they won't.

There's more at play in big purchases than technical merit.

Cheers!

I don't know, it's too early to tell I think. Once there are enough independent assessments of the impact I think we can make a bigger judgement call on possible market share repercussions. I think they definitely have a feather in their cap and they will be waving it as hard as they can!

 

[jdwii]

Nah, that won't happen. For all I wish AMD would turn some heads from Intel's way, they won't.

There's more at play in big purchases than technical merit.

Cheers!

Well it most certinaly won't hurt Amd any either they will jump to Arm or Amd no way would they continue to buy newer Intel CPU's until this is fixed at a hardware level.

These "kernel patches" can and will be targeted and hackers know they are their and they know where to look. I see Arm benefiting from this more then Amd even.

 

[randomizer]

I have to say that ARM has responded brilliantly to this.

 

[goldstone77]

I have to say that ARM has responded brilliantly to this.

Absolutely agree and here is a link to there support page. This is how you get in front of an issue, and not deflect the problems onto others!
https://developer.arm.com/support/security-update

 

[Darkbreeze]

I'm surprised nobody has commented on this:

This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?

 

[goldstone77]

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00002.html
An update that fixes one vulnerability is now available.

Description:

This update for ucode-intel fixes the following issues:


The CPU microcode for Haswell-X, Skylake-X and Broadwell-X chipsets was
updated to report both branch prediction control via CPUID flag and
ability to control branch prediction via an MSR register.

This update is part of a mitigation for a branch predictor based
information disclosure attack, and needs additional code in the Linux
Kernel to be active (bsc#1068032 CVE-2017-5715)

Note from the SUSE Security Team
SUSE is aware of the Spectre Attack named side channel attack and will be publishing updates.
https://www.suse.com/security/cve/CVE-2017-5715/

 

[goldstone77]

I'm surprised nobody has commented on this:

This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?

You would think this would have an impact on performance, but hard to say to what extent. Branch prediction is a guess at what information might be needed. I'm sure we will have more benchmarks in the coming days.

Edit:
Benchmarks are coming!
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/998991-google-makes-disclosure-about-the-cpu-vulnerability-affecting-intel-amd-arm/page5