KHOBE Cause Temblor

Matousec did cause some temblor in the infosec community with the KHOBE attack paper published last week. See my earlier post Windows TOCTTOU Attacks with KHOBE for the initial material.

KHOBE has gotten a lot of publicity and has generated active response and commentary from the anti-virus industry already. Temblor reached the internet s0c1ety also due to some "juicy" details published in a GData blog post about their recent communication with Matousec in order to get more information and evaluate the effect on their software correctly.

It is the art of vulnerability disclosure, no? The difficulty to handle all the aspects of disclosing delicate information. Considering that Matousec apparently did disclose privately their full research to their "clients and other software vendors" already in August 2008 and (especially) considering the fact that the KHOBE code is a result of some years of research and development, I personally find it only correct that Matousec now sell the full details and offer audit services for paying customers only. On the other hand, helping out an affected vendor a bit beyond the public paper is not too much to ask either IMO, so lets leave it to 1-1.

The technical talk about the attack has been somewhat limited due to all this. Anti-virus vendors want to see code before assessing the threat further and have concentrated responding only to the facts detailed in the Matousec paper for now. See Paul Ducklin´s blog post from Sophos for a thorough write-up on the issue, which in my opinion does good job in summarizing the initial vendor stance on KHOBE across the field as well.

While I completely agree with the point about layered defense providing security beyond the system call and parameter checks (and find the point about unknown malware bypassing the protection with or without KHOBE to be logical), I think the discussion is far from being over yet. Let's assume we are running a multicore/multiprocessor system for the rest of the post. System where the threads are not competing for the clock cycles of only one processor, but have multiple parallel clock cycles to choose from and are able to actually run parallel in time.

I suspect various security software in this type of Windows system to be highly vulnerable to the attack. I am limited to the information available in the KHOBE paper about Matousec´s findings, but studying the earlier papers published about the TOCTTOU attacks on Windows leaves me feeling like possibly every validation check done on Windows platform is vulnerable.

The problem is not really the SSDT hooking dominating the public discussion at the moment. As far as I can see the root cause of the vulnerability lies somewhere in the way the data is being validated on Windows. In the way it is being referenced in the validation process and especially in the alarming detail that the memory areas being validated can actually be manipulated while they are being validated in some cases.

Seems like the KHOBE code focuses on exploiting the vulnerability in software which uses SSDT hooks in order to intercept the system calls and validate the parameters, but I doubt the exploitation is limited to checks initiated by SSDT hooks. The problem really is the accessibility of the memory areas under validation, not the way the checks are initiated. Any type of validation check requires multiple clock cycles, which possibly allow a parallel thread  running on parallel clock cycles plenty of time to manipulate the values in the memory while they are under examination and possibly cause invalidated malicious parameters actually to be passed to the processor for execution.

The anti-virus vendors rushed a bit in my opinion to declare that any known malware would be detected regardless of KHOBE due to various alternations monitored in the system. While true obviously for big zoos of known malicious code, it does not exactly address the issue sufficiently in the enterprise environments.

Imagine an installer exploiting TOCTTOU vulnerabilities. Used in a staged attack as the initial payload for bypassing the security checks when installing further compromise tools including a malicious communication component again utilizing the technique to bypass the firewall for stealth communications. The race condition exists as long as the user memory objects can be manipulated, while the values are being examined.

It is not the end of the world by any means, but definitely something to keep an eye on. Very possibly maybe a real threat (at least until more details about KHOBE are published), but in any case a serious vulnerability which apparently exists and which probably require some changes both to the Windows kernel and to the security software functionality in order to get solved completely.

One more reason for the enterprises to ensure they have adequate incident response capabilities available in addition to the preventive security mechanisms. All the hope obviously should not be placed on the anti-virus vendor and the end point protection. Preventive security measures will be circumvented repeatedly and intrusions do happen. Just as trusted systems need hardening, they need constant intrusion and integrity monitoring throughout their lifetime.

Windows TOCTTOU Attacks with KHOBE

