Bugzilla – Bug 12095
Some YARA rules malfunction
Last modified: 2021-08-19 14:24:11 EDT
Created attachment 7413 [details] Example of malware file that should match The following YARA rule does not trigger $a and $c when used with clamav https://github.com/Yara-Rules/rules/blob/master/Webshells/WShell_PHP_Anuna.yar It works fine in yara directly, but the pcre lib in clamav does not trigger the rule: clamav: LibClamAV debug: matcher_run: performing regex matching on full map: 0+5108(5108) >= 5108 LibClamAV debug: cli_pcre_scanbuf: checking 7374756c747a676574737265676578; running regex /<\?php \$[a-z]+ = '/ LibClamAV debug: cli_pcre_scanbuf: triggered 7374756c747a676574737265676578; running regex /<\?php \$[a-z]+ = '/ LibClamAV debug: LibClamAV debug: cli_pcre_report: PCRE Execution Report: LibClamAV debug: cli_pcre_report: running regex /<\?php \$[a-z]+ = '/ returns -1 LibClamAV debug: cli_pcre_report: no match found LibClamAV debug: cli_pcre_report: PCRE Execution Report End LibClamAV debug: LibClamAV debug: cli_pcre_scanbuf: checking 7374756c747a676574737265676578; running regex /\$[a-z]+=explode\(chr\(\([0-9]+[-+][0-9]+\)\)/ LibClamAV debug: cli_pcre_scanbuf: triggered 7374756c747a676574737265676578; running regex /\$[a-z]+=explode\(chr\(\([0-9]+[-+][0-9]+\)\)/ LibClamAV debug: LibClamAV debug: cli_pcre_report: PCRE Execution Report: LibClamAV debug: cli_pcre_report: running regex /\$[a-z]+=explode\(chr\(\([0-9]+[-+][0-9]+\)\)/ returns 1 LibClamAV debug: cli_pcre_report: 0: 246b7361766b70663d6578706c6f64652863687228283631322d3439322929 LibClamAV debug: cli_pcre_report: no named substrings LibClamAV debug: cli_pcre_report: PCRE Execution Report End LibClamAV debug: LibClamAV debug: cli_pcre_scanbuf: located regex match @ 2819 LibClamAV debug: cli_pcre_scanbuf: checking 7374756c747a676574737265676578; running regex /\$[a-z]+=\([0-9]+[-+][0-9]+\)/ LibClamAV debug: cli_pcre_scanbuf: triggered 7374756c747a676574737265676578; running regex /\$[a-z]+=\([0-9]+[-+][0-9]+\)/ LibClamAV debug: LibClamAV debug: cli_pcre_report: PCRE Execution Report: LibClamAV debug: cli_pcre_report: running regex /\$[a-z]+=\([0-9]+[-+][0-9]+\)/ returns -1 LibClamAV debug: cli_pcre_report: no match found LibClamAV debug: cli_pcre_report: PCRE Execution Report End LibClamAV debug: LibClamAV debug: cli_pcre_scanbuf: checking 7374756c747a676574737265676578; running regex /if \(!function_exists\('[a-z]+'\)\)/ LibClamAV debug: cli_pcre_scanbuf: triggered 7374756c747a676574737265676578; running regex /if \(!function_exists\('[a-z]+'\)\)/ LibClamAV debug: LibClamAV debug: cli_pcre_report: PCRE Execution Report: LibClamAV debug: cli_pcre_report: running regex /if \(!function_exists\('[a-z]+'\)\)/ returns 1 LibClamAV debug: cli_pcre_report: 0: 696620282166756e6374696f6e5f65786973747328276578616261776f272929 LibClamAV debug: cli_pcre_report: no named substrings LibClamAV debug: cli_pcre_report: PCRE Execution Report End LibClamAV debug: yara: 0x0:$a: <?php $fpvvyhgv = ' 0x17c2:$b: $ksavkpf=explode(chr((612-492)) 0x1e19:$c: $ublkyi=(569-448) 0x1861:$d: if (!function_exists('exabawo')) It seems to be a problem with the escaping? Example file added
Thanks for the report Tom. It should definitely help. We have a similar internal report as well. No ETA on a when we can work on it, but it's on our radar. I'm hopeful that we can fix the behavior, or at a minimum - improve our yara rule signature writing documentation, and improve the error output when a failure to parse a yara rule occurs.
Is this still on the radar? We're still seeing regex-related issues with Yara rules.
(In reply to Connie Quist from comment #2) > Is this still on the radar? We're still seeing regex-related issues with > Yara rules. Hi Connie, Thanks for the reminder. We haven't yet found time to work on this or other issues identified with ClamAV's admittedly dated and error-prone support for Yara rules. It seems we've seen strong and renewed interest in Yara rule support. We have a lot in our backlog, but I'll do my best to make sure this is considered during project roadmap planning. Respectfully, Micah