Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Intel Security

Intel Will Soon Bake Anti-malware Defenses Directly Into its CPUs (arstechnica.com) 57

Posted by msmash from the moving-forward dept.
The history of hacking has largely been a back-and-forth game, with attackers devising a technique to breach a system, defenders constructing a countermeasure that prevents the technique, and hackers devising a new way to bypass system security. On Monday, Intel is announcing its plans to bake a new parry directly into its CPUs that's designed to thwart software exploits that execute malicious code on vulnerable computers. From a report: Control-Flow Enforcement Technology, or CET, represents a fundamental change in the way processors execute instructions from applications such as Web browsers, email clients, or PDF readers. Jointly developed by Intel and Microsoft, CET is designed to thwart a technique known as return-oriented programming, which hackers use to bypass anti-exploit measures software developers introduced about a decade ago. While Intel first published its implementation of CET in 2016, the company on Monday is saying that its Tiger Lake CPU microarchitecture will be the first to include it. ROP, as return-oriented programming is usually called, was software exploiters' response to protections such as Executable Space Protection and address space layout randomization, which made their way into Windows, macOS, and Linux a little less than two decades ago. These defenses were designed to significantly lessen the damage software exploits could inflict by introducing changes to system memory that prevented the execution of malicious code. Even when successfully targeting a buffer overflow or other vulnerability, the exploit resulted only in a system or application crash, rather than a fatal system compromise.
This discussion has been archived. No new comments can be posted.

Intel Will Soon Bake Anti-malware Defenses Directly Into its CPUs More

Intel Will Soon Bake Anti-malware Defenses Directly Into its CPUs

