
Nmap Development mailing list archives
Re: False positives on antivirus
From: Fyodor <fyodor () insecure org>
Date: Tue, 2 Feb 2010 17:02:19 -0800
On Thu, Jan 28, 2010 at 09:57:15AM -0600, Ron wrote:
2. Encrypt the file properly --> No reason that it wouldn't work (though I've said that before and was very wrong ;) ) --> Dependency on OpenSSL (dependency already exists) --> Will take me awhile to implement (I'm going to be rather busy for the next month or so) 3. Include the file separately --> The most obvious solution --> Adds some burden to the user, but it would be minimal --> Could run into versioning pains (though I can't see it being updated too much) Right now, I propose we go with #3, at least for the short term. I've attached a patch that'll do exactly that (with the URL blocked out with TODO for now). It'd probably be a good idea to tweak the output a bit, but this is what it does right now:
That sounds good. David is going to apply this, maybe with a few changes. For example, we probably want to show the messagqe in "verbose" mode rather than just debugging, so users w/o -d still know why the script doesn't work. If this was a permanant solution, we'd probably fix it so that the message is only printed the first time smb-psexec produces output. That might actually be a neat library function to have. It would presumably check if a registry field exists which says a note has already been printed, then if not it would take a mutex, check the field again to avoid a race condition, then set the field and add the note to the output. But I agree with Ron that in this case, the encrypt-the-file-and-remove-the-exe extension is probably a better approach. So we'll probably just leave the note in for verbose mode for now. And hopefully Ron will get a chance to resolve this before the next release. I just uploaded nmap-5.21-setup.exe to VirusTotal again and here are the results: http://www.virustotal.com/analisis/b9aa3c96c31b6a8088fef744323a553d8a023538fee9392af01f029d43b635de-1265148730 It is nice that Panda really did fix their signature. The only flag left is McAfee+Artemis listing it as suspicious, which may not be such a big deal. So I don't feel like we need to immediately issue 5.22. But we should still get rid of the XOR version (and try to replace it with an encrypted version for the next release), as it is subject to 1 current signature and there is a definite risk of more in the future as AVs try to match other XOR'd executables.
I didn't delete nmap_service.exe in the patch -- we'd have to do that and upload it somewhere. I could technically host it, but it'd probably better to host it on nmap.org.
Good point. Maybe David can put it somewhere such as http://nmap.org/psexec/nmap_services.exe along with a short note in that directory.
I'll work on solution #2, code name "nuke it from orbit" when I have some more time.
Great! -F _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- False positives on antivirus Ron (Jan 28)
- Re: False positives on antivirus Michael Pattrick (Jan 28)
- Re: False positives on antivirus Ron (Jan 28)
- Re: False positives on antivirus Fyodor (Jan 28)
- Re: False positives on antivirus Ron (Jan 29)
- Re: False positives on antivirus DePriest, Jason R. (Jan 29)
- Re: False positives on antivirus Brandon Enright (Jan 29)
- Re: False positives on antivirus Fyodor (Jan 29)
- Re: False positives on antivirus Ron (Jan 29)
- Re: False positives on antivirus Fyodor (Jan 29)
- Re: False positives on antivirus Michael Pattrick (Jan 28)
- Re: False positives on antivirus David Fifield (Feb 12)
- Re: False positives on antivirus Ron (Feb 12)
- Re: False positives on antivirus David Fifield (Mar 03)