NOD32 strikes again......

Again, I have been blocked by NOD32 from downloading a perfectly benign file. Up flies the vomit red threat screen, and Eset essentially tells me what I can and cannot download.

Does Eset really think that it knows every files intent or purpose? Common sense should tell you that false positives will occur. Just look at what I mean in the little video I posted at http://www.mediafire.com/?fjgibwmnmbm .

Why isn't there a "Exempt This File" button on the threat screen? The button should exempt that file no matter where it is found on my PC or network when clicked. I want to exempt the file from a false positive. (Not an instance of the file in a specific directory....the file, in any directory.)

Business (and even personal lives) shoudl not be put on hold until Eset determines if a file should be downloaded or allowed on an end user's PC.

NO SOFTWARE should take control of my PC away from me - even if that means that I screw it up. It's my PC.

This smells like no end user testing is going on at Eset. Surely I am not the first to point out this missing option on the threat screens.

 

Is it a problem to simply report the file as a false positive? We will check it out and remove detection if a FP is confirmed. I don't see a reason for creating a video with biased commentary bashing NOD32.

By the way, the code utilizes viral obfuscation which has not been seen anywhere but in malware, hence it was detected. We'll remove detection for this particular file and other such highly suspicious scripts will be detected as unwanted applications in the future.

 

When you need to use the files (this isn't the only false positive I've gotten using NOD32) it most certainly IS a problem.

I need to work when I need to work...not when Eset thinks I need to work.

Trust me....I was being polite. If I wanted to bash NOD32, it woouldn't be done in a moderated forum with a limited audience.

But, let's move on, shall we?

Why not give users the complete control of their PCs that they are entitled to (being the owners of the PC and all)?

And, so that you don't have to strain yourself, it should work something like this....

NOD32 pops up a threat screen. The end user trusts the source and the file and does not wish to wait for Eset to allow him/her to use his/her PC as he/she sees fit (which is probably how ALL end users feel).

Wisely Eset has included an "Exempt this File" button right on the threat screen which, when clicked by the end user, exempts the file anywhere on the user's PC (this takes care of catching it in the temporary internet cache folders and wherever the user saves or runs the file without having to exempt the internet cache folders and expose the end user to more risk than the file they are choosing to exempt).

The great and wise Eset doesn't stop there....clicking the "Exempt this File" button also pops up a message warning the user that the file may be hazardous to their data before it exempts the file and it automatically submits the file to Eset for further analysis.

And, to protect itself, Eset also should gather the NOD32 username and password, and computer info like hard drive serial number, CPU serial number, etc. to identify the account/computer just in case the end user exempts a file, screws up his/her PC and wants to blame Eset.

It seems pretty simple to me. All of the required functionality exists in NOD32 to handle this scenario much better than it is handled now AND to hand the power of the user's PC back to them - which is where it should have stayed in the first place.

 

I didn't download the video, thanks to my very limited bandwidth at the moment.

But your statement is absurd at best, and reeks of deliberate, uneducated bashing at worst. I'm sorry that I have to educate you about this fact, but when you purchase and install an antivirus program, that's essentially EXACTLY what you're trusting it to do.

It's like hiring a bouncer, and screaming at him when he stops some seedy-looking characters from entering your establishment. Now if NOD32 were famed far and wide for FPs, your whining might have some merit, but unfortunately this is not the case and your experience is nothing but an isolated incident. If you pay good money for an antivirus program, this implicitly means you trust its judgment; if not, find another. There's no point in coming here and accusing a software for doing its job.

 

what counts is how fast the fp gets removed from the database when you send it to eset?
if an antivirus companie can check and remove the fp from the database within say one day or less thats really good like a company i wont mention.
so send it to eset and tell us how long it takes until its taken out of database and also tell us if you get an email back telling you its been taken out?
lodore

 

Detection was removed yesterday. As I said, the program uses viral obfuscation of the code which is typical for malware and has not been seen in legit programs so no wonder it was detected.

 

