Blocking particular process from getting terminated

Stupid feature, in any case. But it’s possible with

http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692(v=vs.85).aspx

Just register for Pre-handle creation and strip the rights (e.g. Terminate) from the handle

On Oct 16, 2014, at 9:00 PM, xxxxx@hotmail.com wrote:

Currently i’m working on a project. Company i’m working for has this product xyz.which when installs in computer proactively cleans temporary file and do some other work. Then this requirement comes that when the product is running user cant kill process manually. which will not hinder the work.

It?s not up to you. It?s my computer, not yours. If I want to kill your process, I have the right to do so.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks Frank…

@Tim: yes tim its ur computer .do whatever u want…
this feature is not for end user. Its for enterprise…

> this feature is not for end user. Its for enterprise…

Yes, and it’s their computer and not yours.

If their admin wants to kill the process, then he/she should be allowed to do this.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Yes they will kill process if they want.
denying a computer administrator to terminate a process is wrong, so process self-protection should be avoided.
This is true 99% of the cases, the remaining 1% are those cases when a process is vital for the system infrastructure security such as anti malwares, IPS and IDS. Those kind of softwares have to protect themself from malicious software trying to terminate their services and processes or inject arbitrary code into their executable address space, so that’s when an appropriate protection is vital.

This problem is already solved:

  1. The users in enterprise infrastructure MUST NOT have administrative privilege.
  2. The applications in enterprise infrastructure MUST be installed by an administrator or by remote installation which runs in a privileged context. Users CANNOT kill the installer in such a case.

And the problem with these cases is that about half the stupid firms don’t
provide an appropriate kill switch for the program. I have turned down
requests for being an “expert witness” because a firm thinks their program
is “so important” they don’t provide a way to terminate it. I am not sure
any of the cases really ended in court, but I know some of the situations
the “we will protect our program against anything” were asking where are we
getting the money to pay our programmers after the enterprise customer was
done with them.

Mr Grig has it right, Use administrative privledge, worst case provide a
confirmation dialog to ensure that termination is what is really wanted.
Trying to stop termination is another one of these idiot chases like trying
to complete clean an infected system while it is running, you are not going
to be able anticipate all the potential ways.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, October 17, 2014 8:59 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

Yes they will kill process if they want.
denying a computer administrator to terminate a process is wrong, so process
self-protection should be avoided.
This is true 99% of the cases, the remaining 1% are those cases when a
process is vital for the system infrastructure security such as anti
malwares, IPS and IDS. Those kind of softwares have to protect themself from
malicious software trying to terminate their services and processes or
inject arbitrary code into their executable address space, so that’s when an
appropriate protection is vital.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Use ObRegisterCallback(), its pretty easy & theres tons of sample code and info about it around, just look on a search engine.

After looking I saw its not easy to find via search engine so heres one (of several) links - http://stackoverflow.com/questions/20552300/hook-zwterminateprocess-in-x64-driver-without-ssdt

I guess that your statement may hold true under the condition that user is warned about these features
BEFORE purchasing your product and is allowed to cleanly uninstall it (or explicitly warned of inability to do so).

After all, it does not conflict with Tim’s and Max’s statements in any possible way - indeed, it is user’s computer, and it is his/her/its right to install a product that effectively strips him/her/it of his/her/its right to control his/her/its own machine in the name of the “security”. Such a product is not necessarily bound to be as unattractive to the end users is it may seem to at the first glance. Instead, it may be VERY attractive to some ( just look at Mac users if you don’t believe it - they are ready to spend a night in a queue in order to be among the first ones who had purchased a new upgrade of a product that controls their every move).

However, users just have to be warned - otherwise, you product is nothing more than just a piece of a malware with a high potential of landing its authors in a courtroom…

Anton Bassov

xxxxx@hotmail.com wrote:

This is true 99% of the cases, the remaining 1% are those cases when a process is vital for the system infrastructure security such as anti malwares, IPS and IDS. Those kind of softwares have to protect themself from malicious software trying to terminate their services and processes or inject arbitrary code into their executable address space, so that’s when an appropriate protection is vital.

But the problem is unsolvable. Don’t you see that? Whatever your
process can do, a malicious process can do as well, and can also UNDO.
You can’t make your process bulletproof. It’s impossible. The malware
writers are smarter than you are. Once you have malicious software with
admin or kernel privileges, the game is over, and you have lost. There
is no solution short of reformatting.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> But the problem is unsolvable. Don’t you see that? Whatever your process can do, a malicious

process can do as well, and can also UNDO.

Well, this is just the question of who was the first one to get there…

If you install such a product on a clean machine there will be simply no malicious processes in sight, unless it was user’s choice to allow them to run by installing their binaries. However, if the target machine has been already infected by the time you install your process there is nothing that can be done.

To put it simply, there are 3 security problems - prevention, detection and cleaning. The first one is perfectly solvable at the target system itself as long as it is clean, the second one may be sometimes solvable at the target system as well, and the third one is simply infeasible unless you use some independent installation, rather than a target system itself - you just cannot do anything about the system that has been compromized at the level of its kernel…

