DW still vulnerable on anti-TOCTTOU BY mj0011

Strong anti-TOCTTOU (race conditions) protection is integrated into.

====

这句说得就有点过分了，新版的DW确实运用了一些技术来防止TOCTTOU（即所谓KHOBE), 主要表现在下面两个方面：
(1).对于用户地址的参数，申请kernel内存并通过MmMapLockedPagesSpecifyCache映射到用户态地址上，然后将参数COPY该地址后，直接将映射后的地址传递给R0

(2).对于句柄，在所有句柄创建、关闭时记录其对象和句柄一个进程对应的链表中，当句柄使用时，检查是否位于这个表中，如果发现send-close-create现象，就阻止请求

但是这些方法是明显存在漏洞的

(1). 对于(1),大部分函数处理都仅仅COPY了 最终的字符串BUFFER,例如NtCreateEvent，仅仅复制了ObjectAttributes->ObjectName->Buffer这一块缓存，而其他的缓存例如object name所在内存则没有做这样的处理，攻击者仍然可以利用TOCTTOU 的方式，伪造恶意的unicode_string length等方式绕过保护

(2).同样， (1).的方法即使处理了全部缓存，也是不能彻底解决TOCTTOU的问题的，因为此时映射到的是仍是RING3的内存，且没有锁定内存禁止修改，因此攻击者仍是可以通过预测内存映射的地址，篡改结果，绕过保护

此外，这版的TOCTTOU防护由于在所有函数调用时都会做句柄记录、检查、用户态内存分配，因此对性能消耗提升是相当大的，而且可能会引发较多的兼容和稳定性问题。

最终防御TOCTTOU还是需要深层+多层钩子来解决，DW这种只能说是偷懒的、在一定程度一定概率上提升了TOCTTOU的攻击难度的保护。

此版的另外一个改进是拦截了NtUserRegisterHotKey,当HotKey没有做combine 时(即不是alt + xx \ ctrl+ xxx \ shift+ xxx \ win key + xxx) 时，即拦截这个热键注册

应该是对抗之前论坛上那个新型键盘截取的

Rico wrote:how does the gd ol' sbie fare in this race ??

This is impressive research by Matousec and I enjoyed reading it and thinking about it. They have a good point here, but most of this does not apply to Sandboxie.

Sandboxie kernel hooks are not SSDT hooks which execute before the kernel, as described in the article. Rather they are callbacks invoked by the kernel, after it has already validated, copied and locked down all parameters in question. It is impossible for the caller to alter these internal copies of the parameter at this point, and what Sandboxie inspects are those internal copies passed by the kernel.

Sandboxie Win32 hooks do work as described in the article, but Win32 window handles are different from kernel handles, and are not susceptible to the handle manipulation attack that was described.

There is one small bit of Sandboxie that might be vulnerable to this, where a sandboxed program might be able to terminate a program outside the sandbox (the EndTask API). However this is pretty much the extent of the vulnerability, so I'm not very concerned and won't be going to any great lengths to do anything about it.

Just found two holes into the anti-TOCTTOU protection. One is fixed, the second is on the way. And it's not about mj0011 blog posts, it's really serious.

ssj100 wrote:
Seems a bit coincidental if you ask me. And I didn't know Ilya could read Chinese haha. I can't make head or tail of the content in the chinese forums etc.

呵呵，老外就是嘴巴硬，其实做安全的老外没几个有国人牛的，真才实学、刻苦钻研的少。

就像DW我都过了多少次了，想过的话还可以随便再过N次

有空的话，等DW出了修复它的所谓TOCTTOU BUG的版本后，我会出过他的ANTI-TOCTTOU的POC,很简单，因为这根本不是BUG问题，而是他解决TOCTTOU的方向就找错了~

This version does streng then the capacity of anti-TOCTTOU as I said previously, map memory (non-read only) way to solve the problem, this version of a change in the Map section of the way, while protect attributes to the PAGE_READONLY

Than the previous version did this greatly increase the difficulty of the attack, but unfortunately, at the expense of so many performance and stability, the obvious flaw in this approach remains an attacker can still guess the address(guess the difficulty and the Version no difference), get the address map, and then use ZwProtectVirtualMemory modify memory property, complete attack.

