Re: clamav: md5 collision based detection avoidance, Was: Out of bounds read and segfault in xar parser

[klondike <klondike () xiscosoft es>]

DISCLAIMER: I'm stepping in here pointed in by Hanno...

There is also another fun issue with the way caching works (which is
enabled by default) that allows avoiding detection by ClamAV.

This issue was originally reported on 14/05/2016 on
https://bugzilla.clamav.net/show_bug.cgi?id=11570 (which I asked to be
made public) and publicly disclosed after rejections from Defcon, Black
Hat and SEC-T at Bornhack this August.

Attached is a small demo, showing the issue.

Basically both files share the same md5 and use Peter Selinger's code
http://www.mathstat.dal.ca/~selinger/md5collision/ to behave differently
based on the contents of the colliding blocks. The custom signature to
detect evil is:
0eb6e7de97c5db6b584036024e18d43b94df0213c036a8cdf38aba20b07e29bf:14616:Ransomware.gen
Which you may need to place on /var/lib/clamav/

Basically as long as answer is scanned first, ransom will not be
detected, this can be used to bypass detection by amavisd reliably as
attachments are scanned in the order in which they appear.

Keep in mind this is a simple PoC detection of such binaries is easy but
I never made use of cryptography to obfuscate them ;)

Anyways this was not fixed on 0.99.3, I didn't check git but given how
deep in the code the cache's requirement for MD5 delves I wouldn't be
surprised if it wasn't.

I'll publish a longer paper on the article when time allows including
some mitigations that can be used if MD5 is a strong requirement, but
for now this is my contribution to this discussion.

Klondike

El 03/10/17 a las 17:34, Joel Esler escribió:
> Hello — My name is Joel Esler, I’m the Open Source lead here for ClamAV at Cisco.  A few comments here on list inline 
> below:
>
>
>
> > On Oct 1, 2017, at 3:37 AM, Eddie Chapman <eddie () ehuk net> wrote:
> >
> > On 29/09/17 14:09, Hanno Böck wrote:
> > > Meta-level comment:
> > > It seems to me clamav development has mostly stalled. Detection rates
> > > are very low and I'm considering to stop using it for mail filtering.
> > > (also there's of course the whole AV debate, however I never saw
> > > clamav as a security tool, more as something like a spam filter that
> > > prevents crap in my inbox. Still of course it needs to have secure
> > > parsers.)
> > I agree with much of this, and I think you're right that the effectiveness of Clamav in mail filtering contexts can 
> > be debated, though maybe more in terms of the AV debate, as you say.  As a user myself with it deployed filtering 
> > multi-user domains, I agree that detection rates are low.
> Something we were working on.  To be honest, shipping detection in the method that we currently ship detection is not 
> going to scale.  We are thinking about ways to change this.
>
> > However, checking just now on Github I do not get the impression at all that development has stalled. Judging purely 
> > by number of commits, every month there are consistently a very healthy number. But what has stalled is stable 
> > releases; the last one being 0.99.2 on 22nd April 2016, so something is not quite right. But I've seen many open 
> > source/free software projects stalled over the years and definitely Clamav does not, IMO, fit that description (at 
> > least not yet).
>
>
> It’s not dead.  At all.  99.2 as a stable release was released in 2016, yes.  We have been working on 99.3 since, and 
> are planning 99.4 and 99.5 now.  99.3 has been in beta for a couple months now, and the fix for this issue has been 
> in git since the date mentioned earlier in the thread.  It’s also obviously in 99.3.
>
> --
> Joel Esler
> Manager
> Talos Group
> http://www.talosintelligence.com

Attachment: answer
Description:

Attachment: ransom
Description:

Attachment: signature.asc
Description: OpenPGP digital signature