|
|
|
|
|
|
by mikeash
3304 days ago
|
|
|
It looks like this will prevent attacks that use information leakage to figure out valid addresses. With ASLR, you can defeat it if you can get the target to send a return address or other code pointer back to you, because you'll then be able to see where the code is loaded. With this, a pointer to code is likely useless: the authentication code depends on the target address, so you wouldn't be able to forge a valid pointer to a different address, and it depends on the current stack pointer, so you wouldn't even be able to reuse the value to point to the same address unless you found an exploit with the exact same stack depth. |
|
|
The authentication code is a combination of key and context: there are 5 total keys in the system, and then an unlimited number of contexts. Contexts are I think most useable on the "return" edges, because you can add the current stack pointer value to the context when you push the boxed return address onto the stack, then re-derive that context when you're at the return site.
That exact scheme doesn't work that well on the forward edge, because the stack pointers will be different when calling function pointer F in function A vs function B. What you can probably do is encode something about the type of F into the context. However, as they outline in the white paper, this isn't enough on its own because the type signature of gets and system are really similar and if your type-to-context encoding scheme maps them to the same context, an attacker could take a call to gets-via-function-pointer and replace that value with the value of system as it appears elsewhere in your program.