Hi,everyone here: whether or not CVE-2014-8242 affects rsync? any commnet would be appreciated!! Yadi
On Mon, May 11, 2015 at 12:50 AM, yhu2 <yadi.hu at windriver.com> wrote:> whether or not CVE-2014-8242 affects rsync? any commnet would be > appreciated!! >Yes. It would be extremely hard for someone to trigger that via indirect means (such as inserting DB data and managing to match a checksum record boundary in contents somehow). So, it has a very small potential to cause a particular file to fail to transfer with a bad file-checksum. I've made a simple change that should avoid the issue: https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869 With the seed value moved to the right spot, an attacker can't craft a false-match record that works for any transfer. And the truly paranoid can use the --checksum-seed=NUM option with their own random-for-each-transfer value, should they think that rsync's seed method is too simplistic. I also plan to add a new checksum method, but that shouldn't be needed for thwarting this issue. ..wayne.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20150511/1ea3a626/attachment.html>
Thanks great!!!. Yadi On 05/12/2015 05:19 AM, Wayne Davison wrote:> On Mon, May 11, 2015 at 12:50 AM, yhu2 <yadi.hu at windriver.com > <mailto:yadi.hu at windriver.com>> wrote: > > whether or not CVE-2014-8242 affects rsync? any commnet would be > appreciated!! > > > Yes. It would be extremely hard for someone to trigger that via > indirect means (such as inserting DB data and managing to match a > checksum record boundary in contents somehow). So, it has a very > small potential to cause a particular file to fail to transfer with a > bad file-checksum. I've made a simple change that should avoid the issue: > > https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869 > > With the seed value moved to the right spot, an attacker can't craft a > false-match record that works for any transfer. And the truly > paranoid can use the --checksum-seed=NUM option with their own > random-for-each-transfer value, should they think that rsync's seed > method is too simplistic. > > I also plan to add a new checksum method, but that shouldn't be needed > for thwarting this issue. > > ..wayne..-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20150512/3d22cfd8/attachment.html>
wayne. Thanks your explanation, how about MD4 (rsync protocal <30)? any comment would be appreciated!! Thanks again. Yadi On 05/12/2015 05:19 AM, Wayne Davison wrote:> On Mon, May 11, 2015 at 12:50 AM, yhu2 <yadi.hu at windriver.com > <mailto:yadi.hu at windriver.com>> wrote: > > whether or not CVE-2014-8242 affects rsync? any commnet would be > appreciated!! > > > Yes. It would be extremely hard for someone to trigger that via > indirect means (such as inserting DB data and managing to match a > checksum record boundary in contents somehow). So, it has a very > small potential to cause a particular file to fail to transfer with a > bad file-checksum. I've made a simple change that should avoid the issue: > > https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869 > > With the seed value moved to the right spot, an attacker can't craft a > false-match record that works for any transfer. And the truly > paranoid can use the --checksum-seed=NUM option with their own > random-for-each-transfer value, should they think that rsync's seed > method is too simplistic. > > I also plan to add a new checksum method, but that shouldn't be needed > for thwarting this issue. > > ..wayne..-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20150512/b13fba3d/attachment.html>