On Tue, 9 Feb 2016, Steven Morgan wrote: > David, > > I've opened https://bugzilla.clamav.net/show_bug.cgi?id=11498 to > investigate and track the issue. Plz sign up for an account at > https://bugzilla.clamav.net and send me the user id and I will CC you on > the bug. Once that is done, I will need for you to attach your signatures > and sample files to the bug report. >
Thanks. One bug appears to be that if ScanOLE2 is yes for clamdscan or --scan-ole2=yes for clamscan the -z option only applies to the decompressed macro files if a hit is obtained on a decompressed macro. The other files in the OLE2 are not scanned and the container itself is not scanned otherwise a signature against these should also hit. If there is no match on a compressed macro then -z checks for matches against the container definitely and possibly the contained other files. I can't work out if scan-ole2=yes causes all files in the container to be scanned or not. It doesn't turn off scanning of the container itself. But a sig that matches the container may also match a file in the container unless there is uncompression in extracting the file. Its unclear what signatures might be applied to files within and OLE2 container. eg would a sig of type 2 be run on an image in an OLE2 or only on another OLE2 inside an OLE2. If OLE2BlockMacros is yes for clamdscan, Heuristics.OLE2.ContainsMacros also counts as a hit and -z only applies to the decompressed macros. A signature that hits on a decompressed macro is needed to exercise the bug. Most or maybe no official or unofficial signatures are written against decompressed macros. Alternatively clamdscan with OLE2BlockMacros yes will exercise the bug. The bug is masked when running clamscan --scan-ole2=yes as there is no OLE2BlockMacros option so there is no hit on Heuristics.OLE2.ContainsMacros with clamscan and a signature that hits on a decompressed macro is needed to exercise the -z bug. There are maybe no official or unofficial signatures that match decompressed macros so no one else can reproduce the bug unless they have clamdscan and OLE2BlockMacros yes or a local signature file with signatures to match decompressed macros. Removal of the local database that contains the matched signature makes the problem go away for clamscan but not for clamdscan if OLE2BlockMacros is yes (as Heuristics.OLE2.ContainsMacros is hit). The problem was not that the local database signature was no good. it was quite the opposite, the local signature was good and got hit and exercised the -z bug. Some other observations: If OLE2BlockMacros is yes and ScanOLE2 yes, you never see any hits on the Sanesecurity badmacros or other databases , because clamd exits upon the first match and with ScanOLE2 yes , the decompressed macro processing is run before processing on the ole2 container with uncompressed macros and the Heuristics.OLE2.ContainsMacros hit short circuits any other hits. Or, a signature that matches uncompressed macros matches first (if HeuristicScanPrecedence is no). Unless using -z , all signatures are equal , the first hit wins and no other sigs are tried. And the order signatures are run in is not configurable. So in a mix of official , unofficial and locally written unofficial sigs , a sig of any of the 3 types might match first. This implies you shouldn't treat signature hits differently based upon whether they are official , unofficial or local. eg its no good trying to apply a different processing based upon a signature name eg drop local unofficial hits but just log other unofficial hits because there might be a match on each and you don't know which match will be first and you might just log something that you wanted to be dropped. This means if you don't trust unofficial sigs but trust your own you have to not use the unofficial sigs or run 2 clamav installations one with local sigs and one with unofficial sigs and apply different behaviour to the results from each. I am not sure if you can remove the official sigs from a clamd the way you can with clamscan --database=your_own_database. The HeuristicScanPrecedence no with ScanOLE2 yes and OLE2BlockMacros yes is also misleading as the precedence is only applying to hits on the uncompressed macros versus Heuristics.OLE2.ContainsMacros. Heuristics.OLE2.ContainsMacros has precedence over all other signatures in this situation including all the badmacro etc. ScanOLE2 yes itself is misleading and doesn't imply turning on or off scanning of OLE2 , it only implies turning on special processing of OLE2 ie extraction of files in the OLE2 container and decompression of macros. Files of type OLE2 will always be scanned against signatures of type:2 or 0 regardless of ScanOLE2. Its not clear if ScanOLE2 yes causes all files within OLE2 container to be scanned and what sig types might apply to those files when scanning. eg are files in a container tested 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