Hello,

It was very interesting to read this message thread--and more interesting to watch and listen to the video.

For those who are unfamiliar with what occurred (or were unable to view the video), what happened was that JimHubbard tried to download a utility program called RyanVM Integrator, which is a slipstreaming utility for Microsoft Windows XP. While there's nothing particular unusual about that (there are several programs available to perform this task) what is interesting about RyanVM Integrator is that it is written in AutoIT Script.

As the name implies, AutoIT Script is a programming language, and it is specifically designed to create small utility programs to collect low-level information, manage systems and so forth. It is a good prototyping tool and you can actually create some fairly powerful programs with it. I have used it a little, but am not particularly familiar with it. Anyways, you can read more about it on the author's site.

Now, when you have a tool like AutoIT which is (1) easy-to-use; and (2) powerful, you enable several actions that were previously not possible: For example, it might allow a system administrator to create a simple inventory tool for the computers on his network. Or, someone might use it to write a worm, password stealer, bot or other piece of malware. Like any other sufficiently powerful tool, it can be misused. A quick check of ESET's web site reveals that there have been about fifty signature updates to detect malware written in the AutoIT language, so while it is not something like Vundo or Zlob that have a robust ecology (malware-wise), it is certainly something that is being looked at by malware authors as an enabling tool.

Which leads us to the problem Jim Hubbard experienced. He downloaded--or tried to download--a utility program written in the AutoIT scripting language that contained a sequence of commands that were designed to obfuscate what the program was doing. While this is not something which is normally considered malicious (obfuscation is a technique commonly employed by copy protection programs), this type of behavior has, up to this point, only been seen in malicious AutoIT scripts, which is why it was detected by NOD32 v2.7's IMON module when Jim Hubbard attempted to download the RyanVM Integrator program.

When a malicious program is reported and none is actually present, it is called a false-positive alarm. Conversely, a missed piece of malware is a a false-negative alarm. As Marcos noted, the false positive reported by Jim Hubbard has since been fixed.

So, now everyone who is reading the message thread should have an idea of what occurred, how it was dealt with by ESET, read Jim Hubbard's logic diagram on how NOD32 should behave, seen commentary from other forum members and so forth.

And now we come to the key part of this, the kernel of the message thread, if you will, Jim Hubbard's video. Watch the video, and more importantly, listen to it. One thing becomes readily apparent: Jim Hubbard is concerned about NOD32 because it behaved in a fashion different than what he expected.

Jim Hubbard went to perform a typical "power user" type activity (download a utility to slipstream an XP CD) and received a false positive alarm type report from his copy of NOD32. He then logically deduced a course of action and stepped through a sequence designed to lead to that, looking at all the available options in NOD32, even reviewing the online help to see what guidance it could provide.

So, after reviewing all of this, you're probably wondering what the answer is to Jim Hubbard's problem, or perhaps what my solution is. Well, here's my answer: I don't know.

It is clear to me that the software behaved in an unexpected fashion, and that there did not seem to be a logical way to troubleshoot the problem. So, my takeaway from the matter is that ESET needs to look better at human factors engineering, specifically the end user's experience with the software. What that solution may be, I cannot say, it may be something like Jim Hubbard suggested, it may be something else that is procedural in nature, or a function of documentation. My personal preference would be to do whatever has the least amount of impact on the stability, reliability, speed and size of the software, as well as to the user experience, but whatever that range of options might be needs to be carefully explored, not just to make sure that the software works unambiguously for Jim Hubbard, but for all the users out there.

Regards,

Aryeh Goretsky

 

I can see why Jim got extremely annoyed by this. If you need to download a specific file and get a false positive, there is no way to circumvent but uninstalling and reinstalling NOD32 (after the file is deleted from the system).

That being said, I never had a false positive with NOD32. This file seems to be a very rare exception. More user control is never a bad thing. After some multiple confirmation the user should be able to circumvent the NOD32 lock and get urged to upload the file to ESET so they can investigate.

 

