A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about user-mode development.
 #1001  by Vrtule
 Thu May 06, 2010 3:08 pm

Finally, it is time to disclose a vulnerability that affects (as it seems) all security software known as "Personal firewalls" etc. It lies in the way vendors implement hooking (the article shows it on SSDT for illustration) in their software. We made the tests on Windows XP SP3.

The article can be found at:

http://www.matousec.com/info/articles/k ... ftware.php
 #1005  by Vrtule
 Thu May 06, 2010 4:39 pm
The tests show that the attack succeeds after just few attempts, in most cases. It depends how the attacker choose thread priorities and on the mood of the scheduler.

When I tried Kaspersky for example, the situation when the attack succeeded by the first attempt to switch the arguments was not so rare as one could say.
 #1009  by Vrtule
 Thu May 06, 2010 8:24 pm
Do disabled normal kernel mode APCs disable thread scheduling? I read that scheduler code runs partially in DISPATCH_LEVEL and uses DPCs, not APCs.

However, it should not help on multiprocessor machines, where no context switch is needed.
 #1012  by EP_X0FF
 Fri May 07, 2010 3:05 am
We have 2 threads. First thread calling service (for example NtTerminateProcess) without required rights, so NtTerminatProcess gives you STATUS_ACCESS_DENIED. Second thread suspends first, frees handle and opens target process. Handle value will be the same. After this we resuming first thread. So TrueNtTerminateProcess(hProcess, ExitStatus) will get different process handle. When acquiring a resource while running in not system thread and runs at passive level we need to disable kernel APCs. Otherwise any user mode code can call NtSuspendThread which is implemented as call to PsSuspendThread->KeSuspendThread where all job is done with (see below), and suspend the thread while having a resource acquired.
Code: Select all
        // Increment the suspend count. If the thread was not previously
        // suspended, then queue the thread's suspend APC.
        // N.B. The APC MUST be queued using the internal interface so
        //      the system argument fields of the APC do not get written.

        Thread->SuspendCount += 1;
        if ((OldCount == 0) && (Thread->FreezeCount == 0)) {
            if (Thread->SuspendApc.Inserted == TRUE) {
                Thread->SuspendSemaphore.Header.SignalState -= 1;

            } else {
                Thread->SuspendApc.Inserted = TRUE;
                KiInsertQueueApc(&Thread->SuspendApc, RESUME_INCREMENT);
This is potential deadlock btw.

Practically usefulness of this Matousec discovery is doubtful. I believe this can be easily fixed.
 #1055  by Alex
 Mon May 10, 2010 5:47 pm
Software which hooks kernel services only exists because most of their users use Administrator account and they think they are secure. It's obvious that if user doesn't have full rights he can't create/delete/overwrite/terminate resources secured by default. Security companies doesn't care about secure writing their code and that's why digitally signing is useless in all these cases when signed drivers have exploitable vulnerabilities. Most of security companies have been fixed vulnerable code of procedures filtrating kernel services, but there are many other things which should be carefully analyzed before signing and publishing final product. For example they still don't care or don't know that user passed buffers won't be correctly probed if passed buffer length is equal to zero, they don't care or don't know that user passed parameters should be copied to local buffers before they will be examined, and so-one...

This rehashed "discovery" shows how weak security softwares are, but there are more serious vulnerabilities which allow to not only replace service's parameters or cause DoS (most of incorrectly hooked services can cause DoS) but also cause privilege escalation user/system, user/kernel or admin/kernel which can breaks all filters without any magic.

There is good example of real vulnerability found in win32k.sys module - MS08-061 : The case of the kernel mode double-fetch.