Messages in this thread | | | Date | Tue, 18 Oct 2022 22:32:06 -0700 | From | Kees Cook <> | Subject | Re: [PATCH] x86/ibt: Implement FineIBT |
| |
On Tue, Oct 18, 2022 at 12:59:42PM -0700, Joao Moreira wrote: > Kees said: > > I still think it's worth noting it does technically weaken the > > "attacker-controlled executable memory content injection" attack > > requirements, too. While an attacker needs to make sure they place an > > ENDBR at the start of their injected code, they no longer need to also > > learn and inject the CFI hash too, as the malicious code can just not > > do the check at all. The difference in protection currently isn't much. > > > > It's not a very difficult requirement to get attacker-controlled bytes > > into executable memory, as there are already existing APIs that provide > > this to varying degrees of reachability, utility, and discoverability -- > > for example, BPF JIT when constant blinding isn't enabled (the > > unfortunate > > default). And with the hashes currently being deterministic, there's no > > secret that needs to be exposed first; an attack can just calculate it. > > An improvement for kCFI would be to mutate all the hashes both at build > > time (perhaps using the same seed infrastructure that randstruct depends > > on for sharing a seed across compilation units), and at boot time, so > > an actual .text content exposure is needed to find the target hash > > value. > > > If we look back at how well ASLR did over the years I think we can't really > rely that randomizing the hashes will solve anything. So what you are > suggesting is that we flip a "viable defence against SpectreBHB" for a > randomization-based scheme, when what we really should be doing is getting > constant blinding enabled by default.
I don't think any of these things are mutually exclusive. The randomization means an additional step (and possibly additional primitive) is needed for an attack chain. Since we get this from a one-time cost on our end, that seems like reasonable value.
> At this point I feel like going on is a bit of bike-shedding, but if this > really matters, below is how to use randomization on FineIBT. Maybe with lot > less entropy, but just ideas thrown that could be improved over time (don't > take this as a serious proposal): > > Assuming we got 16 bytes padding to play with on each function prologue, you > can randomize between 0-11 in which offset you emit the ENDBR instruction. > Caller/Callee would look like (hopefully I did not mess-up offset): > > <caller>: > and 0xf3, r11b > call *r11 > > <callee>: > nop > nop > nop > endbr // <- this position is randomized/patched during boot time. > nop > nop > ... > > And of course, you get more entropy as you increase the padding nop area.
Oh, I kind of like this -- it'd need to be per matching hash. This would require roughly 3 bits of entropy exposure of the .text area. For X^R, that becomes annoying for an attacker, though likely once close enough, multiple attempts could find it, assume panic_on_oops/warn wasn't set.
Anyway, this sounds like an interesting idea to keep in our back pocket...
-- Kees Cook
| |