That's good work.

 

Hello,

I can see why Jim Hubbard got annoyed by it, too. It is annoying. It is also something that cannot be fixed as simply as a false positive alarm (which themselves are not always easy to resolve).

But the underlying problem is not something that is going to be particularly easy to resolve: How do you programmatically codify a set of procedures to handle a false positive alarm? Bear in mind, this is not simply a matter of creating a bypass mechanism. There is going to be people who are going to want it to function in different ways, including not at all. There is also going to be questions about how to manage such functionality within the program and formally validate it.

Also, consider this: Jim Hubbard's model is one of informed consent: The user understands what has occurred and makes a decision based on that. But what happens when you have a user who does not understand what is occurring? What if the threat identified by the software is not a false-positive alarm? What if the mechanism introduces a vulnerability in the product?

This is something which needs some serious thinking about and modeling in order to come up with an answer. It is not something that is going to be solved in a day or a week or maybe even a month. I also strongly suspect that the answer is not going to merely be programmatic, but require some steps on the user's side as well.

Regards,

Aryeh Goretsky

 

I've become used to FPs on AutoIt applications. Every AutoIt app that I submit to Virustotal has always 2 or 3 detections at least. For example, REACT (a ripping tool) is always detected (not by NOD32 IIRC) despite being more than 1 year old.

 

What about having an "Exempt This File" button on the threat screen?

 

I agree with you for the most part in excluding a false positive...but, to exclude a file/name wherever it may exist on the computer I'd consider risky to say it mild.

In my opinion the best would simply be to have the detectionscreen show two options in addition to what it already shows:

Allow Once: would allow execution etc of the file without adding it to trusted files

Trust this file: add the file (including path) to the normal trusted list, maybe with a checksum of the file to only exempt the file specifically told to, and not an eventual later modification of it.

You may have some kind of warning asking you to confirm before actually doing any of those.

In my opinion this is a best of both worlds approach as you don't need to clutter the trusted list with temporary files, but you can permanently trust a specific file if you really want to.
This approach limits the security impact of the exemption to a near minimum.

 

the "exempt this file" option would be nice to have, but i would like to have this option activated by a setting like "activate power user options" so the regular 'dumb' user would not be able to infect himself easily then blame ESET for their crap antivirus

 

Totally agree.

 

I have no problem seeing this as a poweruser option. Apparently most can agree that some sort of exemption would be preferable in some cases..
No doubt it's better than disabling AV while using a specific file for whatever reason at least.

My previous AV did have these options (by default), however it suffered from other problems due to incompatibility with other security software on my computer.

 

Power user options....... are your serious ? Why not two settings options : dumb or power user !!! Some dumb may think they are good enough for power user setting...... AV editor that will offer these settings is dumb !

I really dont agree !

 

+1

 

i donwnload your program
and my nod32 doesn't block it today
it's a cool program
there is not a uninstaller how can i uninstall it?

 

I should have been more explicit in my description. The file should have a hash of it added to a whitelist (like programs like Faronic's AntiExecutable application uses) of executables allowed to run on the PC. In fact, using a whitelist of hashes would probably make NOD32 even faster than it already is - assuming it is doing real-time scanning of every file opened.

Scan a file. If it is clean, add it to the whitelist. If not, show the threat screen with the "Exempt This File" button that a user can use to add it to the whitelist.

The reason that I suggested exempting a file (no matter the path) is that the file I was blocked from downloading by NOD32 was being blocked in the temporary internet cache. It never even made it to the desktop where I was trying to save it. Exempting the file would take care of this issue.

And, I do like your idea of "Allow Once" also.

 

That is why I suggested sending the file and user/pc info to Eset whenever a file is exempted manually.

This would protect Eset in just such a case, and would still allow users unrestricted access of their PCs.

Trying to program the 'dumb' out of end users is futile - just ask Microsoft. In fact, you can ask me.

My small business networking company offers a PC setup that installs all needed applications for a company's workers, updates those applications monthly (or whenever a security threat is patched within the month) and we GUARANTEE no viruses or malware of ANY kind or we will clean it up for free.

We've demo'd the system many times - offering to give away the demo laptop to anyone that could infect it (without physically opening the machine).

Know how many laptops we've given away out of hundreds of demos? Not one. Know how many takers we've had for this ultra secure system? Exactly none!

In the vast majority of cases, people just don't want safety at the expense of freedom. Even if their safety is guaranteed. (You'd think the Bush administration would've figured that out by now - wouldn't you?)

