Process Termination with Antirootkit gives BSOD

NTDEV
21

> In order to traverse the list without causing any synchronization issues, you need to

prevent context switching by setting all CPUs to DISPATCH_LEVEL. This can be done
by raising the >current processor’s IRQL to DISPATCH_LEVEL and then sending DPCs to the rest
of the processors.

As Jonathan already pointed out, it is just not going to work…

What one can do is to “turn MP system into UP one” for the duration of the operation. This technique is
quite ugly and inefficient, but still i 100% reliable. What you have to do is to start system threads that raise IRQL to DPC level and spins in do-nothing loop until the state of a global variable get set to true on all CPU, apart from the one that is going to access the target memory location. We discussed it a couple months ago - check the following thread for more detailed description of it http://www.osronline.com/showThread.cfm?link=123765

Anton Bassov

22

No - because the interrupted modifier thread is holding the lock. That is
the point of having the lock and why you will screw up the list if you
modify it outside of the lock. :slight_smile:

Also - remember that the dispatcher schedules threads - not processes - so
there is no correlation between the process list modification and thread
scheduling. In the case you mention - if the “next thread” tries to modify
the list it will first grab the lock - which in this case will cause it to
block until the interrupted thread runs again and releases the lock.

“Ilias Tsigkogiannis” wrote in message
news:xxxxx@ntdev…
So, what happens in the “normal” case, where the process lock is already
acquired at passive level and at that moment the quantum ends, so the
scheduler decides to do a context switch? Won’t there be a blue screen?

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
On Behalf Of the_el_vez [xxxxx@microsoft.com]
Sent: Sunday, March 16, 2008 10:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Process Termination with Antirootkit gives BSOD

I think that book is pretty good as well - however, the problem with 2) is
that the process lock is sometimes acquired at passive level so you may send
a DPC and interrupt the processor that is currently modifying the list
legally (while holding the process lock) - and screw up the list up nicely
when the interrupting thread removes the process from the list. There really
is no way to do this correctly. It will always have a really high
probability of crashing the system. :slight_smile:

“Ilias Tsigkogiannis” wrote in message
news:xxxxx@ntdev…
The whole mechanism on how to traverse the process list and deal with the
synchronization issues is described by the book “Rootkits: Subverting the
Windows Kernel” from Greg Hoglund and James Butler.

I haven’t tried the suggestions from that book, so I don’t know how well
they work, however according to the book:
1) In order to prevent the “hidden” process (i.e. a process that was removed
from the operating system’s process list) from crashing, when you terminate
it, you need to change the Flink and the Blink to point to its own Flink.
2) In order to traverse the list without causing any synchronization issues,
you need to prevent context switching by setting all CPUs to
DISPATCH_LEVEL. This can be done by raising the current processor’s IRQL to
DISPATCH_LEVEL and then sending DPCs to the rest of the processors.

The book has way more details on that and I suggest reading it, unless
somebody else from the list thinks that this solution won’t work (as I said,
I just point out what I read in the book, since I haven’t tried it, so I
don’t know how well it works).

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
On Behalf Of Dan Kyler [xxxxx@privtek.com]
Sent: Sunday, March 16, 2008 6:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Process Termination with Antirootkit gives BSOD

The discussion on the process list, synchronization thereto, etc, while
somewhat interesting is pretty irrelevant. While I wholeheartedly agree
with those that say you shouldn’t do what you’re doing, I’m sure you’re
going to do it anyway.

So, have you tried the painfully simple what-the-hell-are-you-thinking
obvious? If process termination is doing a RemoveEntryList on the EPROCESS,
why don’t you put it in a damn list before you kill it? Any list should do;
try a locally declared LIST_ENTRY.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, March 14, 2008 12:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Process Termination with Antirootkit gives BSOD

Hi All,

I am working in Quick Heal Techonologies Pvt. Ltd., which is a security
company. We have developed a AntiRootkit product which is capable of finding
processes hidden by system call hooking or Direct Kernel Object
Manipulation.

But the problem is when we terminate the process kernel gives BSOD if the
process is hidden by Direct Kernel Object Manipulation technique.

I found that this is due to following reason…
Rootkit alters linklist of active processes to remove the node(EPROCESS) of
the process to be hidden. It adjust the pointers in link list to make it
consistent but leave the pointers in EPROCESS of the process to be hidden as
it is. That means pointers in EPROCESS are invalid, but when we terminate
the process the system call trys to remove the process from active link
list, which is not there. Thus, these manupulations creates inconsistency in
link list and result in BSOD.

Is there any solution to this problem?

Thanks & Regards,
Amit.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

23

