Goodbye ESET!

Discussion in 'ESET NOD32 Antivirus' started by solcroft, Apr 9, 2008.

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

    bdmc Registered Member

    Joined:
    May 11, 2006
    Posts:
    55
    Is there a way to remove context menu integration in the config file?

    I can't see it anywhere...
     
  2. Hangetsu

    Hangetsu Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    259
    Thanks, I'll try that next time - Wasn't a big deal to me either way, since I don't tweak settings that much.
     
  3. ASpace

    ASpace Guest

    You are welcome
     
  4. proactivelover

    proactivelover Registered Member

    Joined:
    Apr 7, 2006
    Posts:
    840
    Location:
    Near Wilders Forums
    see this
     

    Attached Files:

    • gg.jpg
      gg.jpg
      File size:
      34.9 KB
      Views:
      635
  5. kC_

    kC_ Registered Member

    Joined:
    Apr 6, 2007
    Posts:
    518
    what a strange place to put context menu options...in the option called "context menu":argh:
     
  6. bdmc

    bdmc Registered Member

    Joined:
    May 11, 2006
    Posts:
    55
    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.
     
  7. Cosmo 203

    Cosmo 203 Registered Member

    Joined:
    Mar 3, 2008
    Posts:
    165
    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.
     
  8. mkuntic

    mkuntic Registered Member

    Joined:
    Mar 6, 2008
    Posts:
    54
    For the love of God, get this fixed. Now, please! (version .653)
     
  9. Marcos

    Marcos Eset Staff Account

    Joined:
    Nov 22, 2002
    Posts:
    14,441

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

    mkuntic Registered Member

    Joined:
    Mar 6, 2008
    Posts:
    54
    Has the file-move-without-ACL-restrictions issue been fixed in .650?
     
  11. Cosmo 203

    Cosmo 203 Registered Member

    Joined:
    Mar 3, 2008
    Posts:
    165
    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.
     
  12. mkuntic

    mkuntic Registered Member

    Joined:
    Mar 6, 2008
    Posts:
    54
    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.
     
  13. edwin3333

    edwin3333 Registered Member

    Joined:
    Aug 29, 2007
    Posts:
    244
    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.
     
  14. mkuntic

    mkuntic Registered Member

    Joined:
    Mar 6, 2008
    Posts:
    54
    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".
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.