Shutdown protection?

Discussion in 'NOD32 version 2 Forum' started by Buddel, Dec 1, 2003.

Thread Status:
Not open for further replies.
  1. Buddel

    Buddel Guest

    Newbie question:

    If I hit Ctrl+Alt+Del, I can kill the NOD32 process. If I can kill it easily, a virus, trojan etc. can kill it easily, too. Or am I wrong? (I hope I am.) How does NOD32 protect itself from being shutdown by a "killer app"?
     
  2. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Hello,

    if you are logged as a user with restricted rights, you won't be able to stop the service. That's why it's not recommended to connect to the Internet and perform pottentially dangerous actions under an administrator account.
     
  3. Buddel

    Buddel Guest

    Administrator accounto_O Well, I use Windows ME (sorry, should've mentioned that before), so I can kill all NOD32 processes at any time. It doesn't matter whether I'm connected to the Internet or not. There's no restriction here.

    Consequently, a virus, a trojan horse or some other malicious stuff can easily kill NOD32, too.:eek: Please tell me that it's not true. :oops:
     
  4. Morgoth

    Morgoth Guest

    Same here - I have Win2000 + SP4 + latest updates and can easily shut down the nod32krn.exe using CTRL+ALT+DEL !?!

    BTW, I'm running on administrator level, but that has nothing to do with the problem since other services such as my anti-Trojan kernel or firewall kernel CANNOT be shut down this way, even as an administrator. Only the nod32krn service can be terminated via the task manager (but it can be restarted using the SERVICES manager).

    There is no explanation to this, for even those who designed the software would not be able to provide any, so I'm not expecting anyone to be able to shed light on this complete mystery. I just wanted to let everyone know that this issue is far from being an isolated case.
     
  5. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I brought this issue up with Eset very recently (it has also been mentioned in these forums before--and recently). They acknowledged the issue, and said that it would be resolved in the next update, which would be available "soon".
     
  6. Buddel

    Buddel Guest

    This is very good news indeed. :D Let's hope this update will soon be available. I mean, there is really no point in using a security app if it can easily be terminated by malware.
     
  7. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,374
    Hi all,

    by design, it is not possible to prevent running services from being killed at all. What will be incorporated in the next PCU is an option enabling NOD32 to restart its service in case some internal problem occurs. Basicly, any application can be killed, the only thing that can be done by programmers is to make this process harder.
     
  8. Buddel

    Buddel Guest

    As far as AV's such as NOD32 are concerned, it should be extremely hard to kill such applications. So I do hope that we will soon be able to say that it's next to impossible for malware to terminate NOD32. ;)
     
  9. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    Hi all,

    I am also quite in favor of adding some such form of protection to NOD.

    In the meantime (or additionally), I think that people who worry about malware being able to just kill running security apps would be interested in DCS's ProcessGuard. There's a forum for this over here at wilders, and actually I suppose many people are already aware of it. What PG does is to install a kernel-level driver that intercepts attempts to kill applications you tell it to protect. (Actually it intercepts the call that the malware has to make to the OS to give it a so-and-so-privileged handle to its victim process.)
    From what I understood of the discussion about PG, KAV and ZAP have some similar protection. This would lead me - a loyal NOD&PG user - to the question if something as complex as this (kernel-level driver) should better be incorporated into NOD (instead of or in addition to re-starting capabilities), or if that should be left to third-party tools as it is now. On my system, nothing can kill/terminate/close/younameit nod32krn.exe :D

    Mods, if you feel this is too much of an advertisement (which i still consider fitting, seeing the topic of this thread), simply remove it. I wasn't sure if I should post it, nor am I sure now... Sorry to have caused you trouble then.
    If not, I'd like to hear everyone's thought about the approach represented by PG and its chances/(dis-)advantages of being incorporated into NOD32...


    Andreas
     
  10. Buddel

    Buddel Guest

    Hi Andreas(W),

    I actually don't want to use yet another app just to make sure that NOD32 cannot be terminated by malware. It is my firm belief that anti-virus programs should not only protect my computer from being infected, they should also kill viruses - not vice-versa, i.e. a virus should not be able to kill/terminate an AV.

    Therefore, I do think it is absolutely essential for ESET to make NOD32 more secure in terms of shutdown protection. NOD32 is a very good AV, but there is still room for improvements. :)
     
  11. Andreas1

    Andreas1 Security Expert

    Joined:
    Jan 29, 2003
    Posts:
    367
    Location:
    Mainz (Ger)
    I'm still not sure if this is the right place to discuss these specific protection strategies - unless Eset explains that they are considering adding some such protection...

    Hi Buddel,

    In theory, I agree fully with what you said. There is simply nothing wrong with it. At all.
    If Eset is going to incorporate a process/service protection as strong as PG's then that's an invaluable asset and can not be argued against.

    Difficulties arise when you take into account that

    a) you have more security programs on your host (at least a firewall, better some Anti-Spyware and probably an Anti-Trojan scanner, possibly even more) which would all benefit from a similar level/approach of protection.

    b) you have an operating system running where Process-to-process security is inherently flawed. This is valid for Win 9x and ME, but even for NT and 2000 (I don't know about XP/2003, but I think they suffer from the same problem). For quite some time, programmers have - like Marcos above - pointed out quite rightly that the fact that on these OSs, any process can call Termination functions on any other process (account privileges being only a minor hindrance to this), is a design-flaw from a security perspective. Similarly, these OSs don't provide a way for an application's window to check the source of a "close", "destroy" or similar windows message. Thus it's hard to decide just whose task it is - and if it can be done - and if it should be done (messing with the OS), to fix those problems.

    c) if you assume that it's a third-party app's task to try to patch the aforementioned leaks, it's going to lead to trouble if you have several of those apps trying to patch one and the same spot - especially since development of PG made it clear that in order to do so, one has to venture deep into undocumented terrain.



    I haven't made up my own mind yet - but even during writing this very posting, I came to I think that actually there are several types of vulnerabilities involved.
    Some of them are shortcomings of the OS (TerminateProcess availability), and some are shortcomings of the respective security app (program exits without user confirmation or password prompt). So, I believe that while the former should rather be handled centrally (by an OS patch or a single third-party app safeguarding the sensitive spots), the latter should be left to the applications themselves.

    Which leads (me) to the following:

    1. Any security application should try to get "standard" protection as availably by the OS. I'm talking privileges, exit confirmations, password protection of exit and configuration, etc. here.
    Especially when one considers the handling of windows messages like "close", "minimize", "there's been a right mouse click in your text box abc1" this is becoming more and more evident: While PG is on the (rather messy) way to provide protection in that area as well - it's working somewhat, but requires a PG dll to be injected into protected processes (protection of the latter kind), complex tweaking of its configuration, often triggers incompatibilities and will (have to) be improved itself based on users feedback - it would be only logical to agree that handling user input is a task for the security app in question itself.


    2. For the dangers that arise from design flaws of the underlying OS, it's most likely not only more effective, but also more stable and secure to have one dedicated app deal with it (supposed that the OS itself won't be fixed in this regard).
    But if, say, an AV scanner takes its job as seriously as you want it to, then it should better do it in a good way: i.e. provide a protection comparable to that a dedicated tool is able to provide (PG being the only one at the moment), be so flexible to let the user switch this protection on and off, handle other whitehats trying to get to the same spot (E.g. AFAIU, NOD has a rather complicated LSP handling and it was discovered to be in conflict with different other tools only after it was released - but soon Eset came up with a way to clean things up once they got messy in there. Something like that would be needed for this protection, I guess - but I don't know if it's possible), etc.
    I know from beta-testing PG and from discussions with the DCS coders just how many research, coding effort, tweaking and testing are needed just to get that thing done properly. I can offer no compelling reason why Eset shouldn't be able to do it as well, and in fact - as you rightly point out - it would be nice of them to offer such a protection for their program even to those who don't run yet another tool, but I could imagine they don't want to invent the wheel a second time.


    I - as someone who happens to have PG - would dream of a proper close message handling done by NOD itself and protecting it against Termination, Dll injection, Code modification, Suspending etc. with PG, making for a combo that provides better protection that, say KAV, Outpost or ZAP. And Eset can focus on virii and malware detection and cleaning. (Did i hear someone say "Bundle deal"? :D)


    Again, I would be more confident of the direction we're taking with this discussion if someone from Eset would explain what kinds of plans there are, if there are any, and at what depths of the System they are reaching, to improve on NODs self-protection.

    Andreas
     
  12. Jason_DiamondCS

    Jason_DiamondCS Former DCS Moderator

    Joined:
    Nov 11, 2002
    Posts:
    1,046
    Location:
    Perth, Western Australia
    The same issue arose when we were designing TDS-4's anti-termination. WormGuard 4 would also have to use it... so do you design it so multiple programs can be protected? Or install multiple drivers from different apps so they all protect themselves individually?

    I don't want to advertise any programs, I am just shedding some insight from a developers point of view, and hopefully a customers. I personally would not like each of my anti-virus/anti-trojan/firewall to install kernel level drivers which all do the same thing, wasting my CPU and resources even further.

    You can hardly tell your customers though they need to buy/use another product to keep your program protected. Security developers are in a bind either way, hard to see an easy solution.

    -Jason-
     
  13. Buddel

    Buddel Guest

    >> Again, I would be more confident of the direction we're taking with this discussion if someone from Eset would explain what kinds of plans there are, if there are any, and at what depths of the System they are reaching, to improve on NODs self-protection.<<

    Good point, Andreas. I would also like to know more about this, so let's hope someone from Eset will soon give us some details.
     
  14. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    IMO, the most important way to protect NOD32--or any other important process--is to run as a member of the Users group (in Win2K or WinXP), and not as a member of the Power Users or Administrators group. But especially don't run with debug privileges! This advice protects you against a whole lot more than just process killing, too.
     
  15. Buddel

    Buddel Guest

    It's absolutely true what you say, but Windows 9x and ME users would also like to be sure that NOD32 cannot be terminated by malware, so I do hope NOD32 will soon be improved as far as shutdown protection is concerned.
     
  16. Buddel

    Buddel Guest

    Does anybody know when this issue will be resolved? Will there be another update "soon"?
     
  17. Buddel

    Buddel Guest

    Hm... I wonder why nobody cares to answer my question. I am sure that Eset is well aware of the fact that NOD32 can be terminated by malware quite easily . I am also sure that Eset will do all they can to do something about it. Is it really not possible for Eset to say whether or not this issue will be addressed in the near future?
     
  18. doug6949

    doug6949 Registered Member

    Joined:
    Nov 28, 2003
    Posts:
    110
    I believe "soon" means as soon as Eset can come up with a solid solution. The solution to problems like this rarely have finite gestation periods. In the mean time you still have a very good AV doing it's job the best it can.

    Doug
     
  19. Buddel

    Buddel Guest

    nameless said:
    ... They acknowledged the issue, and said that it would be resolved in the next update, which would be available "soon".
    Well, the engine was updated a couple of days ago, but this serious problem was definitely not resolved. So what does "next update" mean? Does it mean "next version" (version 3)? o_O
     
  20. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I reported here what I was told; I have no other information whatsoever. Probably the best thing that everyone else can do is to ask Eset directly.
     
  21. Buddel

    Buddel Guest

    I did ask Eset directly - right here at the "Official Eset NOD32 Antivirus Forum", but I just don't get an answer from them. :(
     
  22. nameless

    nameless Registered Member

    Joined:
    Feb 23, 2003
    Posts:
    1,184
    I'd forget the forum and go right to the source.
     
  23. Buddel

    Buddel Guest

    I think you're right, but isn't this the official NOD32 Forum? I actually thought that I would get an official reply in an official forum. :( :( :(
     
  24. Paul Wilders

    Paul Wilders Administrator

    Joined:
    Jul 1, 2001
    Posts:
    12,472
    Location:
    The Netherlands
    Buddel,

    Indeed this is the official NOD32 forum. As far as I know, there is no official answer to your question at this very moment, at least no official ETA. As everyone has noticed, Eset is and has been very busy in ironing out some V2 issues, resulting in the latest engine update, addressing the most urgent issues. Rebuilding an engine comes with an unbelievable amount of work. IMO top priorities have been targetted in the latest engine update. In case their are issues left to be addressed, they will be.

    In the meanwhile: Eset can't address all issues at hand at once - and that's perfectly understandable. No software developer can. In this context, providing the software developper time seems the logical way to go.

    regards,

    paul
     
  25. Buddel

    Buddel Guest

    I'm well aware of the fact that this grave problem cannot be resolved overnight. However, it would be nice if ESET told their paying customers what they have done so far to tackle this problem. Am I expecting too much from them?
     
Thread Status:
Not open for further replies.