https://windows-internals.com/kaslr-leaks-restriction/ : many userland APIs now restrict processes to access kernel addresses, in order not to break KASLR and make kernel exploits more complex. This does not affect processes with SeDebugPrivilege though so it is not a long term problem for EDRSandblast (Microsoft's goal is to harden the user->admin boundary; not the usermode-admin->kernelmode one).
This should break some of EDRSandblast code if we do not enable SeDebugPrivilege before calling APIs that are used to leak kernel pointer (such as kernel module addresses, kernel objects' handles, etc.)
TODO: review the code and ensure the privilege is set before these operations.
(I am noting this here as a reminder to myself since it could break EDRSandblast in the near future; but if someone wants to contribute, be my guest 😃 )
https://windows-internals.com/kaslr-leaks-restriction/ : many userland APIs now restrict processes to access kernel addresses, in order not to break KASLR and make kernel exploits more complex. This does not affect processes with SeDebugPrivilege though so it is not a long term problem for EDRSandblast (Microsoft's goal is to harden the user->admin boundary; not the usermode-admin->kernelmode one).
This should break some of EDRSandblast code if we do not enable SeDebugPrivilege before calling APIs that are used to leak kernel pointer (such as kernel module addresses, kernel objects' handles, etc.)
TODO: review the code and ensure the privilege is set before these operations. (I am noting this here as a reminder to myself since it could break EDRSandblast in the near future; but if someone wants to contribute, be my guest 😃 )