Hi there,
On Mon, 21 Mar 2022, Kris Deugau wrote:
TBH I'd prefer if Clam *did* continue, just skipping malformed rules
(and also whinging loudly in the log).
I could live with that if it didn't *also* crash.
Either would be better than just exiting (it's not a hard *crash*,
it's "just" refusing to load a file with a malformed signature -
including things like entirely blank lines).
No, Kris. It *is* a hard crash - and it doesn't happen when it loads
the rules, it happens when it tries to scan something *after* loading
a Yara file which contains a bad rule. Not neccessarily any bad rule,
just one with any of a number of different kinds of badness which I've
found to be problematic. But as I said in my mail things may well be
different as a result of Micah's August PR. TBH I really haven't been
inclined for quite some time to crash clamd on purpose. :)
Strictly speaking, four characters (the {} delimiters for hex
strings). To my reading this is part of the upstream Yara spec, and
I'd be wary of extending this particular bit without at least
requiring some blatant, obvious flag in any such rule to clearly
indicate that it's not stock Yara syntax.
Agreed it needs some thought. Maybe a different filename extension?
Not that I'm a great fan of systems which rely on filename extensions
to control the behaviour of executables. Or maybe persuade the folks
upstream to make some enhancements? That would be best, I think, but
it presupposes that the ClamAV Yara engine catches up - which IMHO is
a necessity in any case.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
[email protected]
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
