| |||||||||||||
Hunting for RootkitsHunting for RootkitsPosted Mar 1, 2007 19:43 UTC (Thu) by tialaramex (subscriber, #21167)In reply to: Hunting for Rootkits by NAR Parent article: Hunting for Rootkits
Specifically the method generates _two_ files (not plain text but it could easily be PDF, HTML or various other formats) with the same MD5 digest value.
The files have the same length, but a block of nonsense (wrapped with a comment, or in a hidden inline image, or concealed in some other way) is different between the two files. A suitable feature of the file format is needed to make the apparent contents conditional on the nonsense data.
There is no way to use this attack, or any variation on the attack, to create an imposter for an existing file.
The threat model for which the attack is relevant is digital signing of third party documents. Imagine a company uses digital signatures to authorise purchase orders instead of hand written signatures. Suppose you're allowed to sign for POs up to $5000 without confirmation. A salesman from a new company offers you a great deal, for $200 you can get the parts you'd otherwise need to spend nearly $500 on elsewhere. He sends you a PDF to sign, which shows the $200 price, you sign it, and once the parts arrive you forget about it, central finance can do the paperwork. A few months later you're called into your bosses office because you've gone way over budget. The salesman, and the money, are long gone, but there's a PDF, signed by you, which clearly says the price is $4000 and so central finance paid the invoice.
If you use binary executables, or even certain types of configuration file, which have unexplained content, and you don't trust the party which created them, then you have a problem. You'd be vulnerable to this attack, but more importantly, you're already running untrusted code. If you trust the people who built your program executables, wrote your configuration files etc. then the known flaws in MD5 and SHA-1 are nothing to worry about in this particular application.
(Log in to post comments)
Two files with the same MD5 digest Posted Mar 2, 2007 17:03 UTC (Fri) by giraffedata (subscriber, #1954) [Link] So let me get this straight: The salesman created two contracts: one said $200 and the other said $4000 and they both have the same MD5 digest. I signed the MD5 digest. The Accounts Payable people are pretty stupid then, aren't they? With $4000 at stake, they should demand a signed copy of the full contract. But I'm sure if we think hard enough, we can find a case where signing a whole file is impractical and this twin-file technique would work.
Two files with the same MD5 digest Posted Mar 3, 2007 14:23 UTC (Sat) by kevinbsmith (guest, #4778) [Link] No, you signed the full $200 contract. Signing a digest is the same as signing the document. If the vendor delivers the contract to Accounts Payable, with your signature, they could deliver either the $200 contract (signed by you) or the $4000 contract (also signed by you). To foil (or at least detect) the attack, YOU would have to deliver the contract (the $200 one that you think you signed) to Accounts Payable yourself.
But this is just an example story, so don't get caught up in the unimportant details. The attack is possible any time you MD5 sign a document that was created by someone else.
The trivial defense is to make slight changes to the document before signing it. Even adding a few spaces. I suppose the other defense, at least to help you later in court, is to be sure to keep an archive copy of everything you sign.
At least that's my understanding. I'm not a crypto expert.
Two files with the same MD5 digest Posted Mar 3, 2007 19:10 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Signing a digest is the same as signing the document. In what way? As we've shown here, fraud is possible when you sign the digest and not when you sign the full document. That's a big difference. If I sign the full document, that means I encrypt the actual PDF with my private key and send the result to the salesman. He forwards it to Accounts Payable, which looks up my public key and decrypts it. The result is a PDF in which AP must see the same price I saw when I signed it. People like to sign digests instead because it uses less resources. Sometimes the tradeoff is worthwhile.
To foil (or at least detect) the attack, YOU would have to deliver the contract ... to Accounts Payable yourself. the other defense, at least to help you later in court, is to be sure to keep an archive copy of everything you sign. Those defeat much of the purpose of the signature, either allowing me to defraud the vendor or leaving an open question of what the agreed price was. It would be no worse than paper, though, where the salesman can take the signature sheet off the $200 contract and staple it to the $4000 one. Electronic signatures have the wonderful advantage over paper of non-repudiation. I can't deny that I authorized $4000 if I did.
|
|||||||||||||