4 ms·

> “The second defense is more complicated. On entry to a function, it essentially "encrypts" the address being returned to by the function, prior to any code th

> “The second defense is more complicated. On entry to a function, it essentially "encrypts" the address being returned to by the function, prior to any code that could possibly corrupt the return address. The key used to encrypt the return address is stored in a reserved CPU register, generally ensuring that the key itself should not leak. The resulting value of encrypting the return address gets saved in a register, but the actual return address in memory is not modified. On return from the function, the instrumented code will compare whatever return address exists at that point (either legitimate or attacker-modified) to that obtained from decrypting the encrypted return address saved in the other register. If the two do not match, execution is terminated.” There's probably a very good reason I'm missing, but could the return address be hashed and then on return hash the address that is being returned to and compare it with the previously hashed address? This would prevent the issues around the encryption key leaking, but probably raises its own issues.

Buge 10y ago
The problem I think is that at some point the register containing the encrypted address needs to be written to the stack, where it could be overwritten. So if it was just hashed, an attacker could overwrite both the hash and the plaintext return address, and return wherever they want. Although hashing with a secret salt would solve that. I don't seen any benefit over encrypting though. One attack I can see is in their model of "the attacker can read all memory" the attacker reads the memory at a time when system() is legitimately called, then the attacker can know the encrypted version of the system() address, and use that to overwrite some other return address with system() and the encrypted version. But I think it would be very unlikely an attacker would be able to do that.

Buge 10y ago

The problem I think is that at some point the register containing the encrypted address needs to be written to the stack, where it could be overwritten. So if it was just hashed, an attacker could overwrite both the hash and the plaintext return address, and return wherever they want. Although hashing with a secret salt would solve that. I don't seen any benefit over encrypting though. One attack I can see is in their model of "the attacker can read all memory" the attacker reads the memory at a time when system() is legitimately called, then the attacker can know the encrypted version of the system() address, and use that to overwrite some other return address with system() and the encrypted version. But I think it would be very unlikely an attacker would be able to do that.