On 22.01.2016 03:13, Erich E. Hoover wrote:
On Jan 21, 2016 9:41 AM, "Sebastian Lackner" <sebastian(a)fds-team.de> wrote:
... In this case it shouldn't matter (as far as I know NtOpenFile isn't intercepted by the Chromium Sandbox), however when thinking more carefully about it, heap functions could indeed be problematic. What we theoretically need is two sets of them, user mode calls are supposed to go through NtAllocateVirtualMemory, but kernel mode calls not. I'll do some more testing myself, so far I haven't found out which thunks exactly introduce the randomness in the Chromium sandboxing code. ...
Maybe this is being overly simplistic, but we do have both Zw* and Nt* entry points. It could make sense to use Zw* internally and route all the external calls through the thunks (Nt*).
Best, Erich
I already thought about that, but on Windows both Nt* and Zw* exports point to the same function. Sooner or later we might find an application which relies on this. Of course we could still use Zw* names internally only, but like any other solution, its a huge amount of effort to check all calls manually. Especially things like heap management functions are used both in "user mode" and "kernel mode".