Comments Filter:

  • Intel needs to bake ani-hack-our-CPU (Score:5, Insightful)

    by gavron ( 1300111 ) on Monday June 15, 2020 @09:57AM (#60185100)

    Every week another attack against Intel's speculative operations or cache.
    - Meltdown
    - Spectre
    - Many others
    - And as of March 2020 LVI https://www.zdnet.com/article/... [zdnet.com]
    - One more from May but it's Wired, so enjoy your adblocker https://www.wired.com/story/in... [wired.com]

    Intel should focus more on fixing their stuff, not adding "anti-malware" for one weak operating system.
    Malware changes. People use different languages, compilers, JIT, VMs, etc. But CPU flaws exist forever.

    Sorry, Intel. Time to focus on your bad stuff, not trying to ignore it and "add more cruft."

    E

    • That's my first thought too. Unnecessary complexity in the processor just sounds like another attack vector.

      • Exactly, but that attack vector will be for Intel primarily, it will just be incidental when bad actors find a way to take control of this feature and permanently malware or brick your fucking CPU just for fucking gags!

        I hope Intel gets a massive class action after this one!

        • All that's needed for a side-channel attack on an Intel CPU is a good sneeze.

          And AMD's PSP Land of Oz is just as bad. Want some keys, anyone? How about your OWN SPECIAL keys? Just a few instructions away!!

      • Re:Intel needs to bake ani-hack-our-CPU (Score:5, Informative)

        by AmiMoJo ( 196126 ) on Monday June 15, 2020 @10:29AM (#60185218) Homepage Journal

        Reading their paper (https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf) this does sound like a good idea with no obvious way to exploit it. Basically there are two parts.

        Shadow stack - When enabled the CPU writes return addresses to both the main stack and a second shadow stack that is only used for return addresses and never data. Using the MMU that stack is protected from writes by instructions other than those which save a return address, so malware can't write arbitrary addresses to it.

        Indirect Branch Tracking - A new CPU instruction marks target addresses as allowed for jumping to. One popular technique for malware is to find little snippets of code just before a RET instruction that they can then call by loading up the stack with bogus return addresses. The little bits of code all add up to a program that loads the main malware somehow, and there are automated tools to do all that. With this feature enabled a jump to an address that was not specifically marked as valid for jumps will crash the program.

        So it doesn't seem too half baked at all really, it's just that it won't mitigate a lot of the other security flaws in Intel CPUs and you can't really trust them to implement it properly. Hopefully AMD will adopt it though.

        • Gives one 6809 vibes, dual-stacks and all that.
          Pointer signing like ARMv8.3 to protect from changes.

        • Just one thing, Intel has been talking about their Shadow Stack [intel.com] stuff since 2016. They have had to make several revisions because they failed to account for basic things like exception handling. This made it worthless since it breaking most programs lead OS vendors to disable it by default.

          It's a positive security development but it also hinders... shall we say, less conventional designs for exotic programs like emulators.

        • Shadow stack - When enabled the CPU writes return addresses to both the main stack and a second shadow stack that is only used for return addresses and never data. Using the MMU that stack is protected from writes by instructions other than those which save a return address, so malware can't write arbitrary addresses to it.

          That's all very well, but part of the mitigation proposed for LVI required replacing indirect branch instructions (ret, jpm, call) with emulation sequences that squeeze in an lfence, so if this requires relying on using specific instructions then gp seems on point that these CPUs need to be fixed.

        • Re: (Score:2)

          by fintux ( 798480 )

          this does sound like a good idea with no obvious way to exploit it

          That's what was probably said about the Intel's speculative execution model :P

      • Then disable NX bit / XD bit on your processor, since it's unnecessary complexity. You know you 've found the lazy person in the room when he is the one harping about "unnecessary complexity" and can't substantiate the "unnecessary" part.

    • Every week another attack against Intel's speculative operations or cache. - Meltdown - Spectre - Many others - And as of March 2020 LVI https://www.zdnet.com/article/... [zdnet.com] - One more from May but it's Wired, so enjoy your adblocker https://www.wired.com/story/in... [wired.com]

      Intel should focus more on fixing their stuff, not adding "anti-malware" for one weak operating system. Malware changes. People use different languages, compilers, JIT, VMs, etc. But CPU flaws exist forever.

      Sorry, Intel. Time to focus on your bad stuff, not trying to ignore it and "add more cruft."

      E

      They have made changes to fix their architecture. If you've paid any attention you'll see that most of these attacks are mitigated in hardware in 9/10th gen chips. Have they completely rearchitected the chips? Not yet. But I have no doubt they are currently working on just that.

      • Re: (Score:1)

        by peace5 ( 6962164 )
        You sound like a supporter of the apartheid regime, and so, desperate for Intel to be back on top, ripping off people and finding creative new techniques to block their competitor?
      • Weak operating system? Which exactly? Because Linux and its stack had its fair share of heartbleeds and buffer overflows, since it's also written in a non-memory protected language. Sound like you don't know what you are talking about.

    • Intel should focus more on fixing their stuff, not adding "anti-malware" for one weak operating system.

      What's more likely, a highly sophisticated speculative execution attack customised to your specific machine's specific running instance exfiltrates some data that could be used against you in a follow up attack,

      OR

      You get hit by malware using a common technique targeted at a generic but widely available piece of software.

      No thanks to your proposal Intel should work on things which actually affect their customers, and not insanely complex exploits that have yielded no results outside of a lab.

    • Intel should focus more on fixing their stuff, not adding "anti-malware" for one weak operating system.

      Maybe Apple knew about this and it's one more reason they're planning a transition to their own ARM-based CPUs.

  • ...for the malware guys to find a way to take advantage of the anti-malware built in to intel's new chips to insert malware into said chips?
  • Somehow I have the feeling it will not protect the customers against all the behind-the-users-control processes from Intel. That is what the system should be doing.
  • Or will it empower them?

  • Well this simplifies my decision making process. (Score:3)

    by Guyle ( 79593 ) on Monday June 15, 2020 @10:20AM (#60185194)
    Of late when purchasing hardware I've gone with whoever has the performance I need at the price I want, I haven't been particularly attached to AMD or Intel. Going forward, pretty sure I'm rolling with AMD when it's time to upgrade or build new again. With all the issues Intel has had, this is bound to come with additional vulnerabilities that will be discovered later, and I just don't want that kind of headache. As others have said, if they aren't fixing their existing problems, I'm not confident in the execution of something like this at the CPU level.

  • So they are going to try to put malware "software" (kinda fuzzy, since it's in a chip) in their chips? I used to work for Intel. One thing they can't do is make software. It's made in a vacuum, never tested besides the engineer who made it saying... it works! This will be a disaster. It will instantly be compromised, and now there is something else to fix/update, if they can.

    Intel = Hardware Manufacturer (good at this)
    Intel = Anything else including software (suck)

    Making the case for AMD. I guess the

    • Re: (Score:2, Troll)

      by thegarbz ( 1787294 )

      So they are going to try to put malware "software" (kinda fuzzy, since it's in a chip) in their chips? I used to work for Intel.

      Given your level of understanding of what is going on I assume you worked for Intel in the HR department, or building services?

  • I thought that not having overflows in your code was an effective software mitigation against this?

  • Backups? We don't need no backups! (Score:3)

    by Ostracus ( 1354233 ) on Monday June 15, 2020 @10:27AM (#60185208) Journal

    CET introduces changes in the CPU that create a new stack called the control stack. This stack can’t be modified by attackers and doesn’t store any data. It stores the return addresses of the Lego bricks that are already in the stack. Because of this, even if an attacker has corrupted a return address in the data stack, the control stack retains the correct return address. The processor can detect this and halt execution.

    Sounds like basically a backup copy. An idea that should have been implemented long ago.

    • Don't CPUs already have such a copy for fast returns? I was under the impression that manipulating the return addresses on modern CPUs (for example to return through multiple stack frames at once) was slower than you'd expect because CPUs optimistically assume that returns from addresses on the stack will transfer execution to the instruction following the relevant call executed previously and manipulation of the return address interfered with pipelining. The way I understood this to work was that CPUs had
      • What you are talking about is probably stored in the code cache .. so first pass through it has no idea where the return goes, but after that it would be stored and unified with all the other stuff the decoder caches.

        The problem with the idea of a shadow stack is that a mismatch between return addresses would not be exceptional. While application developers dont usually get in there and alter or mock return addresses, you can be sure many applications still depend on a low level library that does it for g
  • Intel will add a new additional attack vector in their CPUs. Your CPU hardware should NEVER be a place to add anti-ANYTHING; it has one job to do and that's it.

    • Re: (Score:2, Troll)

      by thegarbz ( 1787294 )

      Intel will add a new additional attack vector in their CPUs. Your CPU hardware should NEVER be a place to add anti-ANYTHING; it has one job to do and that's it.

      Sure, if you got your language degree is cereal box marketed at the mentally challenged then I'm sure you would come up with that conclusion. In the meantime, protection mode, NX bit, executable space protection ... when was that introduced in a CPU again, holy shit 1961, CPUs even had anti-SOMETHING back when they were fed code via punchcards!

      Please don't comment on topics you know nothing about.

      • Re:Translation (Score:4, Interesting)

        by John_Sauter ( 595980 ) <John_Sauter@systemeyescomputerstore.com> on Monday June 15, 2020 @01:48PM (#60186250) Homepage

        ...In the meantime, protection mode, NX bit, executable space protection ... when was that introduced in a CPU again, holy shit 1961, CPUs even had anti-SOMETHING back when they were fed code via punchcards!

        For the non-greybeards, IBM introduced Problem State in 1964 on the System/360, DEC introduced User Mode in 1964 on the PDP-6, and Burroughs introduced Normal State on the B-5000 in 1961. The IBM and Burroughs computers were fed code on punch cards. There was a card reader available for the PDP-6, but as far as I know only two were sold--most customers preferred teletypes.

  • Please do not try this at home. (Score:3)

    by gurps_npc ( 621217 ) on Monday June 15, 2020 @11:54AM (#60185616) Homepage

    Baking your CPU is a difficult process and can result in it over-rising and spilling onto your heat sink. ;D

  • They've already attempted to do this and we have seen their failures the past several years. While this maybe a different approach and it will help, it will be broken within 2 years if not sooner. Then, we'll find out how much slower the chips well have to get as history repeats itself and new microcode is issued to slow things done and attempt (but not successfully) the problems. History. Watch, learn, forget, repeat.

  • Well, they'd be the experts in security (Score:3)

    by nagora ( 177841 ) on Monday June 15, 2020 @12:04PM (#60185660)

    not.

  • So what happens when someone breaks CET? (Score:3)

    by wakeboarder ( 2695839 ) on Monday June 15, 2020 @01:10PM (#60186020)

    Intel Exec: We need something built into the processor to stop all these bugs in our processors
    Engineer: OK, we'll do CET
    ---- 2 years later----
    Engineer: The hackers broke CET
    Intel Exec: *Head Slap*

  • What a joke.... (Score:3)

    by ELCouz ( 1338259 ) on Monday June 15, 2020 @01:10PM (#60186026)
    Intel can't even fix their shit properly. Good luck with that!

  • In Soviet Russia... (Score:3)

    by LordHighExecutioner ( 4245243 ) on Monday June 15, 2020 @01:28PM (#60186128)
    Hackers bake YOUR CPU!

  • Intel Will Soon Bake malware Directly Into its CPUs

    FIFY

  • In doing so, they're adding even more complexity to their microprocessors. More complexity means more potential for security vulnerabilities.
    They should be getting as much complexity as possible out and make things simple. Leave the details to the OS. Software can change, hardware cannot.

  • I don't have the time to replay whole swaths of games at my age and I want to see the whole game.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close