C is Brittle D is Plastic

[Indraj Gandham]

Just on the subject of buffer overflows, since I don't think anyone else 
has mentioned it here: Intel and AMD have been shipping x86 processors 
with Control-Flow Enforcement (CET) since 2020.

To mitigate ROP, when the CPU executes a CALL instruction, it will push 
the return address to both the normal process stack and a shadow stack 
stored in a protected region that cannot be modified except by the CPU. 
When the CPU executes the RET instruction, the addresses are popped from 
both stacks and compared. If they do not match, a fault will be raised.

To mitigate JOP, the CPU uses a state machine. When a JMP or CALL 
instruction is executed, it moves from an idle state into a waiting 
state. The very next instruction must be ENDBRANCH. If it is, the state 
returns to idle. If it isn't, a fault will be raised.

These mitigations do have limitations; for example the JOP protection 
does not verify whether the target is actually the correct destination 
for a given call site. It also does not protect against data 
modification. For compatibility reasons the operating system will likely 
disable CET for the entire process if one of the libraries the 
application links against was not compiled with CET support. JOP 
protection is not yet (?) available on AMD processors.

However -- CET may mean the difference between a vulnerability allowing 
for some degree of local data corruption and an attacker gaining 
complete control over your application.

You can enable CET in GCC and GDC by passing -fcf-protection=full.

The performance overhead of CET is generally minimal and most major 
Linux distributions are attempting to enable it (or have already enabled 
it) by default when compiling packages.

(Of course, it does nothing to protect against double-free, UAF etc.)