Although the addition time of a call system service process, reduce the probability of success will be attacked, but in theory, as long as the higher number of attempts, or in multi-core machines, or is likely to succeed

In fact, this attack can block only a thin the last step, and it is on the increase in ZwProtectVirtualMemory hook dw own memory map to change property to prevent interception, DW Unfortunately, this version does not have this feature, refer to the relevant DW HOOK:

ProxyNtProtectVirtualMemory:
....
if (KeGetPreviousMode ()! = UserMode
| |! IsLimitedProcess (IoGetCurrentProcess, 0, 0)
| | Handle == 0
| | Handle == NtCurrentProcess ())

goto pass_this_request;

Of course, this method can in theory solve the DW although the current anti - tocttou problem, but with more performance loss is the need to intercept all the memory attributes of the process changes, the process also need to call system services for all limited When the data recording memory allocation table, but DW has been consumed for solving the problem so much performance, to further increase this fear is the inevitable.

But it is still I said before, TOCTTOU this issue should be resolved with a deep hook, so that neither the performance issue, nor a security risk, just for the forming of security software, the need to change hook framework, to bring stability and compatibility risk has increased.

mj0011 wrote:dw 3.04 still vulnerable

by google translate:

This version does streng then the capacity of anti-TOCTTOU as I said previously, map memory (non-read only) way to solve the problem, this version of a change in the Map section of the way, while protect attributes to the PAGE_READONLY

Than the previous version did this greatly increase the difficulty of the attack, but unfortunately, at the expense of so many performance and stability, the obvious flaw in this approach remains an attacker can still guess the address(guess the difficulty and the Version no difference), get the address map, and then use ZwProtectVirtualMemory modify memory property, complete attack.

Although the addition time of a call system service process, reduce the probability of success will be attacked, but in theory, as long as the higher number of attempts, or in multi-core machines, or is likely to succeed

In fact, this attack can block only a thin the last step, and it is on the increase in ZwProtectVirtualMemory hook dw own memory map to change property to prevent interception, DW Unfortunately, this version does not have this feature, refer to the relevant DW HOOK:

ProxyNtProtectVirtualMemory:
....
if (KeGetPreviousMode ()! = UserMode
| |! IsLimitedProcess (IoGetCurrentProcess, 0, 0)
| | Handle == 0
| | Handle == NtCurrentProcess ())

goto pass_this_request;

Of course, this method can in theory solve the DW although the current anti - tocttou problem, but with more performance loss is the need to intercept all the memory attributes of the process changes, the process also need to call system services for all limited When the data recording memory allocation table, but DW has been consumed for solving the problem so much performance, to further increase this fear is the inevitable.

But it is still I said before, TOCTTOU this issue should be resolved with a deep hook, so that neither the performance issue, nor a security risk, just for the forming of security software, the need to change hook framework, to bring stability and compatibility risk has increased.

ssj100 wrote:Firstly, welcome to the forum mj0011. I'm not sure if you're the "real" mj0011, but that doesn't matter.

Could you please link us to the original thread that contains that information you posted? I know most of us here can't read mandarin, but it's just nice to have a reference.

From what I gather, it sounds like you know of a way or concept to improve DefenseWall so that it is resistant against TOCTTOU attacks while also preserving performance. I'm sure Ilya will be most interested in this.

TOCTTOU 本身就只是一定概率上会成功的攻击方式，也就是需要多次大量尝试才有可能成功。

前面我已经说了，这版DW改进的PAGE ONLY方式以及把此前的只capture部分参数的BUG改了，因此攻击的成功率已经比较低了，但是防御的方式上仍存漏洞，仍存在被攻破的概率，因此不会发针对TOCTTOU的POC出来。

New 3.04 build uploaded. Found two issues with anti-TOCTTOU protection module. Check this build very carefully, it may cause problems (I did checks on my side, but everything may happens, I could miss something).

To mj0011: yes, it was possible to change PAGE_READONLY memory region to PAGE_WRITECOPY (but not to PAGE_READWRITE and PAGE_EXECUTE_XXX), and not only with NtProtectVirtualMemory, but, also, with trivial NtAllocateVirtualMemory (you missed this possibility with your blog post), but the game over now. It is completely impossible to change mapped memory region's protection attributes. With any rin3-available functions, I already tested all potential variants.