The e-mail trick is just an example, but the scenario is still valid. Consider an alternative scenario where an attacker is able to upload files to your server (perhaps jpg, gif, etc) via a web application or FTP server. Or perhaps, if someone were able to contribute source or a tarball by uploading it to your server, this would be an issue.
Also, if a Postfix/etc server is misconfigured (or one were to be set up by the attacker) they would have far more control of the SMTP headers than you may realize. This would give them the ability to reliably predict the rest of the headers stored on disk. Especially if they've been able to see the headers from an e-mail you've previously sent through the same network. D On Sun, Feb 7, 2010 at 10:44 AM, erik quanstrom <quans...@quanstro.net> wrote: >> OK, lets assume that the attacker has the most powerful attack >> against a hash available in which he can construct a garbage >> block of data (perhaps with some control of its content) that >> hashes to a value of his choosing. Now he predicts some data >> that is likely to be written to your filesystem soon (say a >> brand knew pull update that you havent pulled yet), makes >> an email that has a data block in it that collides with that >> block, sends that email to you. Your filesystem stores it. >> Later you do a pull and venti notices that you don't have to >> store one of the blocks because it already has a block stored >> with that same hash. Now one of your files is corrupt. > > small problems with this: > > 1. the sender can't control email headers. many > transfer agents add a random transfer-id which > would confound this attack. > > 2. if the rcpt uses mbox format, the sender can't > control how your message is fit into venti blocks. > the sender would need to control the entire > mail box. > > 3. http://en.wikipedia.org/wiki/SHA_hash_functions > says that there have been no SHA1 collisions found. > > - erik > >
