Sticky

Meltdown and Spectre Vulnerabilities Information

https://spectreattack.com/


Quote:

Meltdown and Spectre
Bugs in modern computers leak passwords and sensitive data.


Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents.

Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider's infrastructure, it might be possible to steal data from other customers.


Quote:

Questions & Answers
Am I affected by the bug?

Most certainly, yes.

Can I detect if someone has exploited Meltdown or Spectre against me?
Probably not. The exploitation does not leave any traces in traditional log files.

Can my antivirus detect or block this attack?
While possible in theory, this is unlikely in practice. Unlike usual malware, Meltdown and Spectre are hard to distinguish from regular benign applications. However, your antivirus may detect malware which uses the attacks by comparing binaries after they become known.

What can be leaked?
If your system is affected, our proof-of-concept exploit can read the memory content of your computer. This may include passwords and sensitive data stored on the system.

Has Meltdown or Spectre been abused in the wild?
We don't know.

Is there a workaround/fix?
There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .

Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, 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). We successfully tested Meltdown on Intel processor generations released as early as 2011. 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.

Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Which cloud providers are affected by Meltdown?
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.

What is the difference between Meltdown and Spectre?
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers ( Meltdown and Spectre)

Why is it called Meltdown?
The bug basically melts security boundaries which are normally enforced by the hardware.

Why is it called Spectre?
The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.

Is there more technical information about Meltdown and Spectre?
Yes, there is an academic paper and a blog post about Meltdown, and an academic paper about Spectre. Furthermore, there is a Google Project Zero blog entry about both attacks.

What are CVE-2017-5753 and CVE-2017-5715?
CVE-2017-5753 and CVE-2017-5715 are the official references to Spectre. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.

What is the CVE-2017-5754?
CVE-2017-5754 is the official reference to Meltdown. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.


https://spectreattack.com/spectre.pdf

https://meltdownattack.com/meltdown.pdf

Motherboard Bios Update:

Dell

