Goodbye ESET!

Well, looks like my three months with ESET is up. Leaving NOD32 for AVG 8.0, but there's just one suggestion I want to make before I do.

Please allow users with limited accounts to disable the on-access module.

It was extremely annoying that I had to login to my admin account and turn off NOD32 every time I wanted to play Warcraft - for some mysterious reason NOD32 was the cause of 150+ms ping ingame even when I configured the HTTP scanner to ignore the Warcraft executable. Other than that, I think my other gripes are well-known enough.

It's been fun. Hope I'll be back sometime. Adios.

 

PS: You could use a simple Run-As script to elevate your rights to disable NOD32.

 

Or just Warcraft to the exceptions.

 

limited accounts and disable rights seems to me very....... contradictory ! If you are the pc administrator just have a look to suggestions here.

 

I run a limited account on my machine, playing a similar game -- As described above, best bet is to just place the application in the Excluded list, and put any URLs used by the game into excluded addresses.

I agree though, its annoying to have to go into the admin account to change some settings... But given you shouldn't have to change application settings all that often, once its set it SHOULD be a non-issue, right?

 

limited accounts should not be allow to change the settings,or it will cause many bother.


The bset solution is to use Exclude.

 

It is not, the opposite is correct. The reason:
If I am the admin of the pc, but log in in a limited account (that's what I do regularly), than I am still the one, who decides, what can be done with the machine. What is the reason, that I am forced to switch to the admin account or restart egui.exe with elevated rights to make some settings, e.g. define a new on demand scan profile, define a new task in the planner, or even to disable the guards, if I see the necessity for that? In fact, there is no reason for such a detour.

On the other hand, if it is necessary to prevent other limited users on the machine to alter settings (except some GUI issues), there is a simple way already built in: password-protection. In fact, actually the password protection in NOD32 is at now superfluous, because as long only the admin is able to change settings, what is the need for that? There is no!

 

Solcroft, judging by

https://www.wilderssecurity.com/showthread.php?t=199660&page=24

We may see you sooner than later

 

Granted, it's got its own quirks, but it's working generally fine so far.

Besides, OneCare is next on my to-try list when I'm bored with AVG anyway. For now, though, I'm experiencing the refreshing change of my vendor's virus lab providing a decent turnaround time for the samples I chuck at them.

 

Actually, what's weird about it is some settings can be changed by a non-admin, while other settings will throw an error if you try and change them. Its a mix.

While its annoying, I agree that it makes sense that only an admin can change the settings - I'm not looking for that to be changed personally.

 

Then what's the point of "Password Protect Settings"?

If I walk to a users desk, and quickly want to eliminate NOD32 as the cause of a problem. I cannot disable the real-time scanner...

Stupid design.

 

Let me guess: You are regularly using an admin account, do you?

Eset tells themselves in the help file, that a limited account should be used for daily use. But to make this workable, the software has to support this usage - not only in the meaning of technical working in a system with different rights, but also in the meaning of let the user gaining success with that. A limited user is not allowed in nod to add a task in the planner to regularly and automated scan some folder, e. g. in his profile. Where is the meaning of this restriction, what can be bad about doing so? The limited user may not add or activate a program in the browser or e-mail-client list, that nod missed to add or activate there. Security by this limitation? No, except in the meaning of less security. And there is more. Yes, you can stop the egui-process from a limited account and start it with the credentials of an admin account (runas); that is a workaround for users, who are admins on their machine but do work in a limited account regularly. But there is no way, to stop the egui-processs, which has been started via runas and to revert back to the not-elevated egui.exe (which by default is not not elevated by esets decision!).

As already said, with the nod-password option it is not a problem to prevent users to alter settings, that should not get altered by them, so there is no logic. But this kind of "security" is absolutely ridiculous, if you see, that there is no limitation, that a user can destroy the whole system with a simple action of the nod-shell-context menu - as said: he can this with limited access. I have informed the official regional distributor about this really critical bug some time ago, but nothing has changed until now. For those, who want to know exactly: If you choose "copy to quarantine" in the context-menu, this object(s) do get moved, not copied, and this can get done with any(!) file, also in C:\Windows from a limited user account. Be warned: do not try this wit a critical file! So far about the security by limiting the user's rights in nod.

 

There is a way.

What you describe is OS limitation , complain to Microsoft . With Vista things are much easier . You can choose to permanenly run egui.exe as admin and stop it any time if you elevate privilages to Task Manager.

By the way , you can elevate privilages to Task Manager to stop egui.exe as Admin (in XP , too) . But you haven't thought of this .

Actually with the latest version it is called "Quarantine file" - it seems it is a design.

 

I prefer to leave the culprit where it is. The limitation is in nod (the part you did not quote). And than come the workarounds. Workarounds are no features and the limitation is the fact, that there is a workaround necessary for doing a job on a secure (= limited) base.

The latest version is that, that the official distributor can deliver, and that that is here b642. And another fact: Saying copy instead of move (translated to English) is a mistake, that should never have it made into a final release.

But you did not get the main point (at least, this is what I read): A limited user - btw unable to add a on-demand scan because eset seems to rate this as insecure () - is able to remove crucial system files!!! That is monstrous. Let's hope, that there will not be a security hole, until this is solved. EDIT: Before it can get exploited.

 

Actually, I run as a Standard User on Vista. I logged on the admin account to complete configuration as well as schedule weekly scans, etc. All day-to-day work (manual scans, file submission, etc.) work fine as a Standard User. You may have a reason to need to manually adjust schedules or settings regularly, I just can't think of one right now. Also, wouldn't the resolution simply be to log on as an administrator account briefly?

Your issue with copy to quarantine I agree with though - Although to fix it, I'd assume that would have to make the NOD32 drivers run at a lower authorization level than it would need to.

 

How does NOD32 determine what is critical and what is not? It needs to be able to manage system files (in case of an infection). Maybe NOD32 could require the password if a user elects to quarantine a file from any of the system directories...

 

Doing so would of course let me do, what I want to. But if eset thinks, that hindering limited users in doing things, where a security problem is not imaginable (I gave some examples above), what a security risk is to logon with admin rights, although the tasks can perfectly be done without risks without those privileges?

You want an example, here you are. Besides the bug I already mentioned I found (and have reported to the officials also) some more. E.g. I have an task in task-planner to scan a folder once a week. For the case, this task could not be performed (machine down) I have set, that this task shall be performed, if the last performance is 209 hours (or more) ago. Doing some maths one will find, that this is some more than 8 days. If have set this value to make 90% sure, that this scan will not performed during a boot-up of the machine (even with a light-weight AV-scanner as NOD this is not very funny), but at any time later. Having this set I finally found out, that nod does not observes the 209 hours, nod performs the task at the next possible chance. It's a not-critical bug, nothing serious. But for finding a matching solution what can I do anything than play with the settings, wait until the next occurrence and see, if this works better? And every time break the task I am doing at the machine to switch for those simple settings into the admin-account? This breaks will take even on a fast machine 1 or 2 minutes, and that is not good for the job I am working about. Simply open the gui and change the settings does costs only seconds. Nod is fast in performing, but loosing the time for switching between the accounts can not be the payment for that.

I assume the driver has to run on this level, but nod does seem to not observe the rights of the user, who has used the command via the shell-menu. Another question is, if it would not be imperatively necessary to warn the user (even with admin rights), if files from Windows get quarantined by this way. (Little chance, that nod gives this warning, if a really crucial file gets moved, but I am not ready to test this. At least I (and eset) know, that this warning does not come generally in Windows-folder and subfolders.)

 

Well, I asked for a reason and you gave it to me, thanks!

 

The point here is, that this occurs by action of a user. It is not a question, if the file is infected at all, because the (following the new wording given by HiTech_boy) quarantining can be done with any file. And the motif of the user, who "quarantines" a file out of a folder of the OS can be very ... mh different. A limited user has by design no write (and move, delete, alter) access to files in C:\Windows and program files and giving him this access via the shell context menu is a critical bug.

The other point you mentioned (a critical file got infected and nod detects this during a scan) is an interesting one, but quite another story. In the 15 years of Internet (for me) a luckily had never such a problem and I expect, that using a trustworthy AV-program (in this aspect nod does for me belong to them) and consequent usage of the limited account (that, what I am struggling for and what shall never get hindered, even not by an AV-app) will leave me without such "experience". Otherwise I come to find out, if Aaron Margosis is right in saying you are better off running as non-admin WITHOUT anti-virus than you are running as admin WITH anti-virus

 

There is the scenario in where the machine was infected prior to installation of NOD32 - If they were to essentially add system file directories to the exclude list by default (as the software would not be allowed to modify those files), then the opposite spectrum of problems would occur: Namely, people saying that NOD32 "didn't fix my PC".

Having said that, I understand your point (and agree on the non-admin account point of view).

 

This does need to be fixed..

No user should be able to arbitrarily quarantine ANY file. ESPECIALLY in a password protected Business environment.

The STUPIDEST part is that you need to enter the password to RESTORE THE FILE! So when the user accidentally quarantines something (which they shouldn't be able to do in the first place), they have to call you to get it back, and since there's only ONE password for everything, you have to visit them, or give them the keys to EVERYTHING?!?!

THAT'S RIDICULOUS!

I'll repeat, NO USER SHOULD BE ABLE TO ARBITRARILY QUARANTINE ANY FILE. There's no point, if you think a file is infected, but it's not being detected then DELETE IT, or perhaps move it to a secure, excluded directory, or a USB key.

From my testing (under Vista, with UAC turned on) NOD will quarantine system files, but can't delete them.

I tried several things, but couldn't get it to kill anything that would screw Windows. It just comes back and says it couldn't delete them.

So from what I can tell, a user can't take out Windows using Quarantine, but if they can add to the quarantine they should be able to restore the same files if need be, with the same access. But really, if given the option, I'd password protect the ADDITION.

Here's something fun. Go to your Windows folder, highlight all the files (deselect any folders), right click and attempt to quarantine all those files. It will add them all (even if it doesn't delete any of them), fun fun, especially when there's a couple 500+MB .DMP files. The complete lack of centralized quarantine control makes this situation even more annoying.

 

Very good addition. In one word: the limited user has the right to kill a system, but not to correct his mistake (in case, it is an mistake).

In general you are right (especially regarding to system files), but don't forget, that nod has different quarantines for the different accounts. Thinking about the files in the profile folders of the user (especially My Files), the user is the owner of the files, in technical terms, but also regarding the privacy. And because of privacy the separate quarantines is a pro for nod. There might be reasons, why even an admin shall not be able to see them. If a user decides to quarantine a file (e.g. for waiting for a response by eset), that is an own one, that is ok. - During my tests about the "quarantining" of system files I found, that this file does not get stored in the quarantine of the user, who did so, but I found it in the quarantine of the admin account. So the user has indeed no chance to correct it, if he wants. And even worse: The user does not even have a chance to see, what happens. If (s)he is not a rather experienced pc-user (s)he will never get the idea, what has happened to the file, where (s)he tried out a command, where it says "copy". [IRONIC MODE]Perhaps this is a way to get admins without a job to work, because they are needed to check the admin's quaratine, if somebody accidently has "quarantined" anything.[/IRONIC MODE] And lastly: Even if a bad user has done so out of evil reasons, you will never be able to prove that, because he can always argue "I used a copy command and have never heard, that copying (without overriding another one) will harm a system".

 

Well...... hope Eset have some eyes here.... little bug to fix

 

Who is gonna exploit it? Only a user who knows about it and intentionally does it . The solution is easy - either remove the option from the context menu in the next build or to make it not to appear for power users . Relax.

 

It wasn't necessary . Open Task Manager , stop the egui.exe process .
Then from the Start menu , find ESET NOD32 Antivirus (it will be the UI part) , right click it and run it as Administrator .
If the UI is run as Administrator in limited user account , then you can perform the changes without running the whole Admin account.