Amit,
The locking situation in Ke and Ps is not to be trifled with if you value the stability of an NT system. Might I suggest the considerably safer (but equally undocumented) approach of suspending the evil process(es) from kernel mode and preventing them from loading on the next boot? If there are multiple ones monitoring each other, you might get by with Anton’s DPC trick to suspend everyone before they get a chance to execute (it’s not that safe, so don’t do it without thinking carefully about deadlocks).

On tangential note:
My personal belief is that this anti-malware arms race is getting to the point where it would be more effective and profitable to start a product that whitelists all the instances of known beneficial kernel-mode software and rejects anything else.

Neeraj Singh
SDET
Windows Kernel Services

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of the_el_vez [xxxxx@microsoft.com]
Sent: Monday, March 17, 2008 12:29 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Process Termination with Antirootkit gives BSOD

No - because the interrupted modifier thread is holding the lock. That is
the point of having the lock and why you will screw up the list if you
modify it outside of the lock. :slight_smile:

Also - remember that the dispatcher schedules threads - not processes - so
there is no correlation between the process list modification and thread
scheduling. In the case you mention - if the “next thread” tries to modify
the list it will first grab the lock - which in this case will cause it to
block until the interrupted thread runs again and releases the lock.

“Ilias Tsigkogiannis” wrote in message
news:xxxxx@ntdev…
So, what happens in the “normal” case, where the process lock is already
acquired at passive level and at that moment the quantum ends, so the
scheduler decides to do a context switch? Won’t there be a blue screen?

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
On Behalf Of the_el_vez [xxxxx@microsoft.com]
Sent: Sunday, March 16, 2008 10:45 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Process Termination with Antirootkit gives BSOD

I think that book is pretty good as well - however, the problem with 2) is
that the process lock is sometimes acquired at passive level so you may send
a DPC and interrupt the processor that is currently modifying the list
legally (while holding the process lock) - and screw up the list up nicely
when the interrupting thread removes the process from the list. There really
is no way to do this correctly. It will always have a really high
probability of crashing the system. :slight_smile:

“Ilias Tsigkogiannis” wrote in message
news:xxxxx@ntdev…
The whole mechanism on how to traverse the process list and deal with the
synchronization issues is described by the book “Rootkits: Subverting the
Windows Kernel” from Greg Hoglund and James Butler.

I haven’t tried the suggestions from that book, so I don’t know how well
they work, however according to the book:
1) In order to prevent the “hidden” process (i.e. a process that was removed
from the operating system’s process list) from crashing, when you terminate
it, you need to change the Flink and the Blink to point to its own Flink.
2) In order to traverse the list without causing any synchronization issues,
you need to prevent context switching by setting all CPUs to
DISPATCH_LEVEL. This can be done by raising the current processor’s IRQL to
DISPATCH_LEVEL and then sending DPCs to the rest of the processors.

The book has way more details on that and I suggest reading it, unless
somebody else from the list thinks that this solution won’t work (as I said,
I just point out what I read in the book, since I haven’t tried it, so I
don’t know how well it works).

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com]
On Behalf Of Dan Kyler [xxxxx@privtek.com]
Sent: Sunday, March 16, 2008 6:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Process Termination with Antirootkit gives BSOD

The discussion on the process list, synchronization thereto, etc, while
somewhat interesting is pretty irrelevant. While I wholeheartedly agree
with those that say you shouldn’t do what you’re doing, I’m sure you’re
going to do it anyway.

So, have you tried the painfully simple what-the-hell-are-you-thinking
obvious? If process termination is doing a RemoveEntryList on the EPROCESS,
why don’t you put it in a damn list before you kill it? Any list should do;
try a locally declared LIST_ENTRY.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, March 14, 2008 12:35 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Process Termination with Antirootkit gives BSOD

Hi All,

I am working in Quick Heal Techonologies Pvt. Ltd., which is a security
company. We have developed a AntiRootkit product which is capable of finding
processes hidden by system call hooking or Direct Kernel Object
Manipulation.

But the problem is when we terminate the process kernel gives BSOD if the
process is hidden by Direct Kernel Object Manipulation technique.

I found that this is due to following reason…
Rootkit alters linklist of active processes to remove the node(EPROCESS) of
the process to be hidden. It adjust the pointers in link list to make it
consistent but leave the pointers in EPROCESS of the process to be hidden as
it is. That means pointers in EPROCESS are invalid, but when we terminate
the process the system call trys to remove the process from active link
list, which is not there. Thus, these manupulations creates inconsistency in
link list and result in BSOD.

Is there any solution to this problem?

Thanks & Regards,
Amit.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