Matousec has been one of these unsung Internet heroes for sometime already. I know them from actively testing Windows software firewalls and openly sharing the test results as well as the testing methods on their website. But what may have started in 2006 as a small security software testing group, have by now truly matured into a cutting edge research crew.

They published a somewhat groundbreaking vulnerability advisory 2010-05-05.01 on their website last week. The vulnerability and the attack is explained in the accompanying article entitled KHOBE – 8.0 Earthquake For Windows Desktop Security Software.

Matousec did not publicly release the KHOBE engine code with all the research implemented, but apparently they have created a tool to successfully bypass the majority, if not almost all, of the kernel mode security checks performed by the current Windows security software. Think malware checks by the anti-virus software, traffic content checks by the software firewall, all bypassed in the final frontier in kernel mode.

In short the attack exploits a specific type of race condition previously known as time-of-check-to-time-of-use (TOCTTOU) bug, which (apparently almost constantly) occur when Windows security software is performing its various check ups on application behavior. The attack was documented already in 1996 in the Checking for Race Conditions in File Accesses (PDF) paper by Matt Bishop and Michael Dilger and the vulnerability was detailed further by Andrey Kolishak in the end of 2003 in his Bugtraq mailing list post entitled TOCTOU with NT System Service Hooking.

The attack happens on the thread level in the system. There in the grey area between the user mode and the kernel mode where the application threads are calling various operating system services in order to install and execute correctly in the system. There the modern security software appears as additional or hooked functionality to the operating system usually adding some type of mandatory access control for calls to the Windows registry, running process and files among other things.

The security applications usually modify the System Service Descriptor Table (SSDT) in Windows replacing various entries in the table and thus causing the calls and the parameters passed to these services to be examined by the security application. Matousec presented calls to load system drivers and calls to terminate processes as examples, but there are multiple calls that get intercepted by similar methods.

The vulnerability is largely due to the fact that although the hooks may be in kernel mode, the actual memory buffer content and the parameter content of the calls are in the user mode address space and therefore accessible to the attacker. He would need to run two threads, but he will be able to manipulate the buffer or the parameter content concurrently while it is being checked by the security thread. The attacker is able to pass a legitimate value to the security thread and have it validated as acceptable, but then get the concurrently manipulated malicious value to be actually passed to and processed by the called system service.

Sounds very theoretic and applicable only with good luck and with the famous specific conditions? According to Matousec the current version of the KHOBE engine successfully and reliably bypassed the tested security checks in ALL tested software on Windows XP SP3 and Windows Vista SP1 systems running on 32-bit hardware. They point out that with some "smart manipulation" of the thread priorities and the ever more common multicore/multiprocessor hardware allowing them to literally run their attack threads parallel in time to the security threads, they are able to create the necessary conditions for a successful attack in the matter of seconds.

Do not sleep on the bolded comment made by Matousec when listing the known affected products that due to "time limitation" only limited number of products have been tested, but they suspect that majority of the Windows security software is/was vulnerable to the attack. Matousec also states that the KHOBE engine should work equally on Windows 7 and on 64-bit hardware, but this has not been tested yet. Apparently the currently used methods to hook the security software functionality to both user mode and kernel mode are vulnerable by design regardless of platform version.

Matousec did not publish their suggested solution for the attack publicly, but my guess is this will be hard to fix. First thing that come to mind is attempting to limit the time the security check ups take in order to narrow down the race condition time frame, but obviously this would be only mitigation, not the solution. Maybe the memory areas under examination could be locked for the time it takes to verify them. In any case there is very little a system administrator or an user can do. The changes needed here have to happen in the operating systems or in the security software.

Symantec by the way have acknowledged the validity of the attack in a communication sent to their enterprise customers. They do not however consider it a vulnerability in their products for now, but rather (a bit confusingly) a problem present in "any product that implements kernel-mode hooking". For mitigation they recommend to harden the other layers of defense in order to prevent this type of malicious code from getting into the system.