Resolved: I remain a NOD32 fan, particularly after the amazing response from Shaun Norris and his team. They have fixed the problem locally, and making sure the ESET engineers improve their download process in future releases.
Original Post 10/14/11: I have been a NOD32 fan for a long time, but recently I have been questioning my loyalty, particularly in the light of their very dodgy virus definition update policies. It seems they are perfectly happy to allow a PC to run with definition files that are 448 days old. Or 105 days. Or whatever. What kind of security is that!?
Take a look at the screen shot at the top of the page (click on the image) to see how the software is lying to me. I installed the software two weeks ago on this Windows 7 32 bit PC, and at the time the virus definitions were updated backwards from version 6364 (20110809) to 5307 (20100723) and then later to 6516 (20111004). OK, so it had a glitch. It came right. Wrong!This morning I returned to the machine, after leaving it running by itself for 10 days. The virus definitions are back to 5307. No amount of cajoling can persuade the machine to download the correct version and not mislead me:
Other versions of the software have experienced similar problems. This PC was using version 4.2.71.2 and it had an issue with the definitions, so I removed the software and installed version 50.93,0. The same thing happened on a brand new Windows 7 machine I was setting up from scratch. Other PCs running Windows 98 and version 2.7 are reverting back to July 2011.
So my question is this: how can the software allow the definitions to roll backwards? How can the servers still have definition files that are 448 days old? Are they insane? They are supposed to be a security company. Yet they issue software with bugs in it, and have a policy that doesn't remove old virus definitions, giving careless users a false sense of security. That's worse than no security at all.
ESET CEO Richard Marko is still blissfully unaware of this problem
Update Tues 18th Oct: ESET requested the configuration file and SysInspector log that I sent on Friday 14th. I am starting to get annoyed as well as alarmed. In the meantime the definition files are now over 450 days old! And they want me to run WireShark to capture all the packets. WTF?!
Update Wed 19 Oct: Posted an update to the Wilders Security Forum.
Update Thu 20 Oct: Definitions are now 454 days old, i.e. 64 weeks. After making enquiries this morning I discover the ESET engineers are waiting for a log that I have already sent them. I sent the following reply:
Yes, I am on M-Web but the problem also occurs when using ISDSL which is what most of the [customer] connections use.
Yes, I sent you the event log. TWICE. Here it is: [I have removed duplicates]
14/10/2011 03:24:54 PM ESET Kernel The program modules have been updated.
14/10/2011 03:24:52 PM Update module Updater: retval = 0x0000, failures: 0 NT AUTHORITY\SYSTEM
14/10/2011 02:59:19 PM Update module Updater: Switch DEVEL modules retval = 0x00005007 [NOT NEED] NT AUTHORITY\SYSTEM
14/10/2011 01:43:30 PM ESET Kernel The program modules have been updated.
14/10/2011 01:43:28 PM Update module Updater: retval = 0x0000, failures: 0 NT AUTHORITY\SYSTEM
14/10/2011 01:43:23 PM Update module Updater: Switch DEVEL modules retval = 0x00005007 [NOT NEED] NT AUTHORITY\SYSTEM
14/10/2011 01:42:56 PM ESET Kernel The program modules have been updated.
14/10/2011 10:56:12 AM ESET Kernel The program modules have been updated.
11/10/2011 06:53:02 PM Update module An error occurred while downloading update files. NT AUTHORITY\SYSTEM
11/10/2011 04:53:00 PM Update module An error occurred while downloading update files. NT AUTHORITY\SYSTEM
05/10/2011 08:51:06 PM Update module An error occurred while downloading update files. NT AUTHORITY\SYSTEM
05/10/2011 03:46:12 PM ESET Kernel Virus signature database successfully updated to version 6519 (20111005).
05/10/2011 11:46:10 AM ESET Kernel Virus signature database successfully updated to version 6518 (20111005).
04/10/2011 09:46:01 PM ESET Kernel Virus signature database successfully updated to version 6517 (20111004).
04/10/2011 06:06:00 PM ESET Kernel Virus signature database successfully updated to version 6516 (20111004).
04/10/2011 06:05:57 PM Update module Updater: retval = 0x0000, failures: 1 NT AUTHORITY\SYSTEM
04/10/2011 04:46:44 PM ESET Kernel The program modules have been updated.
04/10/2011 12:49:52 PM ESET Kernel The program modules have been updated.
This is clearly an ESET issue because it is ESET software doing the download, and ESET software that is lying to me about the result, and ESET software that is allowing is virus definition files to go backwards.
I understand that transparent proxies may be involved, but then please explain why two adjacent computers on the same connection can have different results? One works fine and the other doesn’t update.
I really think that ESET is not taking this matter seriously. If your engineers have any further requests or questions, please ask them to contact me directly.
Update 2: Thu 20 Oct 2011: I got a call from Shaun Norris at ESET South Africa, who assured me that they are not ignoring the problem, and have requested further info from me. This is most reassuring. In the meantime I think I have figured out how things are going wrong: their update mechanism is broken. It is vulnerable to faulty proxy servers (such as those used by M-Web) and doesn't use https. It also has no check to see if the version it is updating is older than the existing version. WTF!?
Update: Fri 21 Oct 2011: Shaun Norris set up an alternate proxy for me to try, and also contacted M-Web to get them not to cache the ESET virus definitions. Last night I tried a new installation, which worked flawlessly. I'm waiting to be able to connect to the "afflicted" PC (the office opens on Monday) to see whether these changes will help.
Update: Monday 24 Oct 2011: The virus definitions have updated to the correct version, and appear to be stable. I have sent the logs through to Shaun Norris. All is well for now, and hopefully the ESET Engineers will fix this bug before it endangers other customers.Update: Tuesday 5 June 2012: Version 5.2.9.1 was just released. It addresses some of these issues, according to the release notes.
8 comments:
That's a bizarre situation. I have four copies of NOD32 running, versions 2.7, 4.2, and 5.0, and haven't seen this odd behavior. You might try a full uninstall, which requires manual deletion of certain folders after running the uninstall program. See here: http://kb.eset.com/esetkb/index?page=content&id=soln2116#uninstall
It would be interesting to see if after doing a complete manual uninstall, and then reinstalling, if the problem reappears. The fact that the problem crosses versions is disturbing.
It doesn't happen on every machine, but in one case (on the same machine) it happened on version 4.2 and 5, in spite of FULL uninstalls attempted several times.
On another machine I just gave up and reverted to Microsoft Security Essentials because I ran out of time.
What worries me the most is that the software is prepared to go *backwards* to older definitions. This is very sloppy programming, IMHO. It is also sloppy server maintenance, because definition files that old should no longer be kept on the servers.
I'm SO glad I found this Blog Post. I'm having the EXACT same issue. Keeps rolling back to 5307. Tried uninstalling a thousand times, clearing the cache as well as going back to v4 - v4 rolls back now as well!
Please let me know if you ever find a solution. I'm stumped.
Personally, I'd like to see more insight and less rant. I understand how it must be frustrating for you, but I think there are probably better ways to deal with the issue other than to question the fundamental philosophies of this company.
Clearly you (and perhaps a few others) are experiencing an issue which is extremely rare (btw I use the software and have never experienced such issues). As rare issues such as these do occur in other types of software, I'd urge you to take a more objective stance on this issue. I see what point you're trying to make: "Software which is meant to protect your computer should not compromise your computer 100% of the time", but ultimately all cases are impossible to account for. The information you have provided here just seems to point to such a case, and does not point to some 'hidden agenda' of sorts which questions the abilities of a company which is clearly trusted by millions of clients for the right reasons.
If I had to suggest an improvement for the software which catches this particular exception, I'd add a procedure which cross checks the date of the update file visible on the proxy server with an absolute date provided by an Eset server elsewhere, although this probably won't help with the software seemingly being offered one choice of available update files. I've had negative experience with some caches before, and if this is such a case, then it is unfortunately a little out of the 'quick-fix' scope. In the meantime, it's obviously important to keep the software working. Perhaps try do an update using a 3G connection? In my opinion, there are just too many variables to make a solid conclusion, so might as well start with eliminating as many as possible.
As far as the 'old' files kept on the server, I believe this is the practice of delta updates, so they will always be there to ensure that a fresh install of a client can always download the entire virus database independent of the database it currently has. It's just a 'cloud-over-client' mentality, creating a more robust system (minus your particular case), which also reduces the update times onwards from the most recent update. It could also be said that in 99% of cases, a file offered by the cloud is guaranteed to be the same or later version than on the client, and hence the logic of the state machine tells it to replace whatever version it currently has. You are correct in assuming that it SHOULD check if the situation is the other way around, but I'm assuming that such a case simply wasn't accounted for; and I don't believe that this small case should compromise the social integrity of the company.
BTW, you have a win98 machine still in use?? :O
Regards,
Niems
I am a programmer, and I work for a company that has a 100-user NOD32 license. At least 70% of the computers on their WAN still use Windows 98, because they are too slow to run XP at anything other than a crawl. By the end of the year they will be forced to replace them with faster machines, and will be using Win7.
What has alarmed me (hence the ranting) is that the problems with the updates have occurred on new installations mostly. If we are going to be doing 50 new installations before the end of the year, are we going to have this crap in all of them?
What has also alarmed me is the really casual way the problem has been addressed, UNTIL I started tweeting and leaving messages on Facebook fan pages this week. Is it really necessary to do this just to get a bug addressed?
It is a bug, however "rare". NOD32 and ESS versions 4 and 5 are all vulnerable to bad proxies. I'm just one of the unlucky suckers who struggled with this problem on multiple machines at multiple locations.
A bug, by definition, is something the programmers don't expect. I *pay* my clients R100 cash every time they find one, so I can fix them. I don't expect ESET to pay me, but at the same time I don't expect to be ignored either.
They have stopped ignoring me but I doubt very much whether they will be improving their update mechanism anytime soon. I just get that feeling, based on the feedback I have received. I guess it's their choice to make vulnerable software.
Hello, I'm experiencing the exact same problem and i need to fix it soon on my PC (and probably others)
Please tell me how to correct this problem step by step 'cause im not an expert, post the solution or send me an email to
jhcp2011 gmail com
it'd be highly appreciated
The problem lies with a bad proxy server at your ISP. Please contact ESET support in your country for a fix. You can refer them to this page if necessary.
Version 5.2.9.1 claims to fix some of the issues mentioned here.
Post a Comment