[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <071bacf8-a762-f4f1-39d8-f2e286413ea6@xiscosoft.es>
Date: Tue, 3 Oct 2017 20:54:50 +0200
From: klondike <klondike@...cosoft.es>
To: oss-security@...ts.openwall.com
Subject: Re: clamav: md5 collision based detection avoidance,
Was: Out of bounds read and segfault in xar parser
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@...k.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
Download attachment "answer" of type "application/octet-stream" (14616 bytes)
Download attachment "ransom" of type "application/octet-stream" (14616 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
