Goodbye ESET!

Is there a way to remove context menu integration in the config file?

I can't see it anywhere...

 

Thanks, I'll try that next time - Wasn't a big deal to me either way, since I don't tweak settings that much.

 

You are welcome

 

see this

 

what a strange place to put context menu options...in the option called "context menu"

 

Obviously I could see it in the GUI - I asked if it exists in the xml config file.

I would like to push it out to all the other users.

 

This objection has become outdated by Eset.

In the meantime the German build 650 is availible, and all bad is as bad as it was before.

Still ESET "elevates" any limited user to the facility, to destroy the complete system with a few simple mouseclicks.

Still ESET supports an attacker, who is able to get in contact with the system (e.g. a bad-minded employee) to do so and to tell, that this was not his intention, as still the context-menü is labeld with "Datei in Quarantäne kopieren" (I think also non-German speaking can recognize the Word "kopieren".) The attacker can say, that he did a copy-command and expected, that a copy-command does not anything to the source (except changing the Archive-attribute with certain programms). So ESET not only punctures the security of the system, they also protect the attacker against convicting him.

So I see at now a few possible conclusions, that I can draw:

Either, this is the official Eset Support forum, than ESEt knows about those critical bugs and decided to not solve them with the next possible release. This is unacceptable! (Not to forget, that ESET had been informed weeks before I posted this problem via the official distributor. And before anybody asks: The distributor answered me, that he had received my report and that he forwards it at once to ESET. This is 5 weeks ago. I would have been more than happy, if ESET would not have obliged me to report this publicly.)

Or this is not the official ESET Support forum and the ESET don't mind, what gets informed and discussed here. Nevertheless, this does not change anything about the fatal bug as described.

Third option: ESET does not consider such a bug as a critical one and does not see the need to solve it as soon as possible. In this case there would obviously exist as distinct opinions about critical risks as can be, so it would be unlikely, that a discussion about that would be possible at all. (People, who use the word "copy" with the meaning of "move" do apparently speak a language, I will never be able to learn.)

At least, as a customer who has paid for a product to enhance security, I am more than disappointed, as a service agent I do not see the possibility to recommend NOD as long as this bug exist.

 

For the love of God, get this fixed. Now, please! (version .653)

 

The wording of the option "Datei in Quarantäne kopieren" has been changed to "Datei in Quarantäne verschieben".

 

Has the file-move-without-ACL-restrictions issue been fixed in .650?

 

I guess you want to say "will be changed" in the next version. The German build 650 is dated from 18/04, so this is the actual release - with the old and false wording. (In fact, I do not understand, why Eset was not able to correct a string in between of 5 weeks.)

But more important: As a customer, who expects enhancing of security by a security software and not the opposite I expect, that the main security hole gets also closed in the next release. To avoid misunderstandings: I mean the point, that a limited user must not get the right to move a file, where he has no write access by the OS (E.g. in folder-trees Windows or program files or all root of drives); the actual fatal bug, that he is able to remove the files via Eset context menu (regardless of the wording), must get removed - better yesterday than today. Eset has missed the chance to do so with build 650; this must not happen again! There are no excuses any more allowable.

 

This security breach has NOT been fixed in 3.0.657. I'm utterly disappointed and at total disbelief as to how it's possible this major issue is simply being ignored.

 

We have other software which has this type of issue. A user can launch a GUI that interfaces with a service, which they can elevate their rights through and do things they shouldn't be able to.

While not the best solution in the world, what we have done is modified the permissions on the .exe so that only admins & system have rights to it.

You could do this with %ProgramFiles%\ESET\ESET NOD32 Antivirus\egui.exe and then remove it from HKLM runonce so that the gui does not launch. We do this using an Active Directory GPO.

One thing we also found a bit odd was the fact that when the non admin user tries to disable Nod32 features & they know the password, it will not let them. I suppose this is because Nod32 stores these settings in HKLM/software/eset* and the normal user has read only rights. I VNCed into a PC and tried to disable Nod 3.0 but could not without running the program as alternate user.

 

The GUI itself is not elevated and thus doesn't present a problem - by itself. The problem is in the service, and should be fixed there.

Theoretically, anyone could write an alternate utility to interface with the NOD service and do the same thing. What you suggest is "security by obscurity".