http://www.dell.com/support/article/us/en/04/sln308587/microprocessor-side-channel-vulnerabilities--cve-2017-5715--cve-2017-5753--cve-2017-5754---impact-on-dell-products?lang=en
Asus
https://www.asus.com/News/V5urzYAT6myCC1o2
MSI
https://www.msi.com/news/detail/FpUpzUbcvgecc4SqcsaMmbzSOXEcIxys45KR9AJWEure3UmryqhcXl6SLdJEqNKirRs7p-1Ne6bp0VLtef3YSg~~
Microsoft Surface
https://support.microsoft.com/en-us/help/4073065/surface-guidance-to-protect-against-speculative-execution-side-channel
GIGABYTE
https://www.gigabyte.com/MicroSite/481/intel-sa-00088.html
Fujitsu
https://www.fujitsu.com/global/support/products/software/security/products-f/jvn-93823979e.html
HP
https://support.hp.com/us-en/document/c05869091
Lenovo
https://support.lenovo.com/us/en/solutions/len-18282
Toshiba
https://support.toshiba.com/
Samsung
https://www.samsung.com/us/support/?CID=AFL-hq-mul-0813-11000946
LG
http://www.lg.com/us/support
Acer
https://www.acer.com/ac/en/US/content/support
Panasonic.
https://pc-dl.panasonic.co.jp/itn/vuln/g18-001.html
Asrock
http://www.asrock.com/support/index.asp?cat=BIOS
346 answers Last reply
More about cpu security vulnerabilities information
  1. 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.

    Quote:

    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
    Quote:

    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.


    2nd Edit: Additional Information
    Quote:

    Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipHEADmaster
    Pull x86 page table isolation fixes from Thomas Gleixner:

    "A couple of urgent fixes for PTI:

    - Fix a PTE mismatch between user and kernel visible mapping of the
    cpu entry area (differs vs. the GLB bit) and causes a TLB mismatch
    MCE on older AMD K8 machines

    - Fix the misplaced CR3 switch in the SYSCALL compat entry code which
    causes access to unmapped kernel memory resulting in double faults.

    - Fix the section mismatch of the cpu_tss_rw percpu storage caused by
    using a different mechanism for declaration and definition.

    - Two fixes for dumpstack which help to decode entry stack issues
    better

    - Enable PTI by default in Kconfig. We should have done that earlier,
    but it slipped through the cracks.

    - Exclude AMD from the PTI enforcement. Not necessarily a fix, but if
    AMD is so confident that they are not affected, then we should not
    burden users with the overhead"


    * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86/process: Define cpu_tss_rw in same section as declaration
    x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat()
    x86/dumpstack: Print registers for first stack frame
    x86/dumpstack: Fix partial register dumps
    x86/pti: Make sure the user/kernel PTEs match
    x86/cpu, x86/pti: Do not enable PTI on AMD processors
    x86/pti: Enable PTI by default

    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce&utm_source=anz
  2. So basically, there are two separate issues:

    Meltdown: Confirmed on Intel CPUs. Believed AMD and ARM CPUs unaffected, or at the very least not affected in the same way. OS level fixes are being implemented.

    Specter: Affects all Intel, AMD, and ARM CPUs. There is no current solution that works across the board.

    Basically: Every consumer level CPU released since the mid to late 90's have had gaping security holes. One of them appears Intel specific and is being fixed, the other affects everyone and is not.

    Fun times.
  3. January 3, 2018—KB4056892 (OS Build 16299.192)
    Quote:
    Applies to: Windows 10 version 1709
    Improvements and fixes
    This update includes quality improvements. No new operating system features are being introduced in this update. Key changes include:

    Addresses issue where event logs stop receiving events when a maximum file size policy is applied to the channel.
    Addresses issue where printing an Office Online document in Microsoft Edge fails.
    Addresses issue where the touch keyboard doesn’t support the standard layout for 109 keyboards.
    Addresses video playback issues in applications such as Microsoft Edge that affect some devices when playing back video on a monitor and a secondary, duplicated display.
    Addresses issue where Microsoft Edge stops responding for up to 3 seconds while displaying content from a software rendering path.
    Addresses issue where only 4 TB of memory is shown as available in Task Manager in Windows Server version 1709 when more memory is actually installed, configured, and available.
    Security updates to Windows SMB Server, the Windows Subsystem for Linux, Windows Kernel, Windows Datacenter Networking, Windows Graphics, Microsoft Edge, Internet Explorer, and the Microsoft Scripting Engine.
    If you installed earlier updates, only the new fixes contained in this package will be downloaded and installed on your device.

    Manual Download Link
    http://www.catalog.update.microsoft.com/Search.aspx?q=KB4056892
  4. gamerk316 said:
    So basically, there are two separate issues:

    Meltdown: Confirmed on Intel CPUs. Believed AMD and ARM CPUs unaffected, or at the very least not affected in the same way. OS level fixes are being implemented.

    Specter: Affects all Intel, AMD, and ARM CPUs. There is no current solution that works across the board.

    Basically: Every consumer level CPU released since the mid to late 90's have had gaping security holes. One of them appears Intel specific and is being fixed, the other affects everyone and is not.

    Fun times.

    Meltdown I believe you are correct.
    I believe they are using software to help mitigate Spectre, but there is no fix for any X86 platform.
  5. EXPLAINED: 'Meltdown' and 'Spectre' — the massive Google-discovered security exploits that have Silicon Valley in a tizzy
    Matt Weinberger


    Quote:
    It's just as important to make sure you stay up-to-date. While Spectre may not have an easy fix, Google says that there are ways to guard against related exploits. Expect Microsoft, Apple, and Google to issue a series of updates to their operating systems as new Spectre-related attacks are discovered.

    Additionally, because Meltdown and Spectre require malicious code to already be running on your system, let this be a reminder to practice good online safety behaviors. Don't download any software from a source you don't explicitly trust. And don't click on any links or files claiming you won $10 million in a contest you never entered.
  6. goldstone77 said:
    gamerk316 said:
    So basically, there are two separate issues:

    Meltdown: Confirmed on Intel CPUs. Believed AMD and ARM CPUs unaffected, or at the very least not affected in the same way. OS level fixes are being implemented.

    Specter: Affects all Intel, AMD, and ARM CPUs. There is no current solution that works across the board.

    Basically: Every consumer level CPU released since the mid to late 90's have had gaping security holes. One of them appears Intel specific and is being fixed, the other affects everyone and is not.

    Fun times.

    Meltdown I believe you are correct.
    I believe they are using software to help mitigate Spectre, but there is no fix for any X86 platform.


    For Spectre, they're basically patching each individual application as problems are found, which essentially means "yeah, there's not much we can do as far as prevention goes".
  7. What We Know So Far About Meltdown and Spectre, the Devastating Vulnerabilities in Modern CPUs
    Tom McKay and Alex Cranz
    Yesterday 9:50pm

    Quote:

    This week, news of massive security vulnerabilities afflicting every modern model of Intel processor went public, even as developers for practically every major platform frantically rushed to roll out fixes. Much more information has now become available about Meltdown and Spectre, a group of attack methods malicious parties could use to break into some of the most sensitive inner workings of any device using the affected CPUs.

    Here’s what we know so far.

    What’s the problem?
    In 2017, Google’s Project Zero team in collaboration with researchers at a number of different universities identified an absolutely massive problem with speculative execution, one of the techniques employed in modern microprocessors as a way of improving performance.
    Essentially, when a processor uses speculative execution, instead of performing tasks strictly sequentially, it predicts which calculations it might need to do subsequently. It then solves them in advance and in parallel fashion. The result is that the CPU wastes some cycles performing unnecessary calculations, but performs chains of commands much faster than if it waited to process them one after the other.

    However, there’s a serious flaw in the way modern processors are hardcoded to use speculative execution—they don’t check permissions correctly and leak information about speculative commands that don’t end up being run. Whoops.

    As a result, user programs can possibly steal glimpses at protected parts of the kernel memory. That’s memory dedicated to the most essential core components of an operating system and their interactions with system hardware, and it’s supposed to be isolated from user processes at all times to prevent such glimpses from happening. Everything from passwords to stored files could be compromised as a result.

    According to a release by the Graz University of Technology, the researchers have identified three potential attack methods, Meltdown and two closely-related vulnerabilities collectively named Spectre:

    Quote:

    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.

    ...

    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.

    Quote:

    As ZDNet wrote, a worst-case scenario is that a low-level user could run JavaScript code hosted on a webpage and gain access to kernel memory. As TechCrunch noted, another worst-case scenario is users on cloud services that share hardware resources being able to peek on other clients’ operations.
    There’s no way to truly fix Meltdown or Spectre on the hardware level. It can’t be fixed with a microcode update.

    But researchers can rewrite OSes and other platforms to work around the error by severing kernel memory entirely from user processes with a method called Kernel Page Table Isolation—though as the Register noted, the cost might be processors working up to five to 30 percent slower depending on the model and task. Cloud-based services like Amazon and Google servers are likely to be the hardest hit, while it’s possible the impact on home users could be negligible. Meltdown is more easily patched than Spectre, which security researcher Daniel Gruss told ZDNet is “going to haunt us for years.”

    Intel CEO Brian Krzanich told CNBC that Google alerted them of the flaw some time ago, but it leaked ahead of time because “Somebody was doing some updates on a Linux kernel and they improperly posted that this was due to this flaw.”

    Who’s impacted?
    Since this is a hardware bug, everything running on affected processors is vulnerable including every major OS (Windows, Linux, and macOS), some mobile devices, and cloud computing providers.

    Originally, the Register reported, only Intel processors (which dominate the U.S. market) were believed to be subject to the flaw. But it’s become clear that a wide range of processor types could be affected, with Google writing that AMD, ARM, and other devices were also vulnerable—though only partially and with less performance impact following a fix than Intel-based devices.

    In a statement to Gizmodo, AMD said that of the three attack variants, one was easily resolved with “negligible performance impact,” while the others have “near zero risk” or “zero risk” due to “architecture differences.”

    ARM told Gizmodo that it has been working “together with Intel and AMD to address a side-channel analysis method which exploits speculative execution techniques used in certain high-end processors, including some of our Cortex-A processors. This is not an architectural flaw; this method only works if a certain type of malicious code is already running on a device and could at worst result in small pieces of data being accessed from privileged memory.”

    Qualcomm did not immediately respond to a request for comment.

    On the mobile side, per Reuters, it’s unclear whether Apple needs to patch the OS running on iPhones and iPads. According to ZDNet, many Android devices are likely impacted but “given the failure or tardiness of many Android vendors to update their devices with security updates, many on the mobile operating system are likely to remain vulnerable until a new phone is purchased.”

    What are companies doing about it?
    Companies are rushing to patch platforms. Per Axios, Microsoft has already patched Windows 10 and will release patches for Windows 7 and 8, Amazon Elastic Compute Cloud is already mostly secured, AMD is still investigating, and ARM is still working on how to address the issue. Apple did not respond to Axios’ request for comment, though security researcher Alex Ionescu tweeted it already released an initial fix for its desktop-based macOS in December 2017's 10.13.2.
    “We’ve found no instances of anybody actually executing this exploit,” Krzanich told CNBC. “... I mean, it’s very hard—we can’t go out and check every system out there. But when you take a look at the difficulty it is to actually go and execute this exploit—you have to get access to the systems, and then access to the memory and operating system—we’re fairly confident, given the checks we’ve done, that we haven’t been able to identify an exploit yet.”
  8. gamerk316 said:
    goldstone77 said:
    gamerk316 said:
    So basically, there are two separate issues:

    Meltdown: Confirmed on Intel CPUs. Believed AMD and ARM CPUs unaffected, or at the very least not affected in the same way. OS level fixes are being implemented.

    Specter: Affects all Intel, AMD, and ARM CPUs. There is no current solution that works across the board.

    Basically: Every consumer level CPU released since the mid to late 90's have had gaping security holes. One of them appears Intel specific and is being fixed, the other affects everyone and is not.

    Fun times.

    Meltdown I believe you are correct.
    I believe they are using software to help mitigate Spectre, but there is no fix for any X86 platform.


    For Spectre, they're basically patching each individual application as problems are found, which essentially means "yeah, there's not much we can do as far as prevention goes".


    Well, yes, but it looks like it's not easy to do, and your system has to first be infected by malware. Only download trusted software can probably help mitigate chances of malware infection. Everyone should run script blocking extensions, and malware detection/prevention programs. Also, keep an eye out for new security patches that we should see rolling out across many different platforms with the IOT's this could be expansive, or on the other hand just leaving a bunch of gaps open for entry!
  9. “Meltdown” and “Spectre”: Every modern processor has unfixable security flaws
    Immediate concern is for Intel chips, but everyone is at risk.
    PETER BRIGHT - 1/3/2018, 7:30 PM

    Quote:

    Spectre
    Owners of AMD and ARM systems shouldn't rest easy, though, and that's thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.

    Moreover, Spectre doesn't offer any straightforward solution. Speculation is essential to high performance processors, and while there may be limited ways to block certain certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren't known.

    Sensitive pieces of code could be amended to include "serializing instructions"—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.

    In the immediate term, it looks like most systems will shortly have patches for Meltdown. At least for Linux and Windows, these patches allow end-users to opt out if they would prefer. The most vulnerable users are probably cloud service providers; Meltdown and Spectre can both in principle be used to further attacks against hypervisors, making it easier for malicious user to break out of their virtual machines.

    For typical desktop users, the risk is arguably less significant. While both Meltdown and Spectre can have value in expanding the scope of an existing flaw, neither one is sufficient on its own to, for example, break out of a Web browser.

    Longer term, we'd expect a future Intel architecture to offer some kind of a fix, either by avoiding speculation around this kind of problematic memory access, or making the memory access permission checks faster so that this time interval between reading kernel memory, and checking that the process has permission to read kernel memory, is eliminated.


    https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-273.html
    8.3 SERIALIZING INSTRUCTIONS
    Quote:

    The Intel 64 and IA-32 architectures define several serializing instructions. These instructions force the
    processor to complete all modifications to flags, registers, and memory by previous instructions and to drain all
    buffered writes to memory before the next instruction is fetched and executed. For example, when a MOV to
    control register instruction is used to load a new value into control register CR0 to enable protected mode, the
    processor must perform a serializing operation before it enters protected mode. This serializing operation ensures
    that all operations that were started while the processor was in real-address mode are completed before the switch
    to protected mode is made.
    The concept of serializing instructions was introduced into the IA-32 architecture with the Pentium processor to
    support parallel instruction execution. Serializing instructions have no meaning for the Intel486 and earlier proces-
    sors that do not implement parallel instruction execution.
    It is important to note that executing of serializing instructions on P6 and more recent processor families constrain
    speculative execution because the results of speculatively executed instructions are discarded. The following
    instructions are serializing instructions:
    •Privileged serializing instructions — INVD, INVEPT, INVLPG, INVVPID, LGDT, LIDT, LLDT, LTR, MOV (to
    control register, with the exception of MOV CR83), MOV (to debug register), WBINVD, and WRMSR4.
    •Non-privileged serializing instructions — CPUID, IRET, and RSM.
  10. Linux doesn't seem overly impressed with Intel :lol:

    https://lkml.org/lkml/2018/1/3/797
  11. At this point in time we have no idea on what is going on we must wait and see rumors and speculation mean nothing facts is the only thing i'm interested in. So far it seems that in part Amd processors are affected but not nearly as much as Intel and Arm is also affected.

    This is major and embarrassing for all companies shortcuts is something a law suite should solve

    Amd claims this does not affect their CPU's Lisa Su herself said it so lets wait and see.
  12. Sticky this?

    I'll leave it to you randomizer. I'm going to bed. :P
  13. Linus has merged in the patch which excludes AMD CPUs from the fix (unless you turn it on manually): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce
  14. anort3 said:
    Sticky this?

    I'll leave it to you randomizer. I'm going to bed. :P


    I was thinking about it. We do have an imperial ton of stickies already, but this is fairly important, so it probably warrants a sticky, if only temporarily.
  15. randomizer said:
    Linus has merged in the patch which excludes AMD CPUs from the fix (unless you turn it on manually): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a5ae218d57741088068799b810416ac249a9ce


    Good as stated before it was only a matter of time they just had to fix the issue as fast as possible exceptions was always going to be made.
  16. randomizer said:
    Linux doesn't seem overly impressed with Intel :lol:

    https://lkml.org/lkml/2018/1/3/797


    Well, if you look at the post I made on serialization:
    Quote:
    The concept of serializing instructions was introduced into the IA-32 architecture with the Pentium processor to
    support parallel instruction execution. Serializing instructions have no meaning for the Intel486 and earlier proces-
    sors that do not implement parallel instruction execution.
    It is important to note that executing of serializing instructions on P6 and more recent processor families constrain
    speculative execution because the results of speculatively executed instructions are discarded. The following
    instructions are serializing instructions:


    It's been around for a while now, so I can see why he would be "frustrated."
  17. https://www.amd.com/en/corporate/speculative-execution

    Edit: Don't forget to update your OS!
  18. goldstone77 said:
    It's been around for a while now, so I can see why he would be "frustrated."

    He is frustrated because Intel has done nothing but put out PR statements to deflect damage.
  19. goldstone77 said:


    So what does this mean for AMD users????
  20. Benchmarking The Intel CPU Bug Fix, What Can Desktop Users Expect?
    Hardware Unboxed
    Published on Jan 4, 2018




    Looks like 8700K benchamarks show that desktop users will not be affected by the recent patch. Only high I/O devices like NVME seem to be affected.
  21. jdwii said:


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


    AMD says their CPU's are not vulnerable!

    Edit: You just need to get your OS update! I posted a link with the information to manually download the Windows patch.
  22. goldstone77 said:
    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.

    Quote:

    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
    Quote:

    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:

    Quote:
    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.
  23. gamerk316 said:
    So basically, there are two separate issues:

    Meltdown: Confirmed on Intel CPUs. Believed AMD and ARM CPUs unaffected, or at the very least not affected in the same way. OS level fixes are being implemented.

    Specter: Affects all Intel, AMD, and ARM CPUs. There is no current solution that works across the board.

    Basically: Every consumer level CPU released since the mid to late 90's have had gaping security holes. One of them appears Intel specific and is being fixed, the other affects everyone and is not.

    Fun times.


    The Spectre attacks affects virtually any modern CPU, not only those from AMD, ARM, or Intel. It seems a full solution of the problem will require a rethink of the design of modern CPUs.
  24. goldstone77 said:
    jdwii said:


    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:

    Quote:
    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
  25. 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!
  26. Well, you can be sure of one thing, brown stuff IS hitting the fan. In large quantities and at very high speeds.
  27. juanrga said:
    goldstone77 said:
    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.

    Quote:

    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
    Quote:

    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:

    Quote:
    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.
    Quote:

    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
    Quote:
    "Our CPUs don't speculate using memory references pointing to locations restricted to higher privilege levels than the running code"
  28. juanrga said:
    goldstone77 said:
    jdwii said:


    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:

    Quote:
    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


    Quote:

    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:
    Quote:

    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/
  29. Well, this just keeps getting better and better. (No, it doesn't)

    http://www.tomshardware.com/news/meltdown-spectre-exploit-browser-javascript,36221.html
  30. 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/

    Quote:
    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.
  31. Yea this is going to turn into a PR nightmare for Intel.
  32. First Spectre patches for AMD are also being developed:

    Quote:
    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
  33. 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.
  34. 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).
  35. https://spectreattack.com/spectre.pdf
    Quote:

    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.
    Quote:

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

    Quote:

    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.
  36. goldstone77 said:
    I believe this is why AMD claims a near zero chance of exploit.


    Malicious Spectre code has already been run on AMD CPUs.

    Quote:
    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.
  37. juanrga said:
    goldstone77 said:
    I believe this is why AMD claims a near zero chance of exploit.


    Malicious Spectre code has already been run on AMD CPUs.

    Quote:
    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:
    Quote:
    Spectre Attack named side channel attack

    https://www.suse.com/security/cve/CVE-2017-5715/
  38. Intel Hit With Three Class Action Lawsuits Related to Security Vulnerability
    Alex Cranz
    4 minutes ago

    Quote:

    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.

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

    AMD adds a new graphic to the security update page.
    Quote:
    Information Security is a Priority at AMD

    I think they are trying to say something here!
  40. 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!
  41. Yuka said:
    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!
  42. Yuka said:
    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.
  43. I have to say that ARM has responded brilliantly to this.
  44. randomizer said:
    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
  45. I'm surprised nobody has commented on this:

    Quote:
    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?
  46. 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/
  47. darkbreeze said:
    I'm surprised nobody has commented on this:

    Quote:
    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
Ask a new question

Read More

Security vulnerability CPUs meltdown spectre