Intel has a long history of working with the software community and making strides in strengthening protections of operating systems and software running on modern computer systems. As these protections came into effect, adversaries started looking for creative alternatives to bypass these protections. Return Oriented Programming (also known as ROP) and Jump Oriented Programming (also known as JOP) are two such techniques that has been gaining popularity. JOP or ROP attacks can be particularly hard to detect or prevent because the attacker uses existing code running from executable memory in a creative way to change program behavior. What makes it hard to detect or prevent ROP/JOP is the fact that attacker uses existing code running from executable memory. Many software-based detection and prevention techniques have been developed and deployed with limited success.
ROP is where the attacker relies on RET (return) instruction to stitch together a malicious code flow that was not programmer-intended. Per the design, return instructions fetch the address of next instruction from stack (which was pushed on the stack by the prior CALL instruction) and executes instructions from that address. In the case of ROP-based attacks, the attacker apriori or at runtime scans for sequence of bytes in existing program code by scanning the program on disk or in memory. Figure 1 shows an example of existing instruction stream.
This example shows three instructions executed in a sequence (notice there are no RET instructions in this programmer-intended sequence) and corresponding bytes of program in blue boxes below. The same set of code bytes, when interpreted starting at an invalid offset, can also mean alternate set of instructions that cause the sequence to end with a RET as shown in the figure below where bytes in red boxes correspond to a different instruction sequence and in this example, each instruction is followed by C3 which corresponds to the return instruction. These instruction sequences are called “gadgets”.
Intel has been actively collaborating with Microsoft and other industry partners to address control-flow hijacking by using Intel’s CET technology to augment the previous software-only control-flow integrity solutions. Intel’s CET, when used properly by software, is a big step in helping to prevent exploits from hijacking the control-flow transfer instructions. For more details, reference Microsoft’s BLOG “Understanding Hardware-enforced Stack Protection”.
Security Analysis of Processor Instruction Set Architecture for Enforcing Control-Flow Integrity (ACM Digital Library):
Paper PDF: https://dl.acm.org/doi/pdf/10.1145/3337167.3337175
Intel Software Development Emulating (SDE):
GCC Instrumentation Options:
Linux Kernel Patches:
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804