Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday January 04 2018, @01:04AM   Printer-friendly
from the small-price-to-pay dept.

UPDATE 2: (martyb)

This still-developing story is full of twists and turns. It seems that Intel chips are definitely implicated (AFAICT anything post Pentium Pro). There have been various reports, and denials, that AMD and ARM are also affected. There are actually two vulnerabilities being addressed. Reports are that a local user can access arbitrary kernel memory and that, separately, a process in a VM can access contents of other virtual machines on a host system. These discoveries were embargoed for release until January 9th, but were pre-empted when The Register first leaked news of the issues.

At this time, manufacturers are scrambling to make statements on their products' susceptibility. Expect a slew of releases of urgent security fixes for a variety of OSs, as well as mandatory reboots of VMs on cloud services such as Azure and AWS. Implications are that there is going to be a performance hit on most systems, which may have cascading follow-on effects for performance-dependent activities like DB servers.

To get started, see the very readable and clearly-written article at Ars Technica: What’s behind the Intel design flaw forcing numerous patches?.

Google Security Blog: Today's CPU vulnerability: what you need to know.
Google Project Zero: Reading privileged memory with a side-channel, which goes into detail as to what problems are being addressed as well as including CVEs:

So far, there are three known variants of the issue:

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:

During the course of our research, we developed the following proofs of concept (PoCs):

  1. A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
  2. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
  3. A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
  4. A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

According to a report in Barron's:

AMD said through a spokesperson:

There is a lot of speculation today regarding a potential security issue related to modern microprocessors and speculative execution. As we typically do when a potential security issue is identified, AMD has been working across our ecosystem to evaluate and respond to the speculative execution attack identified by a security research team to ensure our users are protected.

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.

UPDATE 1: (takyon)

Intel statement.

Original story follows

It appears that all modern Intel processors contain a hardware-level security flaw. Details are being suppressed while patches are developed, but it appears that a user process can put a reference to a privileged address in speculative execution, and thereby bypass privilege restrictions.

Since simply marking certain areas of the virtual memory space as privileged is insecure, operating systems will have to completely isolate their kernels, i.e., remove them from the virtual memory space of user processes. This will make context switching more expensive. Presumably, every OS call will now require swapping out the virtual memory map and flushing the page tables cache in the processor. Twice: one to go to the kernel, and once to return to the user process. This will be a significant performance hit: depending on the application, up to 30%.

This is apparently an Intel-specific bug; processors by other manufacturers are not affected. However, they may still suffer the performance hit: The changes to the OS are substantial, and it seems unlikely that OS manufacturers will, in the long-term, maintain two completely different kernel-access strategies for different processors.

Previously: Major Hardware Bug Quietly Being Patched in the Open

A bug that affects Intel processors requires Kernel Page Table Isolation in order to be mitigated:

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

The fix could dramatically lower performance for some workloads:

The Python Sweetness blog, which first reported on the bug, said the vulnerability was first identified by developers working on the Linux kernel, though it also affects Windows operating systems. It added that a number of major security patches for the Linux kernel have been pushed out over the Christmas and New Year holidays, which are likely to be an attempt to fix the new bug. These kernel updates have provided a workaround that can prevent attackers from exploiting the bug, but the problem is that doing so comes at a heavy cost. In technical terms, the fix involves using Kernel Page-Table Isolation or PTI to restrict processes so they can only access their own memory area. However, PTI also affects low-level features in the hardware, resulting in a performance hit of up to 35 percent for older Intel processors.

[...] "Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November," the Python Sweetness blog reported Monday. "In the worst case the software fix causes huge slowdowns in typical workloads." These slowdowns were highlighted by Brad Spengler, lead developer of grsecurity, which is a set of patches for the Linux kernel which emphasize security enhancements. According to HotHardWare, Spengler said an Intel Core i7-3770S GPU will take a 34 percent performance hit, while the new Intel Core i7-6700 will run 29 percent slower.

The Linux fix can be disabled, which you will likely want to do if you use an AMD processor.

December 19, 2017: Intel's CEO Just Sold a Lot of Stock

Did Krzanich use that money to buy AMD stock?

[See also: How-To Geek, Phoronix, and Security Week. --martyb]

