Hi all, Sorry that this response come so late that is nearly a necro-thread. Things have been busy.
I've been thinking about some of the thing you all have said. And we've talked about it a bit as a team. We know there is a lot of interest in having better Yara support, not only because it is easier to use but because there is a wealth of Yara rules out there. Support for features from the 'pe' module is something that I believe is particularly desirable. The KDL-based format that I'm brainstorming does indeed look very similar to Yara. I hope it's not too close. If we do this, we won't want the new language to be so close to Yara that people get confused between them. I certainly wouldn't want to have ours be the Yara format but missing some features and with other extra features. That would be very confusing. We have a need to maintain our own signature language to support features unique to ClamAV. Starting with our own new language would let us maintain do that but make it easier for new analysts to train up on ClamAV. Another reason for tossing the baby with the bathwater is that the clamav's existing signature formats are difficult to extend. I say formats because the format for different types of ClamAV signatures aren't all the same. We have a bunch: https://docs.clamav.net/manual/Signatures.html#database-formats I'm hoping we can unify them. Ged's comment about needing the ability to reference one rule from another rule is something that resonates with us a lot. Being able to have an alert triggered by the combination of some weak indicators would be great. We have something like that in LDB signatures to leverage NDB signatures by way of "macro subsignatures" https://docs.clamav.net/manual/Signatures/LogicalSignatures.html#macro-subsignatures. Macro subsignatures are limited, though. You couldn't, for example, tie together a content-based signature with a certificate revocation signature. What would be every more cool would be to be able to have an archive alert because we found weak indicators in several of the contained files. Like a rule for "a ZIP that contains HTML that alerts with A, and EXE that alerts with B". Indeed, the ability to have severity levels for signatures so we could even have weak indicators is the sort of thing that would be very difficult to add to our existing signature language. It probably wouldn't be so bad for logical signatures but extending this concept to other signature formats like PE section hash signatures, certificate trust and revocation signatures, etc. wouldn't be fun. Ged's idea about using Yara's engine in clamav directly is something that has been brought up time and again. It is possible. My understanding is that the reason ClamAV's yara support isn't done this way is that it would require a second pass over the file with a Yara's pattern matcher, after ClamAV's pattern matcher, and that the performance concern made it make more sense to try and load yara rules into ClamAV's matcher instead. I honestly don't have any numbers to back up this argument. It sounds reasonable, but I'd love to see the numbers. Kris Deugau wrote that he wants embedded comments in signatures, and for ClamAV to ignore empty lines. End-of-line comments probably wouldn't be so bad to add to our current signature language(s). At least for some of the signature types. In-line comments would be more difficult. Ignoring empty lines would be trivial. We'd just have to add it for each of the signature types, which is fine. Honestly I don't know why we haven't done that sooner. We probably couldn't publish anything with empty lines because older versions would choke on it, but at least making it supported for new versions would be nice. We do really want comments in the new signature format though, so seeing that KDL has 3 different types of comments felt really good. Anyways, I've been rambling a bit. I think it's pretty clear that we should work on a new signature language for Clam, whether it's KDL-based or something else. If anyone has any other ideas about it, I'd love to hear them. Like if you have any ideas on a different format, or maybe how the KDL-based one could express dependencies on other signature alerts or whatever. Cheers, Micah Micah Snyder ClamAV Development Talos Cisco Systems, Inc. ________________________________ From: clamav-users <clamav-users-boun...@lists.clamav.net> on behalf of Laurent S. via clamav-users <clamav-users@lists.clamav.net> Sent: Friday, March 4, 2022 5:43 AM To: ClamAV users ML <clamav-users@lists.clamav.net> Cc: Laurent S. <110ef9e3086d8405c2929e34be5b4...@protonmail.ch> Subject: Re: [clamav-users] Minor bug or working as intended? On Wednesday, March 2nd, 2022 at 18:37, Kris Deugau <kdeu...@vianet.ca> wrote: > Kris Deugau wrote: > > > For some types of content, just allowing a plain ASCII string instead of > > > > the hex-coded version of the same would be a big help. Or an > > > > enhancement in the current file formats allowing embedded comments - > > > > I've lost track of how many times I've created something complex, and > > > > had to reconstruct whatever logic I used to create it to make a tweak or > > > > refinement - or just gave up and created a new signature - because > > > > there's no way to document it in-band. Ignoring empty lines - > > > > especially at the end of the signature file! - instead of just claiming > > > > "invalid signature" would ease editing. > We are using a small GUI where you can create (as strings) and view (as strings) all the hundreds of simple .ndb signatures with a database and automatic expiration. But yes, having a similar sig format where you can just input strings... that could be easier to manage. Concerning KDL, I'd really prefer a reliable implementation of YARA for the compatibility with other softwares. There are plenty of yara rules on the web, and it would be awesome to be able to import them easily. Best, Laurent PS: Sorry for replying late
_______________________________________________ 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
