oss-sec mailing list archives
Re: Instruction encoding which prevents execution of a suffix
From: Josh Bressers <bressers () redhat com>
Date: Mon, 23 Nov 2015 21:11:31 -0500 (EST)
----- Original Message -----
Suppose you have some critical kernel operation you want to protect against execution if some preconditions are not met. Therefore, you check the precondition, and abort if it is not met. But this does not really work because if attackers have control over the program counter, they can just enter the function after the checks. What generic transformations exist (on x86_64) to make sure that an attacker cannot jump over the checks and execute only a suffix of the function? I know of one approach—move the check into the kernel, before the critical operation—but this is not always desirable for architectural reasons. I'd also prefer solutions which do not require changing *all* indirect jumps in the process image, and something that does not involve dynamic code generation (JIT).
I'm certainly not an expert here, but I know enough to be dangerous. If an attacker has full control (and in this case that should be the assumption), there's nothing you can do short of some sort of processor magic that doesn't exist today (that I'm aware of). What if you did the checks inside the kernel operation. Some sort of pre-shared secret of sorts to ensure the caller isn't new code. Of course this would require a kernel patch that I imagine wouldn't be a welcome change. Sometimes it's worth talking through problems like this with silly ideas though. -- JB
Current thread:
- Instruction encoding which prevents execution of a suffix Florian Weimer (Nov 20)
- Re: Instruction encoding which prevents execution of a suffix Josh Bressers (Nov 23)
- Re: Instruction encoding which prevents execution of a suffix Florian Weimer (Nov 24)
- Re: Instruction encoding which prevents execution of a suffix Josh Bressers (Nov 23)