TOCTOU with NT System Service Hooking
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