You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, exploits can currently make us keep our off flag set for too long (over some credentials-using code in and calls into the kernel) by abusing override_creds. So maybe the option of accepting that and "weakening" "off must be off" checks (replacing them with resetting of off) doesn't make things much worse (they're pretty bad anyhow). Similarly, maybe even updating shadow credentials on commit_creds is within consideration (and then ditto on override_creds and revert_creds instead of having the off flag at all), which would let us simplify LKRG a lot. As I now recall @Adam-pi3 and I had discussed privately before, this is something we could do if we accept relying only on pCFI to protect from exploits' calls to (or ROP'ing into) those functions. (Our decision not to update on commit_creds pre-dates the introduction of pCFI into LKRG.) Maybe that's the way to go, if we can't reasonably do much better anyway?
Right now, we're paying the price of complexity of hooking many other interfaces instead and we have to match specific kernel versions' logic in updating our off flag and we get false positives if we got anything wrong or if we haven't yet adapted to a kernel change. Maybe that complexity and price is not justified - maybe there is not a corresponding increase in protection compared to simply hooking commit_creds, override_creds, and revert_creds, checking pCFI, and updating our shadow credentials there.
Presumably, an exploit that would bypass pCFI could also have abused override_creds setting of off with our current approach. Such exploit would currently need to do its job without triggering an "off must be off" code path and quickly revert its credentials override afterwards. Is that enough exploitation complexity increase to justify our current protection complexity (compared to the simpler alternative suggested above)?
The text was updated successfully, but these errors were encountered:
I was wrong about this part - we would still need that flag for its short-lived uses across (sys)calls such as setuid (edit: would be across commit_creds then), where the credentials are briefly inconsistent, as long as we can sometimes perform asynchronous validation of task credentials (that is, not only when the task itself attempts to use the credentials, but also e.g. as part of our system+tasks integrity checking on timer).
This is item 4 in #215 (comment) and alternative to #219:
Unfortunately, exploits can currently make us keep our
off
flag set for too long (over some credentials-using code in and calls into the kernel) by abusingoverride_creds
. So maybe the option of accepting that and "weakening" "off
must be off" checks (replacing them with resetting ofoff
) doesn't make things much worse (they're pretty bad anyhow). Similarly, maybe even updating shadow credentials oncommit_creds
is within consideration (and then ditto onoverride_creds
andrevert_creds
instead of having theoff
flag at all), which would let us simplify LKRG a lot. As I now recall @Adam-pi3 and I had discussed privately before, this is something we could do if we accept relying only on pCFI to protect from exploits' calls to (or ROP'ing into) those functions. (Our decision not to update oncommit_creds
pre-dates the introduction of pCFI into LKRG.) Maybe that's the way to go, if we can't reasonably do much better anyway?Right now, we're paying the price of complexity of hooking many other interfaces instead and we have to match specific kernel versions' logic in updating our
off
flag and we get false positives if we got anything wrong or if we haven't yet adapted to a kernel change. Maybe that complexity and price is not justified - maybe there is not a corresponding increase in protection compared to simply hookingcommit_creds
,override_creds
, andrevert_creds
, checking pCFI, and updating our shadow credentials there.Presumably, an exploit that would bypass pCFI could also have abused
override_creds
setting ofoff
with our current approach. Such exploit would currently need to do its job without triggering an "off
must be off" code path and quickly revert its credentials override afterwards. Is that enough exploitation complexity increase to justify our current protection complexity (compared to the simpler alternative suggested above)?The text was updated successfully, but these errors were encountered: