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: