TOCTOU with NT System Service Hooking

[Andrey Kolishak <andr () sandy ru>]

TOCTOU (Time-Of-Check-to-Time-Of-Use) problem is known for a while [1].  Nevertheless such bugs are still not uncommon. 
That is more or less acceptable for general software but not for security products. I believe there are drivers that 
hook kernel system services by well known technique [2,3,4]. Those hooks are used to provide mandatory access 
restriction to registry, files, processes, etc. Of course all that products suffer from TOCTOU bugs.

Problem Details

General practice suppose following algorithm

Technique 1.
Hooked service entry point
        1) get object name
        2) check object name against security policy rules
        3) if access allowed then call original kernel service function
        4) if access denied return error code

As object name is in user memory, attacker may change it between steps 2 and 3. So attacker calls system service with 
object name for which access is not restricted. Than object name is simultaneously changed in order to point at 
restricted object.

Some products seem a bit aware of this problem and use slightly different approach.

Technique 2.
Hooked service entry point
        1) call original kernel service function to get object handle
        2) get object name from handle
        3) check the name against security policy rules
        4) if access allowed then return success
        5) if access denied then close the object handle and return error

The approach is also vulnerable, as attacker may use the handle to access object between steps 2 and 4.

I have developed small demo driver hookdemo.sys which hooks ZwOpenKey system service in order to prevent any access to 
'HKLM\SOFTWARE\hookdemo\test1' registry key. The driver uses both described hooking techniques. After driver started 
you have no access on specified registry key by usual means.
Hookcrack tool demonstrates how to successfully bypass hookdemo.sys restrictions.
Both driver and hookcrack as well as their source code may be found at 
http://www.securesize.com/Resources/hookdemo.shtml.

To bypass the protection of first kind of hook, hookcrack  calls ZwOpenKey with non-restricted key name 'test2'. At the 
same time separate thread change the name buffer to 'test1'.
My tests shown that restricted registry key is accessed in around 5000 iterations, approximately 10 seconds on p4 1.3.
To bypass second hook technique, hookcrack tries to access some registry key to get handle value. That handle value 
will be the same any time hoocrack starts. The value is saved in generated crack.bat which start hookcrack and supply 
handle to it as a parameter. Hookcrack calls ZwOpenKey with target key name and at the same time reads that registry 
key value from separate thread using known handle value.
By this method I was not able to bypass protection in reasonable time on one CPU machine, but on dual CPU machine the 
crack succeed just in 3-5 iterations. 

Except specified brute force attacks more advanced attacks are possible by using hardware debug breakpoints on memory 
access.

Who is affected?

I'm not aware particular products suffer this problem but system service hooking is quite popular among developers as 
it provides abilities that are not present OS's API and proved to be reliable and compatible through different NT 
versions. 
At least, if security product mandatory restricts access to registry on Windows NT prior XP then with high degree of 
probability it has this bug. 

Ho to fix it.

The problem occurs because checks are used against user mode accessible resources: name buffer and user mode handle. To 
mitigate this, hooked service must copy user mode OBJECT_ATTRIBUTES structure with all its sub-buffers to kernel 
memory. In general, it's not trivial task as requires: 
1) composing new name from RootDirectory handle and ObjectName
2) copying security descriptor
3) copying SecurityQualityOfService structure which is undocumented.

Once OBJECT_ATTRIBUTES structure is copied to intermediate kernel memory buffer hook must recursively call the same 
system service. Passing control to original system service merely doesn't work as 'previous mode' is still set to 
UserMode and system expects user memory buffers. In case of recursive call 'previous mode' is set to KernelMode and 
kernel memory buffers are accepted. It works but open another worst security hole because system will bypass all 
security check when call originated from kernel, 'previous mode' set to KernelMode. To close this hole, hook must 
perform all security checks itself which is quite complicated task to be done correctly and impossible at all in some 
cases.
So, correct implementation of mandatory security rules by system service hooks is very complicated and rather 
impossible to achieve. Access to device manager objects (files and devices) may be effectively restricted by standard 
filter drivers. Unfortunately it is impossible for rest of objects, such as registry keys, LPC ports, processes, 
threads. However, XP and w2k3 provide registry callback mechanisms that may be used for access restriction to registry. 
If you still in doubt how to fix it, take a look at GeSWall NT framework.
Note, that we stress mandatory restrictions policies implementations. Of course, it is always possible to set standard 
NT ACLs on any type of objects.


[1] http://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/1996-compsys.pdf
[2] http://www.windowsitlibrary.com/Content/356/06/2.html
[3] http://www.sysinternals.com/ntw2k/source/regmon.shtml
[4] http://www.wiretapped.net/~fyre/sst.html
  

Best wishes for New Year!

 Andrey