RIP ROP, COP, JOP? Intel to bring anti-exploit tech to market in this year's Tiger Lake chip family
(2020/06/15)
- Reference: 1592226011
- News link: https://www.theregister.co.uk/2020/06/15/intel_cet_tiger_lake/
- Source link:
After years in development, Intel is set to debut security mechanisms in its microprocessors that it hopes will block, at the silicon level, exploitation of a class of software vulnerabilities.
Known as Control Flow Enforcement Technology, or CET, the protections are designed to prevent miscreants from exploiting certain programming bugs to execute malicious code that infects systems with malware, steals data, spies on victims, and so on. These bugs typically involve tricking programs into corrupting or overwriting their memory with special values pivotal to the attacks.
"These are all insidious types of attacks that have been plaguing the industry for some time," Tom Garrison, Intel's client computing group VP and general manager of security strategies and initiatives, told The Register . "They are nearly impossible to address with software-based mitigation."
The first CET-enabled chips will be members of the upcoming 10nm Tiger Lake line, due to launch this year. That family is expected to include server and desktop processors, such as the Project Athena silicon going into laptops.
There are various mitigations in place on modern systems, such as Data Execution Prevention (DEP), that stop hackers from injecting and executing malicious code into a program when, for instance, a victim opens a specially crafted document or connects to a remote service. DEP in particular prevents areas of memory marked as data areas, which can be hijacked by hackers, from being used to run smuggled-in code.
Want to get into the nitty-gritty? The concept of CET was first laid out by Intel in a [1]whitepaper [PDF] in 2016, which has been revised over time, as recently as May 2019.
El Reg 's [2]2016 write-up on the original CET whitepaper gives an in-depth technical explanation of low-level workings of CET and the types of attacks it is designed to prevent.
However, it is still possible for skilled miscreants to abuse these memory-corruption vulnerabilities to build a chain of malicious code out of the instructions already present in a program, turning the app or server against itself. This so-called Return Oriented Programming (ROP) is achieved by manipulating an application or server thread stack so that the processor bounces between snippets of the software under attack, performing small operations that together typically disable DEP and pull in more malicious code to execute without hindrance.
CET introduces a shadow stack system to detect and thwart the stack manipulation required by ROP. CET also introduces a new instruction called ENDBRANCH that is a NOP on non-CET x86 processors, but for CET CPUs, marks a valid target for a call or jump instruction. Thus if exploit code hijacks the flow of code in an application or server, and makes it jump to someplace the developers didn't intend, this is caught and stopped. This tackles so-called Call or Jump Oriented Programming (COP or JOP). The ENDBRANCH instructions should be inserted automatically by compilers. Other architectures, such as Arm, have something similar.
"What ends up happening is, as the processor is jumping through the code, it checks to make sure it is landing on an end branch," said Garrison, describing Intel's anti-COP-JOP protection. "If the code jumps to an illegal area, it throws up an error."
Intel believes that the respective adoption process for applications and operating system developers will be minimal: software can be recompiled and re-released for COP-JOP protection, for instance.
"It depends on which class [of attack] you are trying to mitigate," said Garrison, "but in both cases they are relatively modest changes to the application or the OS level."
This is a welcome development – though not at all if you're an exploit developer – yet bear in mind hardware-level solutions aren't necessarily perfect. Intel's SGX has [3]suffered side-channel leaks, and Apple's Arm-based pointer authentication protections have been [4]bypassed in the past, for example. ®
Sponsored: [5]Google Security Whitepaper
[1] https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
[2] https://www.theregister.com/2016/06/10/intel_control_flow_enforcement/
[3] https://www.theregister.com/2020/06/10/intel_patches_sgx_again/
[4] https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html
[5] https://go.theregister.com/tl/1956/-8471/google-security-whitepaper?td=wptl1956
Known as Control Flow Enforcement Technology, or CET, the protections are designed to prevent miscreants from exploiting certain programming bugs to execute malicious code that infects systems with malware, steals data, spies on victims, and so on. These bugs typically involve tricking programs into corrupting or overwriting their memory with special values pivotal to the attacks.
"These are all insidious types of attacks that have been plaguing the industry for some time," Tom Garrison, Intel's client computing group VP and general manager of security strategies and initiatives, told The Register . "They are nearly impossible to address with software-based mitigation."
The first CET-enabled chips will be members of the upcoming 10nm Tiger Lake line, due to launch this year. That family is expected to include server and desktop processors, such as the Project Athena silicon going into laptops.
There are various mitigations in place on modern systems, such as Data Execution Prevention (DEP), that stop hackers from injecting and executing malicious code into a program when, for instance, a victim opens a specially crafted document or connects to a remote service. DEP in particular prevents areas of memory marked as data areas, which can be hijacked by hackers, from being used to run smuggled-in code.
Want to get into the nitty-gritty? The concept of CET was first laid out by Intel in a [1]whitepaper [PDF] in 2016, which has been revised over time, as recently as May 2019.
El Reg 's [2]2016 write-up on the original CET whitepaper gives an in-depth technical explanation of low-level workings of CET and the types of attacks it is designed to prevent.
However, it is still possible for skilled miscreants to abuse these memory-corruption vulnerabilities to build a chain of malicious code out of the instructions already present in a program, turning the app or server against itself. This so-called Return Oriented Programming (ROP) is achieved by manipulating an application or server thread stack so that the processor bounces between snippets of the software under attack, performing small operations that together typically disable DEP and pull in more malicious code to execute without hindrance.
CET introduces a shadow stack system to detect and thwart the stack manipulation required by ROP. CET also introduces a new instruction called ENDBRANCH that is a NOP on non-CET x86 processors, but for CET CPUs, marks a valid target for a call or jump instruction. Thus if exploit code hijacks the flow of code in an application or server, and makes it jump to someplace the developers didn't intend, this is caught and stopped. This tackles so-called Call or Jump Oriented Programming (COP or JOP). The ENDBRANCH instructions should be inserted automatically by compilers. Other architectures, such as Arm, have something similar.
"What ends up happening is, as the processor is jumping through the code, it checks to make sure it is landing on an end branch," said Garrison, describing Intel's anti-COP-JOP protection. "If the code jumps to an illegal area, it throws up an error."
Intel believes that the respective adoption process for applications and operating system developers will be minimal: software can be recompiled and re-released for COP-JOP protection, for instance.
"It depends on which class [of attack] you are trying to mitigate," said Garrison, "but in both cases they are relatively modest changes to the application or the OS level."
This is a welcome development – though not at all if you're an exploit developer – yet bear in mind hardware-level solutions aren't necessarily perfect. Intel's SGX has [3]suffered side-channel leaks, and Apple's Arm-based pointer authentication protections have been [4]bypassed in the past, for example. ®
Sponsored: [5]Google Security Whitepaper
[1] https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
[2] https://www.theregister.com/2016/06/10/intel_control_flow_enforcement/
[3] https://www.theregister.com/2020/06/10/intel_patches_sgx_again/
[4] https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html
[5] https://go.theregister.com/tl/1956/-8471/google-security-whitepaper?td=wptl1956
COMEFROM?
Dave Pickles
It seems Intel have rediscovered the mythical [1]COMEFROM instruction.
[1] https://en.wikipedia.org/wiki/COMEFROM
Exploit in
IGotOut
3...2....1
SGX anyone?
iron
Intel... hardware... security... No, please STOP!
I'm laughing so hard my sides are splitting.
nearly impossible to address with software-based mitigation
Anonymous Coward
So not impossible? Which then makes me wonder why go to all the trouble of changing the hardware when it should be the software that does it anyway, is it not an extra risk to put something else in?
Thoguht
So what exactly will stop the bad people from putting ENDBRANCH in their exploit code too?
ARM equivalent?
IgorS
> Other architectures, such as Arm, have something similar
Anyone knows what the equivalent ARM mechanism is?
Re: ARM equivalent?
John Savard
Apparently it's called Pointer Authentication, and it was introduced in version 8.3 of the ARM architecture.
Surely an extra NOOP that uses a fetch/execute cycle to retrieve and verify it's a valid destination target to branch to in tight loops that get executed billions of times per second will reduce IPC?