Hello,
I’ve been playing with your sandbox recently and noticed that my dummy sandboxed application is crashing when I have ProcessStrictHandleCheckPolicy turned on. After some digging I found out that the INVALID_HANDLE exception is thrown from CopyFile, which doesn’t take any handles, just paths. So at first I thought it’s bug in API.
After some debugging I found the spot where the API calls NtCreateFile which fails (because sandbox works as expected) but due to a bad design of the API the return code is checked but the API doesn’t immediately quit as you would expect but also checks whether the returned handle doesn’t satisfy the following formula
((HANDLE + 1) & 0xFFFFFFFFFFFFFFFE)
If it does it assumes that the handle is valid and starts calling other API with it. This of course works in unsandboxed code just fine because the HANDLE is set to INVALID_HANDLE_VALUE and that doesn’t satisfy the formula. But in sandboxed code sandbox::TouchMemory is called on this value before it’s send to broker, this function overwrites the original INVALID_HANDLE_VALUE (0xffffffff) to 0x00ffffff00 which as you might see it’s not ok.
So my question is, shouldn’t sandbox::TouchMemory restore the original bytes after setting them to 0?
The issue can be replicated on Windows 10 by using ProcessStrictHandleCheckPolicy policy and trying to copy a file where target has only read access.
The crash happens at this location KERNELBASE!BaseCopyStream+0x1e52 on Windows 10 RS3
Regards,
Richard
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.