[Vrtule]

Hello,

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

[EP_X0FF]

Thanks, race condition :) It will require however cycle with huge amount of iterations.

[Vrtule]

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.

[EP_X0FF]

KeEnterCriticalRegion / KeLeaveCriticalRegion will save the planet.

[Vrtule]

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.

[EP_X0FF]

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) {
                KiLockDispatcherDatabaseAtSynchLevel();
                Thread->SuspendSemaphore.Header.SignalState -= 1;
                KiUnlockDispatcherDatabaseFromSynchLevel();

            } 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.

[EP_X0FF]

In continuation of this Matousec di$covery.

Original idea

http://seclists.org/bugtraq/2003/Dec/351

which is based on theory

http://seclab.cs.ucdavis.edu/projects/v ... ompsys.pdf

Such a clever thief now asking for $.

[USForce]

I totally agree with EP_X0FF. Just a huge race condition, imho it's useless

[Dreg]

http://www.rootkit.com/vault/DiabloNova ... _bucks.rar <-- Very nice read!

[Alex]

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.

Alex