CCFI: Cryptographically Enforced Control Flow Integrity
Background
Control Flow Integrity:
Maintain the integrity of control flow
Practical Implementation of Control Flow Integrity had some problems. Attackers could bypass those defenses. (Not saying this is immune to any attack, saying its a better framework to start)
Basically how practical implementation goes:
Pointer A is a function pointer, Pointer B is a return pointer. Then we block A from referensing B
Now if the attacker would have a Pointer C that is a function pointer than C can reference A nothing stops that. Hence, ROP is still possible (+ papers exists showing this is the case)
Now whats the first thing you think when we say "Integrity" in software security. Authentication. What is a well known authentication method?
Message Authentication Code (MAC)
So naturally paper suggest using MAC to keep CFI on pointers. Calling this method CCFI
CCFI ultimately led to development of PAC in ARM processors on the iPhone.
Like any security method, nothing is perfect. Google Project Zero demonstrated the Limitation of PAC
How is it done
Make MAC with runtime variables and secret key. Store MAC inside stack. When pointer is referenced, regenerate MAC and compare. If the two are different we crash the program.
Not Too Detailed but Implementation
So MAC input is basically 128 bits. However note that these details are not essential to the idea.
48 bit is the pointer address (since out of 64 bit address only 48 bit is actually used)
Remaining 80 bits is the class. Hence theoretically we can have 2^80 different pointer classes.
The paper divide classes into four big categories:
- Function pointers
- Return addresses
- Method pointers
- Vtable pointers
Each pointer has a different grammer(?) in how it creates the class of MAC input. So unless the class is different or the address is different, two pointers cannot have the same MAC.
Weakness?
Well the paper demonstrate a "replay attack"
If pointers had the same class. They still can't be on the same address right? right????
No.
Now lets say pointer A was on position X at time T. Lets say pointer A is a very important pointer. Say it could be used to bypass CCFI (we don't want that!)
Now pointer B comes along and sits on position X at time T1. Interestingly if pointer B has the same class as A we have a problem! B can be an alias to A and now the replay attack has succeeded.
Paper suggest an address randomization method to make this more difficult and hint a possibility of allowing it to never occur (could not understand :( something slab something idk )
Now other problems exist like typecasting a function pointer to a void pointer and so on. Or a C structure with a function pointer.
But more generally the reserved registers could leak the secret key. This is not impossible. Afterall, the paper suggested that protecting the kernel is out of scope.
Deployment? Compatible?
Well the void pointer casting does crash programs when done. If a function was casted and the CCFI does not know this. Than when the function is called CCFI would crash the program.
Paper noted that this problem was observed in C. Especially with memcpy and so on.
Compatability will improve. The reason this solution was more viable than before is due to Intel AES-NI (Advanced Encryption Standard - New Instruction). Basically hardware support lowering the overhead of MAC calculation.
Remember that ARM processor use PAC (similar idea) so hardware support benefits this method
Overhead?
We calculate MAC everytime pointer is stored referenced and so on?
As discussed above basically overhead exists. Any security measure would introduce this. But CCFI suggest a dynamic framework for CFI and suggest that hardware support could lower the overhead.
Not perfect but better than whan exists.