An Anonymous Coward contributed Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR.


Original Submission 1

Original Submission 2

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Insightful) by Anonymous Coward on Wednesday January 03 2018, @05:26PM (23 children)

    by Anonymous Coward on Wednesday January 03 2018, @05:26PM (#617229)

    I doubt the average Joe benefits in any way from this patch. Anything worth knowing about a system like that already resides in ring3 and is readily grabbable if the user allows random code to execute (which is a necessity to leverage this). Unless this allows code to be injected into ring0 I don't see how this is as severe as it is made out to be from the scant information that is available right now. There are trivial ways to defeat ASLR type defenses if code is allowed to execute and the offset of the code in the file is known, simple arithmetic, no exploit.

    Starting Score:    0  points
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  

    Total Score:   1  
  • (Score: 4, Insightful) by TheRaven on Wednesday January 03 2018, @05:46PM (22 children)

    by TheRaven (270) on Wednesday January 03 2018, @05:46PM (#617243) Journal

    It's still under embargo (and was meant to be until the 9th, but the Linux people were oh-so-clever and leaked it - I hope Intel won't give them embargoed security reports in the future), so this is speculation:

    If this were just a KASLR bypass, it some of the people who are preparing patches wouldn't be involved, so it's almost certainly more than that. It's either kernel memory disclosure or kernel memory modification. In either case, normal users should care because they typically rely on the kernel for sandboxing. If you run Chrome, Edge, or Safari, the part of the program that deals with untrusted data is run in a de-privileged process with fairly narrow communication channels to the parent. Going from being able to inject code that can trigger, for example, a libpng or libavcodec vulnerability in the browser to being able to run code outside of this process usually requires chaining together a load of different vulnerabilities. With this, you have the possibility of writing an exploit that works reliably on any x86 operating system and browser and will let you jump out of the sandbox. That's very bad. Even if it's 'just' arbitrary kernel memory disclosure, there are often ways of turning that into privilege escalation.

    --
    sudo mod me up
    • (Score: 5, Insightful) by takyon on Wednesday January 03 2018, @05:48PM (7 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @05:48PM (#617246) Journal

      (and was meant to be until the 9th, but the Linux people were oh-so-clever and leaked it - I hope Intel won't give them embargoed security reports in the future)

      I hope Intel loses market share and billions of dollars because of this.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @06:01PM

        by Anonymous Coward on Wednesday January 03 2018, @06:01PM (#617258)

        Haven't you heard? The new business strategy is:

        1. Get enough market share and label yourself "too big to fail"
        2. Do whatever you can to get the most money
        3. Cry when things go bad, get bailed out

        It is a pretty foolproof plan, the hard part is getting the initial market share. After that you pay some idiots to push PR and you continue business as usual. Perhaps we'll get a miracle, I'm sure AMD will get a nice bump, but I'm not gonna hold my breath.

      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @07:56PM (4 children)

        by Anonymous Coward on Wednesday January 03 2018, @07:56PM (#617312)

        Intel will likely throw some money around behind the scenes to ensure that Microsoft, Apple and Red Hat do not make a conditional check in their kernels that lets AMD cpus run unfettered.

        Of course it will be termed exactly that way - "too complicated to conditionally implement (for small minority of our customers)", along with some form of "you amd fanbois can choose a cup or a towel for your tears" conceit.

        At least from Linux side it looks like a simple flag to bypass the problem for AMD, perhaps with a kernel recompile. But I'm sure Pottering and its minions are working on a way to "fix" things in systemd too.

        • (Score: 2) by Grishnakh on Wednesday January 03 2018, @08:08PM (2 children)

          by Grishnakh (2831) on Wednesday January 03 2018, @08:08PM (#617318)

          Intel will likely throw some money around behind the scenes to ensure that Microsoft, Apple and Red Hat do not make a conditional check in their kernels that lets AMD cpus run unfettered.... At least from Linux side it looks like a simple flag to bypass the problem for AMD, perhaps with a kernel recompile. But I'm sure Pottering and its minions are working on a way to "fix" things in systemd too.

          Red Hat is only one of many, many Linux distros. Debian surely wouldn't adopt such a thing, since Debian isn't even a corporation, and all the Debian derivatives are unlikely to follow RH's lead too.

          As for systemd, that seems like a silly accusation. systemd is many things, but it's not a kernel, and AFAICT here, this fix is something purely inside the kernel, not something that could somehow be baked into systemd to force all kernels on both Intel and AMD CPUs to work this way.

          No, I think this is something that Intel isn't going to be able to hide from with any shenanigans. It's just too easy to use a different Linux distro, or compile your own kernel, esp. if the kernel team isn't complicit and makes it easy to enable or disable this fix depending on the CPU it's running on (they could perhaps even make it automatic--a simple runtime check at kernel boot-up could allow the kernel to see what it's running on and adopt the correct strategy). Then it'll be easy for anyone who can run some benchmarks on Linux to show just how awful performance is on Intel CPUs compared to AMD ones, and publish the results.

          What sucks is that the selection of AMD CPUs just isn't very good: I can't easily purchase a business-grade laptop with an AMD processor. Lenovo doesn't use them, Dell doesn't use them (for the Latitudes), and HP doesn't use them (for their ugly business laptops, whatever they're called). You have to resort to some plastic-cased crappy-keyboard consumer laptop to get an AMD, as far as I can tell. Hopefully the business laptop makers will start offering AMDs now.

          • (Score: 4, Funny) by driverless on Thursday January 04 2018, @03:44AM (1 child)

            by driverless (4770) on Thursday January 04 2018, @03:44AM (#617500)

            As for systemd, that seems like a silly accusation. systemd is many things, but it's not a kernel

            Has anyone told systemd that?

            • (Score: 2) by crafoo on Thursday January 04 2018, @08:22AM

              by crafoo (6639) on Thursday January 04 2018, @08:22AM (#617585)

              I'm pretty sure SunnyD is a mostly successful attempt by the NSA to co-opt and backdoor linux.

        • (Score: 3, Insightful) by NewNic on Thursday January 04 2018, @01:24AM

          by NewNic (6420) on Thursday January 04 2018, @01:24AM (#617454) Journal

          Microsoft, maybe. But RedHat can't afford to do this, since it the first person who looks at their kernel packages (no doubt someone at AMD) will discover what has been done and cry foul!

          --
          lib·er·tar·i·an·ism ˌlibərˈterēənizəm/ noun: Magical thinking that useful idiots mistake for serious political theory
      • (Score: 1) by fustakrakich on Thursday January 04 2018, @04:34AM

        by fustakrakich (6150) on Thursday January 04 2018, @04:34AM (#617513) Journal

        I hope Intel loses market share

        To whom? We don't have the alpha chip anymore. Maybe IBM's power chip can come through...

        --
        La politica e i criminali sono la stessa cosa..
    • (Score: 1, Interesting) by Anonymous Coward on Wednesday January 03 2018, @05:50PM

      by Anonymous Coward on Wednesday January 03 2018, @05:50PM (#617248)

      Leave non-Internetty things running as usual.

      Hell, you could even run certain trusted website code without the new protections. It just won't matter in the end; all of the headache will belong to the programmers, not the users.

    • (Score: 5, Informative) by Anonymous Coward on Wednesday January 03 2018, @05:55PM (8 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:55PM (#617250)

      The key detail was leaked on the linux-kernel mailing list, but not by some random Linux developer. It was leaked by an AMD employee who was providing a patch to exclude AMD processors from the bug work-around.

      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:56PM

        by Anonymous Coward on Wednesday January 03 2018, @05:56PM (#617253)

        Might be FUD in that case. The bug is certainly real, but if all the speculation is based on that it's pretty suspect.

      • (Score: -1, Informative) by Anonymous Coward on Wednesday January 03 2018, @06:19PM (1 child)

        by Anonymous Coward on Wednesday January 03 2018, @06:19PM (#617267)
         
        • (Score: -1, Offtopic) by Anonymous Coward on Wednesday January 03 2018, @06:27PM

          by Anonymous Coward on Wednesday January 03 2018, @06:27PM (#617270)

          Is this rabid praise or feral bleating?

      • (Score: 3, Informative) by MrGuy on Wednesday January 03 2018, @07:28PM (2 children)

        by MrGuy (1007) on Wednesday January 03 2018, @07:28PM (#617302)

        Wait - what??? Citation needed.

        If I read your comment correctly, the flaw was identified, and a fix was identified, on the linux-kernel mailing list. That's a public forum. [lkml.org]

        You're saying an AMD employee making a patch ON TOP OF the patch to fix the Intel issue to exclude unaffected AMD processors is the point where the issue was "leaked" to the public?

        How does THAT work? How could the AMD patch to exclude AMD processors precede a discussion/patch to fix the issue on Intel processors? There was zero discussion on the linux-kernel list of the issue before the AMD patch-to-a-patch was suggested?

        • (Score: 4, Informative) by Anonymous Coward on Wednesday January 03 2018, @08:09PM

          by Anonymous Coward on Wednesday January 03 2018, @08:09PM (#617320)

          https://lkml.org/lkml/2017/12/27/2 [lkml.org]

          His second sentence gives away the key info.

          Prior to that, the description of the bug was still pretty vague. Now we have some excellent guesses. We can be almost certain that this is a timing-related attack on the kernel address space.

        • (Score: 2) by stretch611 on Thursday January 04 2018, @05:24PM

          by stretch611 (6199) on Thursday January 04 2018, @05:24PM (#617812)

          While an AMD employee did go into details about the reason for the patch...

          He did so to explain why AMD processors are not affected by the bug.

          Also, it should be noted that some reports are mentioning at 5-30% performance decrease due to the patch. (mostly on server workloads such as databases)

          Now, If you were working at Intel, wouldn't you prefer the patch to decrease the competitor's performance just as bad as yours is being hit?

          I mean if the AMD employee did not speak up, the patch would have slowed down AMD processors unnecessarily. Now AMD can boast a relative boost in server performance over Intel, while also mentioning that they are not creating additional maintenance costs due to the workload of installing software patches to correct bad hardware.

          Mind you, this is one of the specific flaws being patched, not all that are likely happening. Also, based on the comments to the maillist message here [lkml.org], provided by an AC in this discussion. The comments in the message clearly show that "/* Assume for now that ALL x86 CPUs are insecure */" until the AMD employee provided code to bypass the fix along with an explanation for AMD processors.

          --
          Now with 5 covid vaccine shots/boosters altering my DNA :P
      • (Score: 2) by TheRaven on Thursday January 04 2018, @09:09AM (1 child)

        by TheRaven (270) on Thursday January 04 2018, @09:09AM (#617591) Journal
        That email wouldn't have happened if other Linux developers were not committing patches in public, during the embargo period. The AMD email just said 'we're not vulnerable to this', it was the previous patch set that made enough information public for people to be able to guess the vulnerability.
        --
        sudo mod me up
        • (Score: 2) by moondrake on Thursday January 04 2018, @10:17PM

          by moondrake (2658) on Thursday January 04 2018, @10:17PM (#618011)

          the patches were pretty cryptic to almost all people.

          AMD specified what exactly your "this" is.

          So it is a little bit unfair to put the blame on linux. We already knew from NT kernels that something was going on related to memory management.

          Of course, you could spin it to blame linux .

    • (Score: 2) by takyon on Wednesday January 03 2018, @06:12PM (3 children)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @06:12PM (#617264) Journal

      I hope Intel won't give them embargoed security reports in the future

      Maybe we should give Intel's CEO a jail cell for selling as much stock as possible during the embargo.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 2) by frojack on Wednesday January 03 2018, @07:05PM

        by frojack (1554) on Wednesday January 03 2018, @07:05PM (#617289) Journal

        Since they sell stock as a matter of pre-programmed trades (outside of their personal control), any change of pattern during the embargo would constitute insider trading.

        --
        No, you are mistaken. I've always had this sig.
      • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @07:53AM

        by Anonymous Coward on Thursday January 04 2018, @07:53AM (#617580)

        I'm sure he's too rich to jail.

      • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @11:31AM

        by Anonymous Coward on Thursday January 04 2018, @11:31AM (#617621)

        He'll just run to the safe haven that is Intel's home now. Which speaks volumes.