Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Blocking particular process from getting terminated

Ajit_bansalAjit_bansal Member Posts: 12
Hi all,

I'm new to windows driver. So i dont know that much in drivers

I want to ask that is there any way that somehow we can block process from getting killed through kernel mode.
I went through internet found out PsSetCreateProcessNotifyRoutine routine which will add a driver supplied callback routine which will get called every time a process is created or deleted with the boolean value is set to TRUE when process is created and FALSE when process is deleted.

With this routine i will come to know when process is deleted i can even get its loaded image . But can i stop the process from getting killed?????

It will be great if someone enlightened me on this..

sorry for english
regards,
Ajit
«1

Comments

  • Alex_GrigAlex_Grig Member Posts: 3,238
    Why do you need that? What problem are you trying to solve by that?
  • Ajit_bansalAjit_bansal Member Posts: 12
    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.

    so can i achieve this from kernel mode???
  • Frank_FriemelFrank_Friemel Member Posts: 308
    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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,958
    On Oct 16, 2014, at 9:00 PM, [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Ajit_bansalAjit_bansal Member Posts: 12
    Thanks Frank...

    @Tim: yes tim its ur computer .do whatever u want..
    this feature is not for end user. Its for enterprise..
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > 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
    [email protected]
    http://www.storagecraft.com
  • Ajit_bansalAjit_bansal Member Posts: 12
    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.
  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • Don_BurnDon_Burn Member - All Emails Posts: 1,730
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    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
  • Adam-3Adam-3 Member Posts: 18
    Use ObRegisterCallback(), its pretty easy & theres tons of sample code and info about it around, just look on a search engine.
  • Adam-3Adam-3 Member Posts: 18
    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
  • anton_bassovanton_bassov Member MODERATED Posts: 5,250
    <quote>

    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.

    </quote>


    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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,958
    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • anton_bassovanton_bassov Member MODERATED Posts: 5,250
    > 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
  • Ajit_bansalAjit_bansal Member Posts: 12
    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.
  • Adam-3Adam-3 Member Posts: 18
    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.
  • Don_BurnDon_Burn Member - All Emails Posts: 1,730
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    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
  • Adam-3Adam-3 Member Posts: 18
    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?
  • Adam-3Adam-3 Member Posts: 18
    OK nevermind an attacker can still attach a debugger to my process and make changes in memory.
  • Don_BurnDon_Burn Member - All Emails Posts: 1,730
    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: [email protected]
    [mailto:[email protected]] On Behalf Of
    [email protected]
    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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    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.
  • anton_bassovanton_bassov Member MODERATED Posts: 5,250
    <quote>

    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.

    </quote>


    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
  • Mike_KempMike_Kemp Member - All Emails Posts: 291
    >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.<

    And I suppose the formatter and the entire software path that executes it
    (BIOS, media loader etc) needs to reside on an unalterable certified medium
    too. How often does that happen?

    Mike

    ----- Original Message -----
    From: Tim Roberts
    To: Windows System Software Devs Interest List
    Sent: Friday, October 17, 2014 5:47 PM
    Subject: Re: [ntdev] Blocking particular process from getting terminated


    [email protected] 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, [email protected]
    Providenza & Boekelheide, Inc.


    ---
    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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    >And I suppose the formatter and the entire software path that executes it
    (BIOS, media loader etc) needs to reside on an unalterable certified medium
    too. How often does that happen?

    Um, every time you boot from a CD?
  • Mike_KempMike_Kemp Member - All Emails Posts: 291
    Yes, I suppose many machines still have those old CD things... and on those
    machines that support them, is the CD boot code always in unmodifiable
    memory?

    Mike

    ----- Original Message -----
    From: [email protected]
    To: Windows System Software Devs Interest List
    Sent: Monday, October 20, 2014 2:54 PM
    Subject: RE:[ntdev] Blocking particular process from getting terminated


    >And I suppose the formatter and the entire software path that executes it
    (BIOS, media loader etc) needs to reside on an unalterable certified medium
    too. How often does that happen?

    Um, every time you boot from a CD?


    ---
    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
  • Alex_GrigAlex_Grig Member Posts: 3,238
    You can always plug a USB CD drive into a box with secure boot BIOS.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,483
    <quote>
    You can always plug a USB CD drive into a box with secure boot BIOS
    </quote>

    Wait. Did somebody just say "USB" and "secure" in the same sentence... in light of all the recent talk about "badusb"?

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Alex_GrigAlex_Grig Member Posts: 3,238
    >Wait. Did somebody just say "USB" and "secure" in the same sentence... in light
    of all the recent talk about "badusb"?

    It all depends on the context. You need to install your OS somehow on a clean disk. You could do that through PXE (is your L2 network secure?), or through a CD (does your laptop have a CD anymore? Can your secureBoot BIOS boot off a CD?) or from a USB stick (badusb again?). Choose one to match your paranoia level.
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > And I suppose the formatter and the entire software path that executes it
    > (BIOS, media loader etc) needs to reside on an unalterable certified medium
    > too. How often does that happen?

    Windows setup CD is enough, it cannot be altered and everything is digitally signed on it.

    --
    Maxim S. Shatskih
    Microsoft MVP on File System And Storage
    [email protected]
    http://www.storagecraft.com
  • anton_bassovanton_bassov Member MODERATED Posts: 5,250
    >Windows setup CD is enough, it cannot be altered


    ....which applies only to the media itself.However, it has to be loaded into the memory, right? Therefore,
    if boot firmware is compromized it can alter the loaded image.....

    > and everything is digitally signed on it.

    .....including the code path that performs integrity check - it can be simply jumped over,and that's it.

    Therefore, Mike's concern is perfectly valid - all OS-level and installer-level protection can get defeated if boot firmware is compromized, and this is what he speaks about....


    Anton Bassov
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging 15 November 2021 Live, Online