back to article Boffins exploit Intel CPU weakness to run rings around code defenses

US researchers have pinpointed a vulnerability in Intel chips – and possibly other processor families – that clears the way for circumventing a popular operating-system-level security control. ASLR (address space layout randomization) is widely used as a defense against attempts by hackers to exploit software vulnerabilities …

  1. Anonymous Coward
    Anonymous Coward

    This sounds a lot like the CRIME attack in that a miscreant can take advantage of some efficiency improvement (compression in CRIME, a lookup table here) to circumvent obfuscation. Which kind of puts you in a bind since in the last the only way to block these kinds of exploits is to run code INefficiently, which has consequences of their own.

  2. Destroy All Monsters Silver badge
    Pint

    Neo code!

    So you can guess the contents of the Branch Target Buffer from user-level software using timing? That's pretty meta. We might find that "destroy on read" Quantum Mechanics is Nature's surefire way to prevent any breakouts from Her Virtual Machine.

    The hack takes advantage of the CPU's branch target buffer, a mechanism present in many microprocessor architectures including Intel Haswell CPUs.

    In most CPUs since the 90's I would guess.

    The paper has some recommendations though:

    A hardware solution that would fundamentally mitigate the BTB-based attacks is to change the BTB addressing mechanism in a way that prevents exploitable collisions in the BTB. The attack against KASLR can be mitigated by using full virtual address for accessing the BTB, thus eliminating collisions between the user code and the kernel code. This would require adding extra bits in the BTB, as the tag size will increase significantly (by 17 bits compared to Haswell implementation for 48-bit virtual addresses). Alternatively, the BTB can use different indexing functions for user and kernel-level code. For example, a secret value can be added to the existing BTB hash function when the CPU is executing in the kernel mode. To prevent the user process from discovering this value and reverse-engineering the hash function, this value can be randomized during each system’s boot.

    1. I am the liquor
      Mushroom

      Re: Neo code!

      "We might find that "destroy on read" Quantum Mechanics is Nature's surefire way to prevent any breakouts from Her Virtual Machine."

      Shhh! If they find out we know we're running in a VM, we won't be any use to them any more and we'll get rebooted.

  3. Anonymous Coward
    WTF?

    Non sequitur?

    ...miscreants must be able to at least start running their malicious code within an application or operating system on the target machine – this isn't a remote attack, it's a local attack.

    Um, what?

    dependent on a remote code execution flaw != "a local attack"

    It's hardly as if remote code execution flaws are unheard of, now, is it?!!!!!!!!!oneoneone

    1. Anonymous Coward
      Anonymous Coward

      Re: Non sequitur?

      True but, if they got in and managed to run their own code as root, why even run this code to begine with? Which brings me to wondering how easy "...randomising the locations of kernel and application components in memory" is without root.

    2. diodesign (Written by Reg staff) Silver badge

      Re: Non sequitur?

      All right, all right. The BTB part is local. It's needed to defeat ASLR. You need to defeat ASLR whether you're coming remotely or local. That part is local.

      In other words, we were trying to make it clear that you don't attack the BTB + ASLR from outside and then install your malware. You first gain basic code execution (remote or local) and then exploit the BTB to get past ASLR (local).

      I've taken that bit out since it seems to have blown your mind.

      C.

      1. Anonymous Coward
        Mushroom

        Re: Non sequitur?

        Hmmmmm.....

        ...but my mind is now settling back into its normal usual state. So thanks for the response.

        [edit: Why am I suddenly on the naughty stool????]

  4. JLV

    And this is why folks that compare securing software and IT assets against tampering to our fairly high, but reasonable, expectations of service quality from, say, an electric power utility company or civil engineering are, IMHO, off the mark.

    Software is hard and both assets and threats are constantly mutating. Doesn't mean we shouldn't try but foolproof sec is a pie in the sky. Damage mitigation, detection and resilience are needed to catch what slips through.

  5. StuartDavid

    Inventors - do not trust intel

    1. asdf

      Especially since even CPUs are largely becoming a commodity. The layoffs don't lie.

  6. Version 1.0 Silver badge

    Foolproof

    I've just checked and it's impossible to run this attack on an 8080, so let's not panic, we have an easy solution for anyone who's worried about it.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like