Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Sep 2014 10:32:40 +0400
From: Loganaden Velvindron <>
Subject: Re: Re: [CVE Requests] rsync and librsync collisions

On Tue, Sep 16, 2014 at 9:47 AM, Michael Samuel <> wrote:
> On 13 September 2014 04:39,  <> wrote:
>> The short answer is that we neither agree nor disagree at present; we
>> think that either any required CVE assignment can be made by us after
>> a full public disclosure, or any required CVE assignment can be made
>> by a different CNA now.
> The bug is publicly disclosed.  The exploit isn't (and I believe list rules
> dictate that I can't post exploits here).
>> MITRE is not currently interested in receiving an advance copy of the
>> full public disclosure or any related PoC information from anyone.
>> We'll see whether the CNA process above can work.
> I don't care who assigns the CVE, but it would be nice to be able to link
> the tickets for this together somehow.
> An experimental branch of librsync that uses blake2 is available here:
> Dropbox have responded that they have fixed this bug independently, but
> have not pushed anything out to their forked librsync github repo.

Has Dropbox made a public statement regarding this ?

> I have not heard further from the rsync maintainer.  I will publicly release
> colliding blocks and construction details soon, so if you use rsync on
> untrusted files, consider using the -W option to avoid a DoS.

Has the rsync maintainer acknowledged the issue publicly ?

> Regards,
>   Michael

This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