The "safer" you make systems, the less powerful they become. For some users, a "green screen" terminal may suffice. But, there are many, many others (like myself) who are perfectly fine with the risks inherant in a powerful system that allows me to make my own decisions...and even mistakes.

Essentially what our clients consistently tell us is "I'm a big boy now and I'll run with scissors if I damned well please. Thank you very much." And, we listen.

We let them run with the scissors, after explaining the possible scary outcomes of such actions and we stock up on first aid supplies while we wait. Sometimes they get hurt. But, they always seem to come out of it a little wiser than before, and a litttle better at caring for themselves.

I think that's exactly what might happen here with that little "Exempt this File" button. In fact, I'd be willing to bet on it.

 

If I am standing beside the bouncer during the incident (as I was with NOD32 when this incident happened), and if I saw the bouncer stop somebody from entering that I had invited to my establishment (as I saw with NOD32 block the file that I was trying to download), and if I told the bouncer to allow him in regardless of his looks (because I trusted him - as I trsted the file and source in this instance of NOD32's rejection) and he refused - well, he'd be fired.

He's the bouncer. He did his job and warned me of what he saw as an unseemly character. I happen to know this person and he is a friend of mine, so I overuled the bouncer (which is my perogative as the employer). If the bouncer did not abide by my wishes, he'd be looking for other employment.

In this instance, I am the boss (the owner of both PC and software license of NOD32). What I say goes.....even if I am wrong - because I am the customer and the king of my domain (my PC in this case).

Not according to this forum. If you will kindly search for "false positive" before spreading falsehoods here, the thinking posters here would surely appreciate it.

For the most part, you are correct. However, being a programmer myself, I know that all software will misbehave from time to time. I trust no software implicitly. To do so would show a level of ignorance about software and programming that I am no longer capable of....even in jest.

NOD32's "job" is not to take control of one's PC at the expense of the PC owner's right's on his/her own system. You should always be in complete control of your system.

If you are not comfortable with being in complete control of your system, I humbly suggest that you get a friend to set yours up with DeepFreeze to protect you from the "bad guys" as well as yourself. It won't be a terribly useful system as far as I count useful systems, but it will be very "safe".

 

And so you are. You can add the file to the exceptions list, or turn NOD32 off temporarily. That's an exceedingly simple task that I'm quite confident isn't beyond the level of computer knowledge of a "programmer", but I guess it's a given that a part of the human population would rather whine and make videos than to exercise the very obvious and simple solution to the problem.

Those thinking posters will also surely appreciate my educating you of the fact that just because false positives are reported in the product's official support forum, doesn't mean the product produces them frequently.

You're most certainly welcome to your opinion. Have a nice day.

 

You are right. You could turn off NOD32 temporarily, exposing you to anything downloaded into your internet cache directory.

It's just that, with modern tabbed browsing and the prolific use of javascripts, flash and activeX components that can be used to try and infect a user's PC I thought it may be wise to only open the door enough to let in the file that you wish to exempt.

My suggested solution is a simple, elegant one (from an end user and programmer standpoint). People like simple.

If raising an issue of usability in a moment of exapseration is whining, then a whiner I be. But, your "very obvious and simple solution" opens the door to any other site that may be open, any application that may have been compromised or have malicious intent by letting down your guard on one of the most dangersous areas of your PC - the internet cache directory.

I simply think that that is unwise.