24

> Might I suggest the considerably safer (but equally undocumented) approach of

suspending the evil process(es) from kernel mode

It is not safer at all - the only reason why the OP crashes is because the system is already screwed up, so that even “legal” call to TerminateProcess() from the user mode may result in crash…

My personal belief is that this anti-malware arms race is getting to the point where it would
be more effective and profitable to start a product that whitelists all the instances of known
beneficial kernel-mode software and rejects anything else.

This kind of product is not really needed, because the OS already provides built-in mechanism to achieve the above mentioned goal - just don’t routinely run your OS with admin privileges, and that’s it. Certainly, some users don’t do it simply because of supposed “inconvenience”, and this is the only reason why they get infected by kernel-level rootkits. What is the chance that user goes for even more “inconvenience” that the use of the above product inevitably implies if he/she cannot be bothered even to setup non-admin account for daily use and log on as an admin in order to run administrative tasks???

Therefore, in practical terms, security software has to deal not only with prevention, but with detection and cleaning as well .

In any case, any anti-rootkit product may be “best-effort service” only - well-written rootkit may get loaded before the OS, and, at tis point, you are totally helpless…

Anton Bassov

25

The suspend codepath is safer because does much less work than the terminate codepath.

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com [xxxxx@hotmail.com]
Sent: Monday, March 17, 2008 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Process Termination with Antirootkit gives BSOD

Might I suggest the considerably safer (but equally undocumented) approach of
suspending the evil process(es) from kernel mode

It is not safer at all - the only reason why the OP crashes is because the system is already screwed up, so that even “legal” call to TerminateProcess() from the user mode may result in crash…

My personal belief is that this anti-malware arms race is getting to the point where it would
be more effective and profitable to start a product that whitelists all the instances of known
beneficial kernel-mode software and rejects anything else.

This kind of product is not really needed, because the OS already provides built-in mechanism to achieve the above mentioned goal - just don’t routinely run your OS with admin privileges, and that’s it. Certainly, some users don’t do it simply because of supposed “inconvenience”, and this is the only reason why they get infected by kernel-level rootkits. What is the chance that user goes for even more “inconvenience” that the use of the above product inevitably implies if he/she cannot be bothered even to setup non-admin account for daily use and log on as an admin in order to run administrative tasks???

Therefore, in practical terms, security software has to deal not only with prevention, but with detection and cleaning as well .

In any case, any anti-rootkit product may be “best-effort service” only - well-written rootkit may get loaded before the OS, and, at tis point, you are totally helpless…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

26

Actually, that “legal” call fails just because the Flink and the Blink of the process node point to random memory. Just setting them to point to the “hidden” process should fix the BSOD.

The mechanism with the system threads that spin in dispatch level wouldn’t also work, if the process lock can be held at passive level. It has the same end result as sending DPCs to the other processors.

Ilias

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com [xxxxx@hotmail.com]
Sent: Monday, March 17, 2008 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Process Termination with Antirootkit gives BSOD

Might I suggest the considerably safer (but equally undocumented) approach of
suspending the evil process(es) from kernel mode

It is not safer at all - the only reason why the OP crashes is because the system is already screwed up, so that even “legal” call to TerminateProcess() from the user mode may result in crash…

My personal belief is that this anti-malware arms race is getting to the point where it would
be more effective and profitable to start a product that whitelists all the instances of known
beneficial kernel-mode software and rejects anything else.

This kind of product is not really needed, because the OS already provides built-in mechanism to achieve the above mentioned goal - just don’t routinely run your OS with admin privileges, and that’s it. Certainly, some users don’t do it simply because of supposed “inconvenience”, and this is the only reason why they get infected by kernel-level rootkits. What is the chance that user goes for even more “inconvenience” that the use of the above product inevitably implies if he/she cannot be bothered even to setup non-admin account for daily use and log on as an admin in order to run administrative tasks???

Therefore, in practical terms, security software has to deal not only with prevention, but with detection and cleaning as well .

In any case, any anti-rootkit product may be “best-effort service” only - well-written rootkit may get loaded before the OS, and, at tis point, you are totally helpless…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

27

> The mechanism with the system threads that spin in dispatch level wouldn’t also work, if the process

lock can be held at passive level. It has the same end result as sending DPCs to the other processors.

In this context the only thing that matters is that no one gets into *our* operation - once we deal with doubly-linked list, we can always discover whether the particular link we are interested in is in consistent state, i.e. whether we are about to get into the middle of someone else’s operation. Therefore, *in this context* it does not matter if the target lock allows preemtion, although it would be of crucial importance if we had no chance to double-check…

Anton Bassov