On 23/01/2010, at 15.11, G.W. Haywood wrote: > Hi there, > > Please try to be more informative in your questions. You have omitted > important information from your posts, and you continue to do so. It > makes me suspicious.
It was not intentional. Which important information are you missing? > Many new malware signatures are being added to anti-virus databases > world-wide every day, and occasionally one of these signatures will > unintentionally match something else - perhaps another piece of > software, or a document, or even just a collection of random data - > which is unrelated to the malware. When that happens, we have what's > known as a false positive. A false positive is what i think we have here. > Throughout the world there are many millions of systems which contain > many thousands of files which are identical on each system. Various > Windows systems for example have many identical binaries. It's easy > (relatively easy) to check that new malware signatures don't trigger > on most Windows boxes by running them past a few test machines in the > laboratory. Unfortunately, for obvious reasons, there's no way that > all the software and documents in the world can be used to check for > false positives from each new signature in the test lab. One has to > rely on probabilities and feedback. In the case of ClamAV, there are > feedback mechanisms documented on the Website. i did not succeed in finding the information i was looking for on the website. I tried searching for false positive, because that is what i believe we have since only ClamAV detects it. > On Sat, 23 Jan 2010 Jon Bendtsen wrote: > >> G.W. Haywood wrote: >>> my guess is that you don't really >>> know if the files have been changed in the past year or not anyway. >> >> I know, because i scan on the backup server. The backup server uses rsync >> to move the files over, and any changes in existing files will be noticed. > > Are you sure about that? By default, rsync checks only the file size > and the last modified time. You need to force it to run checksums on > the files to be sure that actual data changes will be noticed, and of > course this takes very much longer than just the quick timestamp and > size checks. So most of the time people don't do it, because one of > the main reasons they use rsync is for its speed when compared with > repeatedly copying hundreds of directory trees file-by-file. You already warned me of that privately, and i did answer. The backup scripts are some i have inherited from the former sysadm. I will investigate if i need --checksum. >>>> How do i KNOW FOR SURE, if it is a real positive or just a false >>>> positive? >> ... >> The software in question is something we programmed ... > > I'm struggling to make sense of this. The normal process of software > development requires that an archive is kept of all software releases > so that, at a bare minimum, faults can be tracked and fixed. It must > be obvious to any competent programmer how to keep archives of his > work which cannot be changed without his knowledge. For example, he > can archive digitally signed or encrypted backup copies, write copies > to a write-once-only medium such as CD-ROM, or write to a floppy disc, > break out the write-protect tab, and put the disc in a safe. At the > very least, he can store the md5sums of the files on a piece of paper > and keep it in his wallet. Have you done nothing like that? We have self burned DVD-ROM images, and naturally i have scanned those. With the same result. I did not mean any harm, but i simply forgot to mention this, because it was scanning the backup that triggered and emailed me. > It should also be obvious how to make sure that something you have > written doesn't contain anything malicious. I'd go further, and say > that it's irresponsible to release software if you are not capable of > doing that. Is there something else that you haven't told us? While it is rather easy to trust what you read in your own source code, modern software contains a lot of libraries, and lots of tools are used in the building process. Some of these tools, if not most, are binary and much harder to 100% prove secure. Theoretically someone could redo the evil C compiler hack. naturally we scan all software going out, the coder machines, the builder machines, the servers and the DVD burner. But it was last year. While nothing was found back then, that could just be because the trojan in question is newly found. Our intention is to be responsible and investigate until we are 100% certain nothing is wrong. This is why i asked, because i dont work with viruses and trojans all day, like i expect you guys to do. So maybe you knew some method that i did not think of myself. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
