Slashdot Mirror


'Kernel Memory Leaking' Intel Processor Design Flaw Forces Linux, Windows Redesign (theregister.co.uk)

According to The Register, "A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug." From the report: Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in this month's Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December. Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features -- specifically, PCID -- to reduce the performance hit. Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated -- the flaw is in the Intel x86 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or buy a new processor without the design blunder. Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue. The report goes on to share some details of the flaw that have surfaced. "It is understood the bug is present in modern Intel processors produced in the past decade," reports The Register. "It allows normal user programs -- from database applications to JavaScript in web browsers -- to discern to some extent the contents of protected kernel memory. The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI."

6 of 416 comments (clear)

  1. This could be massive by Artem+S.+Tashkinov · · Score: 5, Interesting

    The developers behind the GRSecurity project measured up to 63% performance loss. If most common tasks are equally affected, Intel is sure fucked. Home users might not need to bother, but large cloud providers might be seriously affected.

    Meanwhile the Linux kernel has received the largest incremental minor patch in its history (229KiB) - perhaps kernel 4.14.11 already contains all the required fixes.

    I have a sneaking suspicion Intel shares will fall through the floor in the next few weeks because Intel CPUs might have suddenly become quite slower than their AMD Zen based counterparts.

  2. Re:How could this be abused? by pereric · · Score: 5, Interesting

    Cryptographic keys, information on other processes (making other attacks feasible), perhaps random number generator seeds and status, for example ...
    And the principle in general that there could be information the process is not supposed to reach.

  3. Re:How could this be abused? by EndlessNameless · · Score: 5, Interesting

    Private keys for system-level crypto and user credentials are stored in kernel space. You want everyone on the system to be reading those? If you can read a private key or a Kerberos token, you can become that daemon/system/user.

    This bug essentially destroys local security and severely compromises network security, subject to any limitations on where/when data can be read.

    I'm not a microarchitecture guru who can dig through the details and figure out the limitations of potential attacks. Perhaps only a small portion of kernel memory can be exposed via this bug. I don't really know. The naive, simple scenario where all kernel memory is exposed, though---that is pretty damned bad. Infosec doomsday bad.

    --

    ---
    According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
  4. Intel CEO Sold a lot of stock... by Nos. · · Score: 5, Interesting

    https://www.fool.com/investing...

    Less than a month before we know the linux kernel was being patched for this bug.

  5. ... and this is why ... by nbvb · · Score: 5, Interesting

    This is why we run our mission critical workloads on SPARC and Power along side Linux. Solaris and AIX. Diversity -- in operating system, in processor, in manufacturer - is healthy. The SPARC T8's are blazing faster, secure, and don't have this nonsense. Neither do our POWER8's. Having all your eggs in the Intel+Linux basket could be a major shitshow here... meanwhile, we'll keep chugging along.

  6. Speculative Memory References and Page Faults by bill_mcgonigle · · Score: 5, Interesting

    From the AMD commit:

    AMD processors are not subject to the types of attacks that the kernel
    page table isolation feature protects against. The AMD microarchitecture
    does not allow memory references, including speculative references, that
    access higher privileged data when running in a lesser privileged mode
    when that access would result in a page fault.

    this can probably be rewritten in the inverse like:

    Intel processors ... allow memory references, including speculative references, that
    access higher privileged data when running in a lesser privileged mode, [including]
    when that access would result in a page fault.

    So it seems like: set up a speculative memory reference to a kernel memory structure, cause a page fault, and then get a bit of kernel memory out (and back in?). That could get you root before long. Some people have been saying this can be leveraged to get a guest into its hypervisor too.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)