[clamav-users] ScanOLE2 yes disables macro virus detection
Hi, I found some problems with the way clamav handles OLE2 containers. This is causing many macro virus sigatures to not work and many viruses to be missed: If ScanOLE2 is set to yes, clamav only appears to scan the decompressed macro files in OLE2 containers. It does not scan any of the other files in the container. If ScanOLE2 is set to no, clamav does not appear to extract any files from the OLE2 container. It just runs signatures against the container file itself. This can be tested with clamav --debug --leave-temps and --scan-ole2 yes or no and writing some signatures against the uncompressed macro files and the other files in the container. This behaviour contradicts signatures.pdf: 2 = file inside OLE2 container (e.g. image, embedded executable, VBA script) which implies signatures for file type 2 will be run against files extracted from OLE2 containers. Which implies files ought be extracted from OLE2 containers and scanned. But this is not the case, whether ScanOLE2 is yes or no. All file type 2 appears to denote for a signature is that that signature should only be run against files recognized as an OLE2 container. It does not mean that the the signatures will be run against each file in an OLE2 container. Setting ScanOLE2 yes, disables the running of signatures of type 2 or any type at all ie type 0, against the OLE2 container itself and causes only signatures of type 2 or 0 to be run against decompressed macros from the OLE2 container. But most of the badmacro or other unofficial virus signatures written to detect macro virus are written against the container itself which has the compressed macro code in it. They are not written against the uncompressed macro code, so setting ScanOLE2 yes will disable these signatures. A check of some macro viruses received in last 6 months shows none detected by clamav official signatures. The work going into macro virus detection appears to be in the unofficial databases. But the signatures in these databases are simple byte matching signatures and not based upon detecting actual VBA code and looking for the patterns of logic used by virus writers in their code. The signatures will fail when matching uncompressed actual vba code when ScanOLE2 is yes. The signatures won't match at all when ScanOLE2 is yes. They only match if ScanOLE2 is no. But then signatures written against vba code in the uncomressed macros are not matched. We are seeing OLE2 virus files where the macros extract the malicious code from other files in the ole container at run time. These viruses are completely missed when ScanOLE2 is yes , no matter what signature you write, as the non macro files in the OLE2 container are not scanned and the scanned files ie the uncompressed macro vba code, don't contain the malicious code. The non scanning of 'other' files in OLE containers if ScanOLE2 is yes or the non scanning of decompressed macros if ScanOLE2 is no is causing macro viruses to be not detected and this appears to be a bug or limitation of clamav (or maybe a misconfiguration ?). Ideally clamav would scan the OLE2 container itself, all the contained files and also the uncompressed macros . Also there is some confusion as to what file type 2 means. Should this denote run signatures against a file recognized as OLE2 or should it mean run signatures against files within an OLE2 container. eg a signature of type 2 would not be expected to be run against a file inside an OLE2 unless that file is also an OLE2 container. signatures.pdf is misleading in its description of file type 2. It seems the OLE2 handling needs to be split into 2 parts , 1 . scanning of the container and all the contained files. 2. Scanning of uncompressed macros . If this were done a special file type to restrict scanning to only uncompressed macros would be useful to prevent false positive. If it can't be fixed then ome clearer explanation of the OLE2 scanning would be helpful as its misleading at present. -- David Shrimpton Information Technology Services | The University of Queensland ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] ScanOLE2 yes disables macro virus detection
Hi Steve, When I scan the file with any of: clamscan -z --scan-ole2=no --database=badmacro.ndb clamscan -z --scan-ole2=yes --database=badmacro.ndb clamscan -z --scan-ole2=no 13 signatures from badmacro.ndb are detected. But when I scan the file with clamscan -z --scan-ole2=yes no signatures from badmacro are detected -- David Shrimpton Information Technology Services | The University of Queensland ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] ScanOLE2 yes disables macro virus detection
Hi Steve, When I remove all my local database files problem goes away. So problem appears to be in a local database. I narrowed it down to one .ldb file. But the problem doesn't seem to be as simple as one particular signature in that file. I can remove signatures until the problem goes away, but then adding any signature to that file that is matched causes problem to come back. eg adding sig below causes the problem. BAD_SIGNATURE.ldb.macro.19;Target:2;1;41747472;0:(0)/./ri The debug file with scan-ole2=yes is showing LibClamAV debug: FP SIGNATURE: 924d8e14ccb2604effc455e1a584cb80:93184:BAD_SIGNATURE.ldb.macro.19.UNOFFICIAL just before exit. This being md5sum:size of the doc being scanned. FP reads like false positive but I don't think it means this. "FP SIGNATURE" seems to be always logged with the last signature matched whether the problem is present or not. I note the same md5sum:size in winnow_malware.hdb 924d8e14ccb2604effc455e1a584cb80:93184:winnow.malware.135963 Seems like some sort of weird bug exercised by the signature set in my local databases when scan-ole2=yes . I'll keep trying to narrow it down. -- David Shrimpton Information Technology Services | The University of Queensland ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] clamscan doesn't have a BlockMacros option
Hi, clamscan doesn't appear to have an option equivalent to the OLE2BlockMacros in clamd.conf for clamdscan. clamdscan will report Heuristics.OLE2.ContainsMacros FOUND for a file with macros if OLE2BlockMacros is yes but clamscan doesn't appear to be able to do this. clamscan does however have a --heuristic-scan-precedence equivalent to HeuristicScanPrecedence from clamd.conf which controls behaviour of OLE2BlockMacros if file is detected by both Heuristic and real signatures. Is there a way to turn on the OLE2BlockMacros behaviour with clamscan ? -- David Shrimpton Information Technology Services | The University of Queensland ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] ScanOLE2 yes disables macro virus detection
sted to see if image , archive ... and then only image sigs applied to the image etc The debugging could be improved by logging what files are being scanned and when. Its not possible from the debug output to determine which of the files in an OLE2 container are being scanned if any. So its hard to know if a sig against a file inside the container did not work or the file inside the container was never scanned. A sequence of bytes in an OLE2 container does not necessarily or maybe ever decompress to the same sequence of bytes in an uncompressed macro extracted from the container. So a sig against the container itself won't work against the uncompressed macro and vice versa. But a sequence of bytes in a container may be the same sequence of bytes in another type of file extracted from the container. So that sig may match the container itself or the extracted file. But as debug doesn't report the file being scanned you won't know if a match is against the container or the contained file and also won't know if the contained file itself was scanned or not. David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] heuristic-scan-precedence is broken
Hi, --heuristic-scan-precedence=no is broken in clamav-0.99 eg create a test encrypted zip /tmp/abcdef.zip clamscan -z --database=/tmp/test.ndb --block-encrypted=yes /tmp/abcdef.zip /tmp/abcdef.zip: Heuristics.Encrypted.Zip FOUND clamscan -z --database=/tmp/test.ndb --block-encrypted=no /tmp/abcdef.zip /tmp/abcdef.zip: testsig.1.UNOFFICIAL FOUND /tmp/abcdef.zip: testsig.1.UNOFFICIAL FOUND clamscan -z --database=/tmp/test.ndb --block-encrypted=yes --heuristic-scan-precedence=no /tmp/abcdef.zip /tmp/abcdef.zip: Heuristics.Encrypted.Zip FOUND With --heuristic-scan-precedence=no testsig.1.UNOFFICIAL should have been returned and not Heuristics.Encrypted.Zip . With -z --heuristic-scan-precedence=no , both testsig.1.UNOFFICIAL and Heuristics.Encrypted.Zip should have been returned. This is same problem as occurs with clamdscan and OLE2BlockMacros yes. Heuristics.OLE2.ContainsMacros gets returned and not any real sigs that also might match. I suspect --heuristic-scan-precedence=no might not work for any heuristic detection. If heuristic-scan-precedence=no worked , you could parse the returned virus name and treat files that only matched Heuristics sig eg pdf or encrypted zip or ole2 with macros, differently to files that matched a real sig. eg do logging only instead of discarding. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] What does TargetType 10 for a signature mean ?
Hi, I wrote a signature against one of the temporary files clamav pulled out of a pdf when --scan-pdf=yes. (The signature does not hit when --scan-pdf=no.) If the signature is TargetType 10 = PDF it was not hit. If it was type 0 = any file, it was hit. But it would also be hit by other files not related to the pdf eg text or html, which I don't want. I only want to match files pulled out of a pdf by --scan-pdf. (clamav --debug reports the file from the pdf as ascii , but Target Type 7 for normalized ascii file does not work.) This is similar confusion to what type 2 means. signatures.pdf says type 2 is file inside an OLE2 container but it actually appears to denote an OLE2 container itself and not a file inside one unless that file is itself an OLE2 container. It seems to me that having additional types may be helpful: eg any file inside an OLE2 or any 'file' inside a pdf in addition to type 2 and 10. PS it appears -z does not work when there is a hit on a 'file' inside a PDF. Other signatures that match the pdf itself are not reported as being hit. This is a similar problem to -z not working when there are hits on macros inside OLE2 or a hit on Heuristics.OLE2.ContainsMacros. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] yara #match does not work with regex
Using #match as a condition in a yara rule to count the occurences of $match doesn't appear to work where $match is a regex. #match only appears to work if $match is a string literal eg "abc123" Is #match intended to work with a regex ? -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Sigtool parsing issues
On Tue, 16 Aug 2016, Jack wrote: > > To note, the document opens fine in Microsoft Word, and oletools has no > issues dumping out the macros. Hi, I have observed this problem too with files that file reports as "Microsoft Word 2007+". oledump will extract the macros but not sigtool. clamav appears to still extract the macros and signatures written against the macro code still work. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Sigtool parsing issues
On Tue, 16 Aug 2016, Jack wrote: > Hello, > > I am attempting to dissect a document’s macros using sigtool, but am running > into a problem. Nothing is being returned when the following command is run: > > $ sigtool --vba > '237b81cda8251aac11eaa28387765e6dd165664aa87563a6bce5951dd5ca4de3.bin’ The document isn't a zip file is it ? (Or some other file containing the OLE2 file) The Microsoft Word 2007+ file I had the same error with was a zip archive so I had to do a zipinfo to find the vba file , which is the OLE2 file, then extract that with: unzip file.doc word/vbaProject.bin Then run sigtool --vba=word/vbaProject.bin > macros sigtool was just failing because the Microsoft Word 2007+ file was not an OLE2. clamav succeeds as it extracts the OLE2 file from the zip. oledump must be able to extract the OLE2 file from the zip as well. The same problem occurs with .docx which are zip but not with .doc which are 'CDF V2 Document' which are the OLE2 file itself. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Understanding OLE2BlockMacros
HeuristicScanPrecedence No is broken with OLE2BlockMacros Yes. It only applies to signatures being run against uncompressed macros. If there is a hit on one of those signatures , that signature hit is returned and not Heuristics.OLE2.ContainsMacros. Otherwise Heuristics.OLE2.ContainsMacros is returned and no other signatures are tried. This disables all the official and unofficial signatures that are not written again uncompressed macros , which is effectively all of them. There are few or no official signatures for macro viruses. The official signatures are of little value in protecting against macro viruses. Commercial antivirus products are also of little value particularly against 'zero day' exploits. Submit every new macro virus file you identify to one of the web based A/V scanning services that use multiple vendors products , if you do not believe this. One well known vendor sometimes responds to a submissions of macro virus docs advising they are only interested in the downloaded malware not the doc that downloads it. Re unofficial sigs , there are few or no unofficial signatures written against uncompressed macros. These signatures are not targeting the code and obfuscations being used by virus writers. You may have more success writing your own signatures based on macro code seen in viruses. As the code is often re-used , signatures written against macro code may provide better 'zero day' protection than other signatures eg unofficial or official ones. I think the main usefulness of clamav is not as an off the shelf A/V product whether supplemented by unofficial signature or not , but as a tool for implementing your own A/V ideas. If you implement your own signatures you will also have control over the aggressiveness of those signatures with respect to false positive, which you will not have with official or unofficial signatures. Overly aggressive signatures might however make sharing signatures a dis-service. It is worthwhile exercise to decode some examples from any unofficial signature database before using it and form your own opinion about the likelyhood of false positive. As the unofficial and official signatures are written after new viruses arrive they are generally too late to be of use in 'zero day' attacks. If you don't implement your own signatures against macro code, setting OLE2BlockMacros Yes effectively causes Heuristics.OLE2.ContainsMacros to be returned and disables all official and unofficial signatures. If OLE2BlockMacros is Yes then the only option is to treat every file with macros as a virus and eg discard if you want to block the files that do contain a macro virus. It might be argued that files with macros should be treated similarly to any other executeables shipped in email from outside your organization and discarded if that is your policy. Note , clamav returns the first signature hit unless -z option is used. The OLE2 signatures are run before any other signatures so OLE2BlockMacros Yes , causes Heuristics.OLE2.ContainsMacros to be returned first and all other signatures that are not against uncompressed macros are ignored. You only get one signature back and that is the first one hit, which may be a 'soft' signature ie one you mightn't discard an email on, such as Heuristics.OLE2.ContainsMacros, even though 'hard' signatures official or unofficial might also have hit if they had been run later . One useful strategy may be to combine the Heuristics.OLE2.ContainsMacros with other information from an email and discard files containing macros that are probably viruses eg invoices and resumes. The Heuristics.OLE2.ContainsMacros hits are arguably more useful in identifying potential macro viruses than is turning OLE2BlockMacros off and using the unofficial and official signatures. Clamav -z option is also broken for OLE2BlockMacros Yes and HeuristicScanPrecedence No. Only signatures matching uncompressed macros and Heuristics.OLE2.ContainsMacros are returned. All other official and unofficial signatures are ignored so not all the signatures that would match are returned. This is a bug/limitation. Logically HeuristicScanPrecedence should be ignored with -z. If clamav -z returned all the matches you could implement a "quality of service" type scheme and parse all the returned signature hits including Heuristics.OLE2.ContainsMacros and prioritize the results eg discard if a 'real' virus or just add a warning if only Heuristics.OLE2.ContainsMacros was returned. Or you could treat unofficial hits with more caution eg add warning only and official hits more aggressively eg discard. But -z is broken with OLE2 ,so you must decide to use OLE2BlockMacros and not official/unofficial signatures or not use OLE2BlockMacros. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
Hi, Win.Trojan.Agent-1696554 added to daily.hdb on 21/9/16 is an md5sum of a file containing 2240 null bytes only, so appears to be a broken signature. It is causing false positives. The example I have was a FP on a 944010 byte pdf which comes up negative on virustotal except for clamav. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
> > Confirmed FP I would say: > > https://virustotal.com/en/file/2f7eaacf490839d9c603736149286272aea4df46c0daf58f0c70062041c68230/analysis/ > > Agreed, above being the sha256sum of 2240 null bytes. The hit on the null bytes could of course be masking actual malware in the same container the file of nulls came from . Presumeably clamav is missing a signature for the original malware that prompted the broken signature. So my pdf might still contain malware and whitelisting the sig while logical might lead to an unfortunate result for anyone then receiving and opening the same pdf. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
On Tue, 27 Sep 2016, Al Varnell wrote: > The signature is based on a 2240 byte file, so it is probably something > embedded in the PDF. Yes, the 2240 null byte file pdf51 is extracted by clamav from the pdf. --leave-temps and --debug can be used to show this and to obtain the file. md5sum pdf51 013167adb9fbc93923f9c0789599ec95 pdf51 sha256sum pdf51 2f7eaacf490839d9c603736149286272aea4df46c0daf58f0c70062041c68230 pdf51 (sha256 sum is in the virustotal url not md5sum). The md5sum and sha256sum of the original malware are unknown. I don't have the malware only a file with a FP on the broken signature , that may or may not also contain malware or be the original malware. The clamav hdb signature is independent of file type and would match any 2240 null byte file not just a file extracted from a pdf. Incidently clamav debug shows the file as stream 68 0 , but stream 68 does not extract to a 2240 null byte file with pdf-parser.py. Uploading the null byte file to fp would make sense. But anyone can create the file themselves. Uploading the pdf to fp might not make sense as is unknown if it contains malware or not. The pdf scans negative except for clamav on virustotal, but could still contain malware. https://virustotal.com/en/file/13f14263e8268626e7a7f42e10dab99b87007cf6f2a29affd46f2cafa2ecb607/analysis/ Note the filename is not the same as original. sha256sum Deal.pdf 13f14263e8268626e7a7f42e10dab99b87007cf6f2a29affd46f2cafa2ecb607 Deal.pdf Is the original malware sample for which the signature was intended still available and does it have the above sha256sum ? -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
On Wed, 28 Sep 2016, Joel Esler (jesler) wrote: > All - > > This signature was my fault. It has been dropped. Should drop with the next > publish and run of freshclam. > Win.Trojan.Agent-1696554 is now dropped. But, the pdf is now detected as Win.Trojan.Agent-1696579. Win.Trojan.Agent-1696554 was published in Version: 9 Sep 21 and is: 4b5acd7f457d05cd4268d56e67dcffb9:4416:Win.Trojan.Agent-1696579 4b5acd7f457d05cd4268d56e67dcffb9 is md5sum of 4416 null bytes . Clamav --debug --leave-temps extracts a file pdf78 from the pdf with 4416 null bytes only and this causes the hit on Win.Trojan.Agent-1696554. Might be something wrong with many more sigs from Version: 9 ? Might be worth doing all the null byte files from 1 to X in size and running clamscan against them. David Shrimpton ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
On Wed, 28 Sep 2016, Joel Esler (jesler) wrote: > These signatures were generated out of attachments to know bad spam files. > We'll have a look. > clamscan -z on pdf shows: Win.Trojan.Agent-1696579 Win.Trojan.Agent-1696632 Win.Trojan.Agent-1696690 Win.Trojan.Agent-1696882 Win.Trojan.Agent-1697875 Win.Trojan.Agent-1697950 Win.Trojan.Agent-1698234 Win.Trojan.Agent-1698242 I'd speculate that all these sigs are broken any maybe many more for other null byte file sizes not present in my pdf. David ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] FP: Win.Trojan.Agent-1696554 is md5sum of 2240 null bytes
> These signatures were generated out of attachments to know bad spam files. > We'll have a look. > I generated the null byte files from sizes 1 to 1 and ran clamav against them and came up with 785 signatures that matched the null byte files and are therefore broken. I'd speculate that is the tip of iceberg and scanning from above 1 may reveal many more. Is there some where I can send this info when I do 1+ David 785 broken sigs for null byte files sizes 1 to 1 Win.Trojan.Agent-1695127 Win.Trojan.Agent-1696476 Win.Trojan.Agent-1696477 Win.Trojan.Agent-1696478 Win.Trojan.Agent-1696479 Win.Trojan.Agent-1696481 Win.Trojan.Agent-1696482 Win.Trojan.Agent-1696483 Win.Trojan.Agent-1696484 Win.Trojan.Agent-1696485 Win.Trojan.Agent-1696488 Win.Trojan.Agent-1696491 Win.Trojan.Agent-1696493 Win.Trojan.Agent-1696494 Win.Trojan.Agent-1696496 Win.Trojan.Agent-1696497 Win.Trojan.Agent-1696498 Win.Trojan.Agent-1696499 Win.Trojan.Agent-1696500 Win.Trojan.Agent-1696501 Win.Trojan.Agent-1696502 Win.Trojan.Agent-1696503 Win.Trojan.Agent-1696504 Win.Trojan.Agent-1696505 Win.Trojan.Agent-1696506 Win.Trojan.Agent-1696507 Win.Trojan.Agent-1696508 Win.Trojan.Agent-1696509 Win.Trojan.Agent-1696510 Win.Trojan.Agent-1696511 Win.Trojan.Agent-1696512 Win.Trojan.Agent-1696513 Win.Trojan.Agent-1696514 Win.Trojan.Agent-1696515 Win.Trojan.Agent-1696516 Win.Trojan.Agent-1696517 Win.Trojan.Agent-1696518 Win.Trojan.Agent-1696519 Win.Trojan.Agent-1696520 Win.Trojan.Agent-1696521 Win.Trojan.Agent-1696522 Win.Trojan.Agent-1696524 Win.Trojan.Agent-1696525 Win.Trojan.Agent-1696526 Win.Trojan.Agent-1696527 Win.Trojan.Agent-1696528 Win.Trojan.Agent-1696529 Win.Trojan.Agent-1696530 Win.Trojan.Agent-1696532 Win.Trojan.Agent-1696533 Win.Trojan.Agent-1696534 Win.Trojan.Agent-1696535 Win.Trojan.Agent-1696536 Win.Trojan.Agent-1696537 Win.Trojan.Agent-1696538 Win.Trojan.Agent-1696539 Win.Trojan.Agent-1696540 Win.Trojan.Agent-1696541 Win.Trojan.Agent-1696542 Win.Trojan.Agent-1696543 Win.Trojan.Agent-1696545 Win.Trojan.Agent-1696546 Win.Trojan.Agent-1696547 Win.Trojan.Agent-1696548 Win.Trojan.Agent-1696550 Win.Trojan.Agent-1696552 Win.Trojan.Agent-1696553 Win.Trojan.Agent-1696555 Win.Trojan.Agent-1696556 Win.Trojan.Agent-1696557 Win.Trojan.Agent-1696558 Win.Trojan.Agent-1696559 Win.Trojan.Agent-1696561 Win.Trojan.Agent-1696562 Win.Trojan.Agent-1696563 Win.Trojan.Agent-1696564 Win.Trojan.Agent-1696565 Win.Trojan.Agent-1696566 Win.Trojan.Agent-1696567 Win.Trojan.Agent-1696570 Win.Trojan.Agent-1696571 Win.Trojan.Agent-1696572 Win.Trojan.Agent-1696574 Win.Trojan.Agent-1696575 Win.Trojan.Agent-1696576 Win.Trojan.Agent-1696577 Win.Trojan.Agent-1696578 Win.Trojan.Agent-1696579 Win.Trojan.Agent-1696580 Win.Trojan.Agent-1696581 Win.Trojan.Agent-1696582 Win.Trojan.Agent-1696583 Win.Trojan.Agent-1696584 Win.Trojan.Agent-1696585 Win.Trojan.Agent-1696586 Win.Trojan.Agent-1696587 Win.Trojan.Agent-1696588 Win.Trojan.Agent-1696590 Win.Trojan.Agent-1696591 Win.Trojan.Agent-1696592 Win.Trojan.Agent-1696593 Win.Trojan.Agent-1696595 Win.Trojan.Agent-1696596 Win.Trojan.Agent-1696597 Win.Trojan.Agent-1696598 Win.Trojan.Agent-1696599 Win.Trojan.Agent-1696600 Win.Trojan.Agent-1696601 Win.Trojan.Agent-1696602 Win.Trojan.Agent-1696603 Win.Trojan.Agent-1696604 Win.Trojan.Agent-1696605 Win.Trojan.Agent-1696606 Win.Trojan.Agent-1696607 Win.Trojan.Agent-1696608 Win.Trojan.Agent-1696609 Win.Trojan.Agent-1696610 Win.Trojan.Agent-1696611 Win.Trojan.Agent-1696612 Win.Trojan.Agent-1696613 Win.Trojan.Agent-1696614 Win.Trojan.Agent-1696615 Win.Trojan.Agent-1696616 Win.Trojan.Agent-1696617 Win.Trojan.Agent-1696618 Win.Trojan.Agent-1696619 Win.Trojan.Agent-1696620 Win.Trojan.Agent-1696621 Win.Trojan.Agent-1696622 Win.Trojan.Agent-1696623 Win.Trojan.Agent-1696624 Win.Trojan.Agent-1696625 Win.Trojan.Agent-1696626 Win.Trojan.Agent-1696627 Win.Trojan.Agent-1696628 Win.Trojan.Agent-1696629 Win.Trojan.Agent-1696630 Win.Trojan.Agent-1696631 Win.Trojan.Agent-1696632 Win.Trojan.Agent-1696633 Win.Trojan.Agent-1696634 Win.Trojan.Agent-1696637 Win.Trojan.Agent-1696639 Win.Trojan.Agent-1696640 Win.Trojan.Agent-1696641 Win.Trojan.Agent-1696643 Win.Trojan.Agent-1696644 Win.Trojan.Agent-1696645 Win.Trojan.Agent-1696647 Win.Trojan.Agent-1696649 Win.Trojan.Agent-1696650 Win.Trojan.Agent-1696651 Win.Trojan.Agent-1696652 Win.Trojan.Agent-1696653 Win.Trojan.Agent-1696654 Win.Trojan.Agent-1696655 Win.Trojan.Agent-1696656 Win.Trojan.Agent-1696657 Win.Trojan.Agent-1696658 Win.Trojan.Agent-1696659 Win.Trojan.Agent-1696660 Win.Trojan.Agent-1696661 Win.Trojan.Agent-1696662 Win.Trojan.Agent-1696663 Win.Trojan.Agent-1696664 Win.Trojan.Agent-1696665 Win.Trojan.Agent-169 Win.Trojan.Agent-1696669 Win.Trojan.Agent-1696670 Win.Trojan.Agent-1696672 Win.Trojan.Agent-1696673 Win.Trojan.Agent-1696675 Win.Trojan.Agent-1696676 Win.Trojan.Agent-1696677 Win.Trojan.Agent-1696678 Win.Trojan.Agent-1696679 Win.Trojan.Agent-1696680 Win.Trojan.Agent-1696681 Win.Trojan.Agent-1696682 Win.Trojan.Agent-1696683 Win.
Re: [clamav-users] No notice of OLE2.ContainsMacros
> $ clamscan -a -v -z --block-macros=yes /var/spool/mqueue/dfuBJBh64e020058 > Scanning /var/spool/mqueue/dfuBJBh64e020058 > /var/spool/mqueue/dfuBJBh64e020058: OK The dfuBJBh64e020058 file looks like a sendmail queue datafile, in which case it would have no email headers and contain only mime encoding eg base64 and just be a plain text file and not an email file to clamav, so scan negative. If you extract the email file from the queue files, or extract the Office file from the mime part in the df file and re-scan this may work. For sendmail quarantined queue file something like the following will extract the email file: cat hfuBJBh64e020058 dfuBJBh64e020058 > somefile Edit somefile to remove the unwanted lines down to the start of the email headers eg the first H??Received: , then remove H?? at start of lines and change the '.' on its own at the end to just a newline (to mark the end of headers) (Use qf instead of hf for a non quarantine queue file, but also bear in mind that queue processing by the mail daemon may be writing to a qf but not a hf file.) Rescan and clamav should recognize as email file and extract and scan any attachments. -- David Shrimpton ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
[Clamav-users] encrypted zip embedded in other files not detected
Hi, 0.95.2, clamav has closed a bug #1554 https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1554 where an archive embedded in say a bitmap file was not detected and searched for viruses , but the archive would be detected by popular unarchivers. However, when I test, an ecrypted zip embedded in another file is not reported as Encrypted.Zip when ArchiveBlockEncrypted is on in clamd.conf, so it would still be possible to send a virus within an encrypted zip by simply appending a few bytes to the start of the archive. -- David Shrimpton Systems Programmer ITS University of Queensland ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] encrypted zip embedded in other files not detected
Thanks for replies, Submitted new bug report: Bug #1660 -- David Shrimpton Systems Programmer ITS University of Queensland ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] encrypted zip embedded in other files not detected bug is back
Hi, Bug #1660 encrypted zip files embedded in other files not detected seems to have come back again somewhere between version 0.95.3 and 0.96.1. If I append a few random bytes to an encrypted zip it will not be detected by clamav but the zip file will be detected and opened by some programs. (Note the virus naming has changed from Encrypted.Zip to Heuristic.Encrypted.Zip in versions >= 0.96rc1) Has anyone else observed the same problem since upgrading to 0.96 ? -- David Shrimpton Systems Programmer ITS University of Queensland ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[clamav-users] Why does virus name now include size and hash ?
Hi, Since upgrading from 0.96.1 to 0.96.5 virus names returned by clamd in response to a SCAN command now include a md5 hash of the file and the file size eg WM.Psycho(773c612cc779a3433ff5fa16ceeea6a4:51712) instead of WM.Psycho Clamdscan will just return WM.Psycho as before. Setting ExtendedDetectionInfo no in clamd.conf and restarting clamd seems to have no influence over this. Is there a way of turning off the hash and file size in the virus name returned in response to a SCAN command , (rather than writing a regex to parse the result )? -- David Shrimpton Systems Programmer ITS University of Queensland ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [clamav-users] Known issue -- LZX compression
On Sat, 16 Jun 2012, Matt Olney wrote: > All, > > > > We wanted to bring to your attention an issue that we have been made aware > of in ClamAV 0.97.5. As part of this release, we tightened the malformed > compression checks in LZX compressed files. CAB, CHM and Install Shield > file formats may use this compression. > I am seeing a similar error message "CL_EFORMAT: Bad format or broken data ERROR" on some .xls .doc and .pdf files since upgrade to 0.87.5. -- David Shrimpton Systems Programmer University of Queensland ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] signatures lost in 3118 Update
Hi, The Worm.Bagle.Gen-zippwd and Worm.Bagle.Gen-zippwd-2 virus signatures disappeared when the 3118 update was released. Files containing this virus are now only detected as a virus if Encrypted-Zip are marked as virus. There used to be 9 Worm.Bagle.Gen-zippwd* signatures. Now only Worm.Bagle.Gen-zippwd-8 remains. Can anyone please explain why these signatures have disappeared ? This has also happened with other virus signatures in the past and viruses previously detected are no longer detected. -- David Shrimpton Systems Programmer Software Infrastructure, Information Technology Services University of Qld 4072 clamav at its.uq.edu.au Brisbane Australia ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] MaxRecursion MaxFileSize MaxScanSize broken in 0.93
Hi,
When any of MaxScanSize MaxFileSize MaxRecursion are exceeded
clamd returns OK instead of an error message.
But, if MaxFiles is exceeded "Files number limit exceeded ERROR"
is returned.
This is the same in 0.91.2 and 0.93 and appears to be a bug.
However in 0.91.2, ArchiveBlockMax could be set and the offending files
detected as viruses as a workaround.
We'd like to detect these files as they could be compression bombs
or archives containing viruses and in any case are likely to impact on
the performance of mail servers doing virus scanning using clamav .
The bug appears to be in places like the following from
0.91.2 libclamav/scanners.c
if(SCAN_ARCHIVE && ctx->limits && ctx->limits->maxreclevel)
if(ctx->arec > ctx->limits->maxreclevel) {
cli_dbgmsg("Archive recursion limit exceeded (arec == %u).\n",
ctx->arec);
if(BLOCKMAX) {
*ctx->virname = "Archive.ExceededRecursionLimit";
return CL_VIRUS;
}
return CL_CLEAN;
}
In 0.93 the if(BLOCKMAX) part is deleted.
I think that CL_EMAXREC ("Recursion limit exceeded" )
should be returned and not CL_CLEAN.
--
David Shrimpton
University of Qld
Brisbane Australia
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] viruses in comments in scripts not detected by 0.93
Hi, Some viruses eg WScr.Unsafe.D for which a hexdump signature exists and which used to be detected by 0.91.2 are no longer detected by 0.93 . WScr.Unsafe.D arrives in email embedded in a "HTML comment tag" enclosed by HTML script tags. eg <!-- entities');sbf=fl.SubFolders;for(var mye=new Enumerator(sbf);!mye.atEnd();mye.moveNext())idd=mye.item();ids=ne --> When clamav processes this it creates 2 files notags.html and nocomments.html and appears to only scan these files. When notags.html is created the embedded virus is treated as a comment tag and removed. When nocomment.html is created the virus is not treated as a comment tag, but all the whitespace is removed and the text lowercased which breaks the hexdump signature as it requires an exact match. eg var mye=new Enumerator becomes: varmye=newenumerator in the nocomment.html so is no longer matched by the WScr.Unsafe.D signature. If you take the "comment" tag delimiters away the whitespace is not removed in nocomment.html but the virus text is lowercased in both nocomment.html and notag.html and is again not detected (unless you create a signature from a lower case version of the virus text) The implication of the above is that clamav 0.93 would now no longer detect many once prevalent viruses for which it only has hexdump signatures. -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] virus in comment in script not detected by 0.93
Hi, Some viruses eg WScr.Unsafe.D for which a hexdump signature exists and which used to be detected by 0.91.2 are no longer detected by 0.93 . eg WScr.Unsafe.D arrives in html file embedded in a "HTML comment tag" enclosed by HTML script tags. eg <!-- virus script --> When clamav processes this it creates 2 files notags.html and nocomments.html and appears to only scan these files. It doesn't appear to scan the unprocessed html file. Any file that looks like it contains html appears to be processed into notags and nocomments before any scanning is done. When notags.html is created the embedded virus is treated as a comment tag and removed. When nocomment.html is created the virus is not treated as a comment tag, but all the whitespace is removed and the text lowercased which would cause matching to a hexdump signature, if it were done, to fail. eg part of the script text from WScr.Unsafe.D var mye=new Enumerator becomes: varmye=newenumerator in the nocomment.html file. My question is: Are all files matched, unaltered, against the entire database or are html files always preprocessed into nocomment.html and notags.html and only these files scanned ? If so, are these files only scanned against a subset of the signatures and not the hexdump signatures ? What has changed in 0.93 to cause WScr.Unsafe.D (and presumeably other viuses) to no longer be detected and is there a fix for this ? -- David Shrimpton ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] viruses in comments in scripts not detected by 0.93
Thanks, This quote from the bugzilla posts is quite amusing: "As for the official clamav signatures, please stand assured that when the new code will be in the stable release, all the broken signatures will be properly fixed." -- David Shrimpton On Fri, 2 May 2008, Steve Basford wrote: > > Take a peek here... > > https://wwws.clamav.net/bugzilla/show_bug.cgi?id=780 > ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] viruses in comments in scripts not detected by 0.93
A signature that detects WScr.Unsafe.D under 0.93 is below
HTML.WScr.Unsafe.D:3:*:22293b7362663d666c2e737562666f6c646572733b666f72287661726d79653d6e6577656e756d657261746f7228736266293b216d79652e6174656e6428293b6d79652e6d6f76656e6578742829296964643d6d79652e6974656d28293b6964733d6e65
create by:
0. Get main.db from main.cvd with sigtool --unpack
grep WScr.Unsafe.D in main.db
remove the label leaving only the hex
1. reverse the hex to get the partial script text eg
cat the hex | perl -ne 'chomp;print pack("H*",$_)'
2. wrap the script text with <!-- -->
to convince sigtool it is html
(should also work without the SCRIPT or comment)
3. normalize the html with
sigtool --html-normalise
4. remove tags (ie <!-- -->
from nocomment.html
5. create a hex signature from the result
eg sigtool --hex-dump
6. create a .ndb database file by adding a name, type and offset
(use sigtool --list to make sure the name you choose doesn't clash
with an existing one. Also choose a name you think won't clash with
a future clamav signature name )
On Fri, 2 May 2008, David Shrimpton wrote:
> Thanks,
>
> This quote from the bugzilla posts is quite amusing:
>
> "As for the official clamav signatures, please stand assured that when the new
> code will be in the stable release, all the broken signatures will be properly
> fixed."
>
>
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] viruses in comments in scripts not detected by 0.93
Sample Submitted. thanks David > > Please submit a sample at http://www.clamav.org/sendvirus/ > ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] False Positive W97M.Static
Hi,
I'm getting a run of what appear to be false positives
on W97M.Static in word docs, since this signature was updated on 18/10/2008.
We get no hits with sophos or any other virus scanner we try
on the .doc file.
The current signature extracted from daily.ndb from daily.cld is:
W97M.Static:2:*:4f7074696f6e73{-12}566972757350726f74656374696f6e{-29}536176654e6f726d616c50726f6d7074
The 3 hex runs decode as follows:
echo 4f7074696f6e73 | perl -ne 'chomp ;print pack("H*",$_),"\n"'
Options
echo 566972757350726f74656374696f6e | perl -ne 'chomp ;print pack("H*",$_),"\n"'
VirusProtection
echo 536176654e6f726d616c50726f6d7074 | perl -ne 'chomp ;print
pack("H*",$_),"\n"'
SaveNormalPrompt
Surely this signature is incorrect .
Is there a way of disabling it ?
--
David Shrimpton Systems Programmer
Software Infrastructure, Information Technology Services
University of Qld 4072 [EMAIL PROTECTED]
Brisbane Australia Phone 61 7 3346 6850
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] False Positive W97M.Static
On Wed, 29 Oct 2008, Noel Jones wrote: > Submit false positives to the clamav team for analysis. > http://www.clamav.net/sendvirus/ Thanks, Was done earlier. > > It appears this has already been fixed - I can't find a > signature named W97M.Static in the current clam database. W97M.Static was removed from database at 200810292051 according to my logs. > > For future reference, whitelisting a specific file or > disabling a specific signature is described in signatures.pdf > section 2.5: > http://www.clamav.net/doc/latest/signatures.pdf > > This suggests creating a local.ign file eg daily.ndb:319:W97M.Static where 319 is line number in daily.ndb of W97M.Static signature. I tried this earlier but it did not work altough clamscan appear to indicate it was loading the file. There is a daily.ign in the daily.cld and I was wondering if I need to pack local.ign into daily.cld somehow. David ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] False Positive W97M.Static
On Wed, 29 Oct 2008, Noel Jones wrote: > David Shrimpton wrote: > > > > This suggests creating a local.ign file eg > > > > daily.ndb:319:W97M.Static > > clamscan appear to indicate it was loading the file. > > Sounds as if you did it correctly, I have no insight into why > it didn't work for you. Only thing I would add is the > local.ign file should have the same owner, group and > permissions as the other clam signature files. > I tried testing with another signature now that W97M.Static is gone . eg main.ndb:2541:W97M.Marker Doesn't work even if local.ign has same permissions and ownership. clamscan appears to load the file still: LibClamAV debug: Loading databases from /opt/mailhub9/clamav/share/clamav LibClamAV debug: /opt/mailhub9/clamav/share/clamav/local.ign loaded LibClamAV debug: in cli_cvdload() David ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [clamav-users] Problem with Max Open desciptor Files limit
I found adding Vbs.Downloader.Generic-6431223-0 to local.ign2 and restarting clamd fixed the problem. This sig turned up in an update at 11:51AM GMT+10 26/1/2018 and problem began a few minutes later clamd run out of file descriptors. I also had to clean out TemporaryDirectory before restarting. Not sure what the exact reason for problem is. There is an EOF-15 in a subsig. Perhaps this causes a performance hit on large text files as end of file must be seeked to and this is sufficient on busy system to cause demand to exceed supply. sigtool --find Vbs.Downloader.Generic-6431223-0 Vbs.Downloader.Generic-6431223-0;Engine:51-255,Target:7;(0|1)&2&3;0:207075626c69632073756220;0:2073756220;EOF-15:203d202272652220656e6420696620;657865202f63207374617274 sigtool --find Vbs.Downloader.Generic-6431223-0 | sigtool --decode-sigs VIRUS NAME: Vbs.Downloader.Generic-6431223-0 TDB: Engine:51-255,Target:7 LOGICAL EXPRESSION: (0|1)&2&3 * SUBSIG ID 0 +-> OFFSET: 0 +-> SIGMOD: NONE +-> DECODED SUBSIGNATURE: public sub * SUBSIG ID 1 +-> OFFSET: 0 +-> SIGMOD: NONE +-> DECODED SUBSIGNATURE: sub * SUBSIG ID 2 +-> OFFSET: EOF-15 +-> SIGMOD: NONE +-> DECODED SUBSIGNATURE: = "re" end if * SUBSIG ID 3 +-> OFFSET: ANY +-> SIGMOD: NONE +-> DECODED SUBSIGNATURE: exe /c start David Shrimpton From: clamav-users on behalf of Carlos García Gómez Sent: Saturday, January 27, 2018 12:03:32 AM To: clamav-users@lists.clamav.net Subject: [clamav-users] Problem with Max Open desciptor Files limit Hi, We have a problem with ClamAV due to Max Open desciptor Files limit It’s seems like delete temp files are not freeded When the soft is reached the clamav proccess responses with an ERROR THe problem has begined Today with 0.99.2 clamav version We have updated to the last release 0.99.3 but then problem again be here. [root@mx2 tmp]# ps -ef |grep clamav clamav 22927 1 0 13:50 ?00:00:00 /home/vmail/antivirus/clamav/bin/freshclam -d root 23128 21677 0 15:01 pts/100:00:00 grep clamav clamav 23137 1 2 13:51 ?00:01:39 /home/vmail/antivirus/clamav/sbin/clamd [root@mx2 tmp]# lsof -p 23137 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME clamd 23137 clamav cwdDIR8,1 4096 2 / clamd 23137 clamav rtdDIR8,1 4096 2 / clamd 23137 clamav txtREG8,2 3308231507346 /home/vmail/antivirus/clamav-0.99.3/sbin/clamd clamd 23137 clamav 11u REG8,2 461540613 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-40e1c3eb5c91506cd8029a626d44e430.tmp (deleted) clamd 23137 clamav 12u REG8,2 1191540264 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-6191bbf55622fa150f6a562fedaa96bf.tmp (deleted) clamd 23137 clamav 13u REG8,2 1191540266 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-d23444b929c3e8f70b245d0f7df9c64e.tmp (deleted) clamd 23137 clamav 14u REG8,2 361540265 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-0323a84d6821a592bccefde5a36c0bb4.tmp (deleted) clamd 23137 clamav 15u REG8,2 47931540268 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-a08b30fcf5ca4cbc35089753a49b688f.tmp (deleted) clamd 23137 clamav 16u REG8,2 47931540267 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-8fa41cdf16f7e03e3fef00fa7faefe66.tmp (deleted) clamd 23137 clamav 17u REG8,2 581540270 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-8106966405936ecc207ceb37377b2be5.tmp (deleted) clamd 23137 clamav 18u REG8,2 1831540272 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-6f395db61ea80440bbcdcccf8c1fd87e.tmp (deleted) clamd 23137 clamav 19u REG8,2 2931540273 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-4d454dfbedfa70c192000a2cc021a0e9.tmp (deleted) clamd 23137 clamav 20u REG8,2 1831540271 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-d7b9350895ea3c7c16a95810da93cbcd.tmp (deleted) clamd 23137 clamav 21u REG8,2 31371540274 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-61ead91328b1a1fb2eed66e0092fab37.tmp (deleted) clamd 23137 clamav 22u REG8,2 31371540276 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-ea8e77c7746f4e20efa08dd714e3bab1.tmp (deleted) clamd 23137 clamav 23u REG8,2 421540275 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-6dc27ea80d232f5cf3354a7a3c8ec58d.tmp (deleted) clamd 23137 clamav 24u REG8,2 441540277 /home/vmail/antivirus/clamav-0.99.3/var/tmp/clamav-fee6d1b3d366eda4e15f5ff8416bc606.tmp (deleted) clamd 23137 clamav 25u REG8,2 677
[clamav-users] Upgrade to 0.100.0 disables CL_TYPE_ZIP regex signatures for Office files
Upgrade of clamav to 0.100.0 disables Container CL_TYPE_ZIP regex signatures for Office 2007+ files. Eg signatures attempting to match a contained file of an Office zip. Prior to 0.100.0 the Container for Office files was classified only as CL_TYPE_ZIP. With 0.100.0 the Container is classified as both (CL_TYPE_OOXML_WORD or CL_TYPE_OOXML_XL or CL_TYPE_OOXML_PPT) and CL_TYPE_ZIP. Existing signatures pre 0.100.0 would all be CL_TYPE_ZIP. With 0.100.0 it appears regexes are pooled as one regardless of Container type and files are first scanned with Container set to one of the CL_TYPE_OOXML_* then same pool of regexes is run with Container set to CL_TYPE_ZIP. But with no hits on a file during the CL_TYPE_OOXML_* run the file md5 is cached as clean so that file is not re-scanned with container set to CL_TYPE_ZIP . Thus the CL_TYPE_OOXML_* run disables the CL_TYPE_ZIP run. The only time a CL_TYPE_ZIP signature may work is with -z and if an CL_TYPE_OOXML_* sig is hit as caching is turned off for the rest of the files during the CL_TYPE_OOXML_* Container run when there is a sig hit. This would also need the file that triggers the CL_TYPE_ZIP to be the same file as that triggering the CL_TYPE_OOXML_* sig or to be a file scanned after that file (so the file is not in the clean cache). --disable-cache for clamscan or 'DisableCache yes' in clamd.conf fixes the problem. The fix would be to not cache files as clean until all Container types are tested. Same problem I expect would apply in other multiple Container situations. The problem might impact a large pool of existing signatures as well as new ones using CL_TYPE_ZIP and not one of the CL_TYPE_OOXML_*. Another unrelated problem is that Flash used to be container CL_TYPE_ZIP but are now CL_TYPE_SWF so some sigs for flash using CL_TYPE_ZIP may no longer work. David Shrimpton ___ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [Clamav-users] Anyone else having problems with the AU mirror for updates?
Hi, Re [Clamav-users] Anyone else having problems with the AU mirror for updates? We keep getting "Mirrors are not fully synchronized. Please try again later" This is because DNS version of daily.cvd is 2025 : dig TXT current.cvd.clamav.net | grep ^current current.cvd.clamav.net. 3m9s IN TXT "0.88.4:40:2025:1160609341:1" but the 2 Australian mirrors that are contactable have older (prehistoric in case of pacific) versions of daily.cvd than this: GET "http://clamav.mirror.pacific.net.au/daily.cvd"; > /tmp/daily.cvd.pacific sigtool -i /tmp/daily.cvd.pacific Build time: 17 Sep 2006 12-11 + Version: 1889 # of signatures: 5576 GET "http://clamavdb.planetmirror.com/daily.cvd"; > /tmp/daily.cvd.planet sigtool -i /tmp/daily.cvd.planet Build time: 10 Oct 2006 18-11 + Version: 2020 # of signatures: 8420 The other AU mirror clamav.island.net.au responds with "daily.cvd was not found" A workaround for this is to comment out DatabaseMirror db.au.clamav.net DatabaseMirror database.clamav.net in freshclam.conf and add a DatabaseMirror line pointing to a mirror host that has an uptodate daily.cvd -- David Shrimpton Systems Programmer Software Infrastructure, Information Technology Services University of Qld 4072 Brisbane Australia ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] freshclam not updating daily.cvd
On Tue, 17 Oct 2006, ash wrote: Hi, I have been using ClamAV with no problems for the last 3 years but have just returned from 1 weeks break to discover my hourly ClamAV updates seem to have stopped on Oct11 around 0800 GMT DNSDatabaseInfo current.cvd.clamav.net DatabaseMirror db.au.clamav.net DatabaseMirror database.clamav.net I have tried pointing the DatabaseMirror to US,UK or JP and they all fail. On Mon 17/10/2006 all the reachable au mirrors had out of date daily.cvd when compared to current version in DNS. ( dig txt current.cvd.clamav.net ) This was causing "Mirrors not synchronized" errors if DatabaseMirror was set to db.au.clamav.net. I notice db.au.clamav.net was sometime after made a CNAME to db.us.rr.clamav.net. Using DatabaseMirror db.au.clamav.net should now be successful as a result of this change. (clamavdb.planetmirror.com which was one of db.au.clamav.net is now uptodate again but may be the only useable au mirror if db.au.clamav.net is restored to former settings.) See earlier postings on list re above. Setting DatabaseMirror to db.us.clamav.net (or uk or jp) should work. What happens when you try wget http://db.us.clamav.net (or uk or jp) ? Also did you comment out all the other DatabaseMirror entries in freshclam.conf when trying db.us.clamav.net etc ? Is DNSDatabaseInfo set to current.cvd.clamav.net in freshclam.conf ? Are proxy settings correct in freshclam.conf (and for wget)? Try running freshclam without --quiet to look for errors. Incidently the error below may mean you need to comment out the TCP entries for clamd in clamd.conf if clamd is listening on unix socket or vice versa and check your clamd is actually starting. Thats if you are using clamd . If not you may want to comment NotifyClamd in freshclam.conf. Oct 11 07:51:29 pow1 freshclam[29134]: ERROR: Clamd was NOT notified: Both socket types (TCP and local) declared in /usr/local/etc/clamd.conf -- David Shrimpton Systems Programmer Software Infrastructure, Information Technology Services University of Qld 4072 Brisbane Australia ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] freshclam not updating daily.cvd
On Tue, 17 Oct 2006, ash wrote: I did read the previous postings, but I feel my problem is different, almost as if I have been banned (which I don't believe I should have been) and the apache config been set to deny my IP , but I haven't been able to find any documented method of getting this checked out. > > What happens when you try wget http://db.us.clamav.net (or uk or jp) ? As mentioned, http connections to sites returned when querying the various country entries failed. A workaround would be to set DatabaseMirror clamavdb.planetmirror.com in freschclam.conf. It sounds like the problem is more an underlying network connectivity problem from your host to port 80 on many IPs but not to clamavdb.planetmirror.com. Perhaps your ISP requires traffic to most sites to go through a proxy but traffic to clamavdb.planetmirror.com is considered "local" and allowed directly. -- David Shrimpton Systems Programmer Software Infrastructure, Information Technology Services University of Qld 4072 Brisbane Australia ___ http://lurker.clamav.net/list/clamav-users.html
[clamav-users] Malformed pattern daily.ldb version 25410
sigtool --list=/path/daily.cld is returning: ERROR: listdb: Error listing database /tmp/clamav-0348baa027819612194d4bd1d7aed9d0.tmp/daily.ldb ERROR: listdb: Malformed pattern line 52912 (file /tmp/clamav-0348baa027819612194d4bd1d7aed9d0.tmp/daily.ldb) extracting daily.ldb with sigtool --unpack-current=daily and finding line 52912 with sed shows: sed -ne '52912p' daily.ldb Doc.Trojan.Agent-6923124-0;Engine:51-255,Target:2;0&1&2&3&4&5&6&7;424f617547596379616f6b795a69614d5563795375646167496245745968203d2053776974636828424f617547596379616f6b795a69614d5563795375646167496245745968203c20312c20227a4f614f706962796175434966416a6968416469776f7c20424f617547596379616f6b795a69614d5563795375646167496245745968203e20322c2022446957415657596b59466578222c20424f617547596379616f6b795a69614d5563795375646167496245745968203c20352c2043566566595265535576596e4f44416a4879526f58202b2022716f674f5179565645485547656d45662229;4759487a6174695a4150414a79724f774f76554661534174495a6167596b654d41647962416a6a5973203d20537769746368284759487a6174695a4150414a79724f774f76554661534174495a6167596b654d41647962416a6a5973203c20342c20224c4978756741616543497844494e45222c204759487a6174695a4150414a79724f774f76554661534174495a6167596b654d41647962416a6a5973203e20322c202248454778414e6954614a222c204759487a6174695a4150414a79724f774f76554661534174495a6167596b654d41647962416a6a5973203c20342c2074694655644f6 3794e6942757645436b596a61506168202b2022425967754e45744f776f546f4d6543692229;48594455775557555055775574796165685574203d20435661722835202b2038202b203329;486f757220226c614e5567657a4172615a6943497261636922202b202268686f6875776b494122;4c4f534f4e596261516f62203d20435661722839202b2035202b20313029;6945786d6f545577555643614c597679584f62455441706567754b59524f78203d2032;72697a6f76414a41486f68654665487570754265764944656375454379203d2038;7a6948557141444976616d5969557759786157654e6947556f4741446157614475526f56754865203d2039 cut and paste has added a line break above but this sig looks OK on first glance sigtool --find-sigs Doc.Trojan.Agent-6923124-0 | sigtool --decode-sigs shows sensible output for the above signature, so I am not sure this is the exact one causing the sigtool error. The problem started from database version 25410 upgrade , so it appears one (or more) sigs are Malformed in 25410 ClamAV 0.100.2/25410/Fri Apr 5 17:58:26 2019 David Shrimpton ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Malformed pattern daily.ldb version 25410
I can reproduce the Malformed pattern problem with a file with just the one signature: Xls.Downloader.Powload-6923120-0 which is an even longer one . This is 4 signatures before Doc.Trojan.Agent-6923124-0 in daily.ldb sigtool reports the wrong line numbering eg with a file with just Xls.Downloader.Powload-6923120-0 it reports the problem as being on line 2. It seems to be 4 lines out when reporting on the whole daily.ldb again sigtool --find Xls.Downloader.Powload-6923120-0 | sigtool --decode-sigs doesn't show a problem. clamscan --debug -d file_with_just_the_sig_above.ldb somefile doesn't show a problem. Xls.Downloader.Powload-6923120-0 turned up in daily 25410 which was when the problem started Maybe sigtool --list can't handle long signatures in ClamAV 0.100.2 There does seem a pointlessness to signatures based upon exact variable names etc that are obfuscated and likely will vary with each sample. A regex signature to get any variable name would be better. David Shrimpton From: clamav-users on behalf of Arnaud Jacques Sent: Saturday, April 6, 2019 12:27 AM To: clamav-users@lists.clamav.net Subject: Re: [clamav-users] Malformed pattern daily.ldb version 25410 Hello, > sigtool --find-sigs Doc.Trojan.Agent-6923124-0 | sigtool --decode-sigs I don't understand why this signature is so long, and why it is based on always changing variables. ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Malformed pattern daily.ldb version 25410
This appears to be a different problem than the sigtool --list problem on daily I think it may be a problem with integrity of downloaded file and not an incompatibility of that file with clamav version or something wrong with a sig in the file. Testing the main.cvd file may be good first step. It appears to be reported that the main.cvd downloaded is corrupted: >> Fri Apr 5 14:17:59 2019 -> *Trying to download >>http://db.US.clamav.net/main.cvd (IP: 104.16.219.84) >> Fri Apr 5 14:18:12 2019 -> Downloading main.cvd [100%] >> Fri Apr 5 14:18:12 2019 -> ^[LibClamAV] cli_cvdload: Corrupted CVD header >>Fri Apr 5 14:18:12 2019 -> !Verification: Malformed database Some things that may help debug: # download the main.cvd manually eg if have unix wget or curl wget http://db.US.clamav.net/main.cvd # check the size , is it zero length or improbably small ? Did wget report errors. # Test main.cvd with sigtool look for errors or sensible output as below. sigtool --info main.cvd File: main.cvd Build time: 07 Jun 2017 17:38 -0400 Version: 58 Signatures: 4566249 Functionality level: 60 Builder: sigmgr MD5: 57462fd73f1cfdb356b9dca66da2b732 Digital signature: KWRdhTG+Own6ohh0wn5+vqg1d8ULKCxxxQeKuSA155B3ijxBKgf+bV3IXPcmZrIBUDn1xi8FmyvB63UieykwN/Avq5mTjHIVO8zFnC7wVF7dhdcEYn9Nt+Pmk/HXXx0voylYkidvgZmrxI8jx4a/Re6n3hHQJoCZrkHM15GER8j Verification OK. # examine main.cvd with binary editor eg xxd main.cvd should have a 512 byte header then a gzipped tar file containing the database files and a main.info The header has : separated fields . About the 4th field should look like an md5sum like above 57462fd73f1cfdb356b9dca66da2b732. This is the md5sum of the gz that follows the header. The header seems to end with space padding. about the 5th field should look like a the value of Digital signature: above. You should see the Builder field eg sigmgr above. I think sigtool has verified the signature above. If file has been altered then verification failure might be reported. eg is db.US.clamav.net the real clamav mirror site or an imposter.WARNING if the file isn't verifying it may be malicious eg a compression bomb , a malicious archive , an exploit against some of the tools below and it might be dangerous to run some of the tools below against it. Remember only http was used not https to get the file so site might be bogus and file could be anything. # Extract gz from main.cvd eg with ddand calling the gz main.gz ie strip off the 512 byte header at start dd if=main.cvd of=main.gz skip=1 bs=512 # test the gz gunzip -t main.gz # extract gz (it will be large eg 3 times size of the gz on my example) gunzip main.gz # this should give a tar file called main for my example # test the tar file (my tar reports improbable dates) tar tvf main -- 0/0 17992 1970-01-01 10:00 COPYING -- 0/01060 1970-01-01 10:00 main.info -- 0/0 3649543 1970-01-01 10:00 main.hdb -- 0/024806499 1970-01-01 10:00 main.hsb etc # try extracting main.info and some of the database files tar xf main main.info # main.info contains sha256sum for each database file. # test the extracted database files have same 256 sum eg from main.info main.sfp:87:ded8b3b340e2da8415f1409959abb54725afad137a66e938080c7c95a9413128 sha256sum main.sfp ded8b3b340e2da8415f1409959abb54725afad137a66e938080c7c95a9413128 main.sfp If a sha256 doesn't match that database file is corrupted or altered or main.sfp is wrong You could look at a database file eg main.ndb with text editor or xxd ans should see lines looking like clamav signatures.Try 'file main.ndb' first to make sure is a text file . Corrupted file might be binary and trash your terminal or editor. If the main.cvd appears to be OK then maybe the problem is it isn't compatible with clamav version. You'd need to look at things like version and functionality level from the sigtool output and decide if this is what is expected for a current main.cvd.If it is then I guess that incompatible main.cvd or some faulty sig in main.cvd might be the issue. >> Is there a way to go back to daily-25409, for example, other than using backups? I looked at the FAQ, If the main.cvd is corrupted I doubt freshclam would replace existing database files and sigtool --versionmay show you are already on daily-25409 or earlier. Note if running freshclam --datadir I think any settings other than database location from freshclam.conf would apply. So if you were just trying to get an example main.cvd you might see side effects you don't want like freshclam writing to a configured log file or trying to HUP your clamd or writing a mirrors.dat David Shrimpton ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help
Re: [clamav-users] Malformed pattern daily.ldb version 25410
Is the failing machine running out of memory running engine = cl_engine_new() David Shrimpton ___ clamav-users mailing list clamav-users@lists.clamav.net https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
