Intel Will Soon Bake Anti-malware Defenses Directly Into its CPUs (arstechnica.com) 57
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.
Intel needs to bake ani-hack-our-CPU (Score:5, Insightful)
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
Re:Intel needs to bake ani-hack-our-CPU (Score:5, Insightful)
That's my first thought too. Unnecessary complexity in the processor just sounds like another attack vector.
Re: (Score:2)
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!
Re: (Score:2)
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)
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.
Re: (Score:3)
Gives one 6809 vibes, dual-stacks and all that.
Pointer signing like ARMv8.3 to protect from changes.
Re: (Score:3)
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.
Re: (Score:2)
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)
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
Re: (Score:2)
Re: (Score:2)
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)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Maybe Apple knew about this and it's one more reason they're planning a transition to their own ARM-based CPUs.
So, what's the spread on how long it takes... (Score:1)
Re: (Score:1)
Came here for this, leaving satisfied.
Fix your bugs by cleaning up and simplfying your shit, instead of making it so complex that you've camouflaged all the bugs.
Introspection (Score:2)
Re: (Score:2)
Re:This is wrong (Score:5, Informative)
Modern CPUs already have all sorts of important security feature. What exactly do you think protection rings are?
This is a very focused defense against Return Oriented Programming attacks, for which there is currently no good mitigation. It doesn't actually add any user-facing APIs or features to exploit, it's just a way of ensuring that programs execute in the manner they were originally designed to. We're not talking about a general-purpose anti-virus scanner built into the CPU or any such nonsense.
I do agree that overly-complex security subsystems are likely to have security issues of their own (like the Management Engine), but from what I can see, this looks a bit different. It's a pretty straightforward internal code-validation mechanism.
Re: (Score:2)
I think this will almost entirely depend on AMD.
Someone at intel is definitely thinking long term about an expensive certification program for this anti-malware feature. But I doubt they would go ahead with it if AMD doesn't do something similar.
Re: (Score:3)
What if AMD now feel compelled to add one of their own to "compete". All of this security theater is nothing more than "feel good" human emotional logic on top of a system that can only do one thing... operate logically. Which means it is going to be exploited by both its creator and bad actors that find ways to subvert it!
A processing unit needs to run the code it has been told to run, not run around assuming that code it was asked to run might be a bad actor. This needs to remain outside of the hardwar
Re: (Score:2)
You do not put security like this at that level. It will be abused instead.
Wasn't it just a few years ago that yet another root exploit was discovered that attacked the Windows font rendering system?
Re: (Score:3)
Not surprising - TrueType is Turing-complete.
Re: (Score:2)
Perhaps you're thinking of PostScript? Either way, the point is that it shouldn't be capable of a root exploit. There is no conceivable reason why font rendering for a GUI layer should be running with admin privilege.
Re: (Score:2)
Not thinking of PostScript. TrueType has a bytecode based hinting system that is Turing complete.
Most unprivileged code should be incapable of a root exploit. Often, it takes a second exploit to gain root level access once you have full user level access, but not always - there are a lot of assumptions in code and drawing a UI was once considered a root sort of thing.
Will it break drm or "anti cheat" systems. (Score:2)
Well this simplifies my decision making process. (Score:3)
Malware? They can't make software... (Score:2)
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)
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?
"no effective software mitigation against ROP" (Score:3)
Re: (Score:2)
That means not using the C/++ programming language.
Which is unthinkable.
Backups? We don't need no backups! (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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
Translation (Score:1)
Re: (Score:2, Troll)
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)
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.
Re: (Score:2)
... yet another attack surface, this one right inside the CPU.
You mean like the many "attack surfaces" already in the CPU which handle security none of which have actively been attacked? Seriously, attack surface? I think it's about time Slashdot introduce a mandatory quiz from TFA before a poster is allowed to post.
Re: (Score:3)
Comment removed (Score:4, Informative)
Please do not try this at home. (Score:3)
Baking your CPU is a difficult process and can result in it over-rising and spilling onto your heat sink. ;D
They've already done this. (Score:1)
Well, they'd be the experts in security (Score:3)
not.
So what happens when someone breaks CET? (Score:3)
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)
In Soviet Russia... (Score:3)
/. constantly needs their link titles corrected (Score:4, Funny)
Intel Will Soon Bake malware Directly Into its CPUs
FIFY
Another attack vector? (Score:2)
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.
Will this affect game trainers? (Score:1)
I don't have the time to replay whole swaths of games at my age and I want to see the whole game.