Anton Bassov

Thanq @adam, @alex, @tim, @anton, @don for ur comments
I understand ur point of view. But as i said mine is a product company which design product according to clients requirement. If they want in their infrastructure no one should be able to kill any particular exe so then it be. They have their own requirement their own point of view.

Now its upon them if they want some kind of kill switch or not.

but according to me i find this idea intriguing one able to protect their exe from getting terminated by other user…

@anton i completely agree with you (there are people who will buy anything jst in the name of glamour-- Celebrity branding is nothing new – get a reasonably famous person to attach their name to a product, and suddenly $10 product will become $100)

well thanq everyone for ur valuable comments i got what i wanted.

Tim Roberts - Thats an interesting comment, and I generally agree with you. However in this case, the only way I am aware of to remove the process protection is to call ObUnregisterCallback(). Are you implying that a malicious program can call ObUnregisterCallbacks() and remove my protection from outside of my kernel module (.sys), or similar? Thanks.

Assuming the malware has infected the kernel, then even with that protection
there are so many things that can be done to mess up the your program. For
example, the malware can corrupt the executable so it crashes, or gently
modify it so it sleeps forever.

As Tim pointed out, once a system is infected you cannot use that system to
clean itself up. Any belief that you can is a fools errand.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, October 18, 2014 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

Tim Roberts - Thats an interesting comment, and I generally agree with you.
However in this case, the only way I am aware of to remove the process
protection is to call ObUnregisterCallback(). Are you implying that a
malicious program can call ObUnregisterCallbacks() and remove my protection
from outside of my kernel module (.sys), or similar? Thanks.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

First, I agree with you, the malware is going to win 99% of the time as offense is way easier than defense. But for the sake of educational argument (as I’m not very farmiliar with this), let’s assume that the infection has occured after my driver is loaded. The driver protects against file modification via a minifilter FltRegFilter(), and is also protecting against process termination via ObRegisterCallbacks(). There’s also another routine blocking remote threads. The attacker cannot modify any binaries, nor use Read/WriteProcMem(), no TermProc(), no CreateRemoteThread(), no SSDT hooks, etc. Apart from offline attacks - how do you destroy my process?

OK nevermind an attacker can still attach a debugger to my process and make changes in memory.

If the malware is in the kernel, then it can attach to your process, have
access to your memory space, and modify it. At that point your process
image is hosed. Depending on when you filter gets loaded versus the malware
there are ways around the file protection, so I can change your protected
application to be malware.

Malware is going to win 99.9% of the time, you may be able to defeat a
specific threat vector, but then all they need is to improve slightly to
bypass that.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Saturday, October 18, 2014 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Blocking particular process from getting terminated

First, I agree with you, the malware is going to win 99% of the time as
offense is way easier than defense. But for the sake of educational argument
(as I’m not very farmiliar with this), let’s assume that the infection has
occured after my driver is loaded. The driver protects against file
modification via a minifilter FltRegFilter(), and is also protecting against
process termination via ObRegisterCallbacks(). There’s also another routine
blocking remote threads. The attacker cannot modify any binaries, nor use
Read/WriteProcMem(), no TermProc(), no CreateRemoteThread(), no SSDT hooks,
etc. Apart from offline attacks - how do you destroy my process?


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Once again, you are trying to engage in battle that can’t be won.

“Let’s give everybody in the city the same locks and keys. Because that’s very convenient.”

“But how about thieves?”

“We’ll install automated guns with face recognition on each door”

The problem you are trying to solve just DOES NOT EXIST in properly configured enterprise.
Windows gives you user accounts, trusted installer, administrative accounts. Allowing users have administrative accounts is as wise as just running Windows 95.

Well, your only bet here is to ensure that the system DOES NOT get infected, and this is what your software may, indeed, achieve (not by some “super-intelligence” on its own but simply by ensuring that no one is able
to run on the target system, apart from those binaries who were explicitly allowed to do so by the user).
This is known as whitelisting, and it is the only approach to the security that is known to work. Basically, this is just the logical equivalent of EXECUTE access flag, i.e. something that has been present on UNIX-like systems since the inception of UNIX…

However, if user allows some malicious kernel module to get loaded all your future attempts to protect the system are doomed to failure.More on it below…

Apart from offline attacks - how do you destroy my process?

Well, let’s say simply by removing all its KTHREADS/ETHREADs from the list of active threads, effectively rendering all your protection useless and turning it into the oblivion. Similarly, all your executable code can get replaced with the sequence of NOPs; all your hooks can get undone, etc,etc,etc - all these tricks can be done by anyone who gets an access to the kernel address space…

In other words, just keep on repeating “whenever a malicious kernel module gets loaded all my bets are off”
mantra until you finally learn to think of it like of the laws of motion, of thermodynamics, etc…

Anton Bassov