3 ms·
How does that work with regards to privilege separation. It sounds like bypassing nt.dll might be an exploit vector that is easily forgotten.
by rocqua 7y ago
How does that work with regards to privilege separation. It sounds like bypassing nt.dll might be an exploit vector that is easily forgotten.
- gruez 7y agoPermission checks are still done in the kernel. >It sounds like bypassing nt.dll might be an exploit vector that is easily forgotten. MSFT might be bad, but not that bad.
- mehrdadn 7y agoJust a note, it's not nt.dll, it's ntdll.dll.
- crehn 7y agoHeh, interesting. Any specific reason for the stuttering? Or just arbitrary inconsistent historical decision?
- mehrdadn 7y agoNot sure! My guess is the name would've just felt too short otherwise.
- windozeee 7y agoI'll give you a better one. On a 64 bit Windows: - the 64 bit binaries are stored in C:\Windows\System32 - the 32 bit binaries are stored in C:\Windows\SysWOW64
- quotemstr 7y agoI'm guessing it's because module names are sometimes used without the extension and "ntdll" looks better in such a list than "nt".
- DHowett 7y agoI think it’s because the kernel’s module name is “nt”. It’ll show up like that in stack traces on occasion.
- anaisbetts 7y agoAll of the verification is done on the kernel side of the boundary, all entrance points to the kernel via syscalls are marked using static code analysis so that the kernel never trusts a pointer provided from user-mode, so even if you sysenter yourself, you can't do anything Special