On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote: > On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: > > > > If SHA-1 is broken (in certain ways), someone *can* replace an > > arbitrary blob. GPG does not help in this case, because the > > signature > > is over the commit object (which points to a tree, which eventually > > points to the blob), and the commit hasn't changed. So the GPG > > signature will still verify. > > The "in certain ways" is the critical bit. The question is whether > you are trying to replace an arbitrary blob, or a blob that was > submitted under your control. > > If you are trying to replace an arbitrary blob under the you need to > carry a preimage attack. That means that given a particular hash, > you > need to find another blob that has the same hash. SHA-1 is currently > resistant against preimage attack (that is, you need to use brute > force, so the work factor is 2**159). > > If you are trying to replace an arbitrary blob which is under your > control, then all you need is a collision attack, and this is where > SHA-1 has been weakened. It is now possible to find a collision with > a work factor of 2**69, instead of the requisite 2**80. > > It was a MD5 collision which was involved with the Flame attack. > Someone (in probably the US or Isreali intelligence services) > submitted a Certificate Signing Request (CSR) to the Microsoft > Terminal Services Licensing server. That CSR was under the control > of > the attacker, and it resulted in a certificate where parts of the > certificate could be swapped out with the corresponding fields from > another CSR (which was not submitted to the Certifiying Authority) > which had the code signing bit set. > > So in order to carry out this attack, not only did the (cough) > "unknown" attackers had to have come up with a collision, but the two > pieces of colliding blobs had to parsable a valid CSR's, one which > had > to pass inspection by the automated CA signing authority, and the > other which had to contain the desired code signing bits set so the > attacker could sabotage an Iranian nuclear centrifuge. > > OK, so how does this map to git? First of all, from a collision > perspective, the two blobs have to map into valid C code, one of > which > has to be innocuous enough such that any humans who review the patch > and/or git pull request don't notice anything wrong. It looks like Linux contains at least some firmware which would be hard to audit. One random example is: firmware/bnx2x/bnx2x-e1h-6.2.9.0.fw.ihex -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html