Shutdown protection?

[Buddel]

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"?

[Marcos]

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.

[Buddel]

Administrator account??? 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.:o Please tell me that it's not true. :-[

[Morgoth]

-{ Quote: "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." }-

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.

[nameless]

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

[Buddel]

-{ Quote: " quoting: nameless link=board=39;threadid=17122;start=0#msg106349 date=1070437213]
...They acknowledged the issue, and said that it would be resolved in the next update, which would be available "soon".
" }-
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.

[Marcos]

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.

[Buddel]

-{ Quote: " quoting: Marcos link=board=39;threadid=17122;start=0#msg106378 date=1070448085]
... Basicly, any application can be killed, the only thing that can be done by programmers is to make this process harder.
" }-
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. ;)

[Andreas1]

Hi all,

-{ Quote: " quoting: Marcos link=board=39;threadid=17122;start=0#msg106378 date=1070448085]
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.
" }-

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

[Buddel]

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. :)

[Andreas1]

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,

-{ Quote: " 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." }-

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

[Jason_DiamondCS]

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-

[Buddel]

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

[nameless]

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.

[Buddel]

-{ Quote: " quoting: nameless link=board=39;threadid=17122;start=0#msg106481 date=1070474521]
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.
" }-
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.

[Buddel]

-{ Quote: " quoting: nameless link=board=39;threadid=17122;start=0#msg106349 date=1070437213]
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".
" }-
Does anybody know when this issue will be resolved? Will there be another update "soon"?

[Buddel]

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?

[doug6949]

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

[Buddel]

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)? ???

[nameless]

-{ Quote: " quoting: Buddel link=board=39;threadid=17122;start=15#msg108922 date=1071039239]
-{ Quote: " quoting: nameless link=board=39;threadid=17122;start=0#msg106349 date=1070437213]
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".
" }-
Does anybody know when this issue will be resolved? Will there be another update "soon"?
" }-
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.

[Buddel]

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

[nameless]

I'd forget the forum and go right to the source (http://www.nod32.com/support/support.htm).

[Buddel]

-{ Quote: " quoting: nameless link=board=39;threadid=17122;start=15#msg109497 date=1071196473]
I'd forget the forum and go right to the source (http://www.nod32.com/support/support.htm).
" }-
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. :( :( :(

[Paul Wilders]

Buddel,

-{ Quote: "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." }-

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

[Buddel]

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?

[Paul Wilders]

-{ Quote: " quoting: Buddel link=board=39;threadid=17122;start=15#msg109584 date=1071218827]
I'm well aware of the fact that this grave problem cannot be resolved overnight." }-

We agree on that one ;)

-{ Quote: "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?
" }-

Buddel, are you actually asking for technical specifics from Eset's Lab? No company will ever reveal such an info - this isn't Open Source software ;). IMHO you are expecting too much from every software developper when asking such info.

regards.

paul

[Buddel]

-{ Quote: " quoting: Paul Wilders link=board=39;threadid=17122;start=15#msg109587 date=1071219991]
...
Buddel, are you actually asking for technical specifics from Eset's Lab? ..." }-
No, I would just like to find out whether ESET is currently working on a solution or not, and if they are working on one, it would be very kind of them to tell their customers when this problem will probably be fixed. I would be completely satisfied if they told me and other customers that this problem will probably be a thing of the past, say, within the next six months or so. That's all I want. I don't expect them to give me an exact date, because this is not possilbe.

BTW...snipped - please one topic in one thread; thanks

[iNsuRRecTioN]

Buddel, I think, the answer is, that eset doesn't have fully coded and implement all the features in NOD32V2 that on their description site, yet.
Maybe there are develop currently the sfx feature for better support and their will be an update, maybe in 6 month :D

There...snipped - please one topic in one thread; thanks

bye

iNsuRRecTioN

[NewNOD]

-{ Quote: "Buddel, I think, the answer is, that eset doesn't have fully coded and implement all the features in NOD32V2 that on their description site, yet.
" }-

Yea. I've noticed that myself over the months since NOD32 v2 was released.

It's kinda like buying a car that's supposed to have power windows, then you notice that the front window switches are there but the rear window switches aren't. Then you notice that the right front window switch is connected to the windshield wipers and the left front switch is not connected at all.

But be assured, it has a motor and that's what counts; or so they'll tell you.

I guess I shoudn't complain too much, I finally get to use NOD32 v2 after six months of waiting for a fix to the Kernel32 errors. Luckily, this update did something to patch that up.

So, I guess I'll drive NOD32 with the power windows screwed up for a while.

[Buddel]

Buddel, I think, the answer is, that eset doesn't have fully coded and implement all the features in NOD32V2 that on their description site, yet.
Maybe there are develop currently the sfx feature for better support and their will be an update, maybe in 6 month.
I think you are right. However, I doubt that all the features will be implemented within the next six months.

[doug6949]

The shutdown problem is not a simple affair. NAV can be disabled by infections in spite of efforts to prevent this (and claims to the contrary). There is little point in adding a feature that doesn't work, except from a marketing standpoint. Why not just wait until eset gets it right? Doug

[Buddel]

Why not just wait until eset gets it right?

It's a good idea, but how do I know that eset is willing to get it right? Are they working on a solution to this problem? They won't tell me, I think.

[Eliot]

Wow, protected by NOD32 and bashing it. ::)

[Paul Wilders]

Ladies and gents,

There's no use in repeating one and the same question over and over again, as is the case in this thread.

Be assured Eset is aware of this issue. Until Eset has news on this topic, I'm closing this thread. Eset reps can re-open this thread or start a new one on the subject as soon as there's news to report.

regards.

paul