<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 11, 2015 at 12:50 AM, yhu2 <span dir="ltr"><<a href="mailto:yadi.hu@windriver.com" target="_blank">yadi.hu@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">whether or not  CVE-2014-8242 affects rsync? any commnet would be appreciated!!<br></blockquote><div><br></div><div>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:</div><div><br></div><div><a href="https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869">https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869</a><br></div><div><br></div><div>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.</div><div><br></div><div>I also plan to add a new checksum method, but that shouldn't be needed for thwarting this issue.</div><div><br></div><div><div><div class="gmail_signature">..wayne..</div></div></div></div></div></div>