kernel.org compromised

Posted Sep 1, 2011 0:05 UTC (Thu) by jonabbey (guest, #2736)
In reply to: kernel.org compromised by daney
Parent article: kernel.org compromised

It depends on the level of certainty you are asking for in using the term 'know'.

No one has demonstrated the ability to find a collision with a pre-existing text in the open literature yet as far as I know. There are techniques to find generate a collision with less than 2^80 operations, but that's still a ways from attacking Git.

See http://www.schneier.com/blog/archives/2009/06/ever_better...

Even if someone had the ability to generate a collision with a preimage text, they'd have the secondary task of making the colliding text look reasonable to kernel developers. When people were having fun creating md5 collisions, they tended to have pretty long sequences of random bytes in the text, which would be hard to hide in a kernel source file.

Long story short, it's very unlikely that anyone out there has successfully attacked SHA-1 to the degree necessary to be able to attack the kernel's Git repo. If they had, it's unlikely that they'd have made the kind of mistakes that attracted kernel.org's attention.

to post comments

kernel.org compromised

Posted Sep 1, 2011 7:04 UTC (Thu) by chax (guest, #52122) [Link] (3 responses)

How about making these semirandom bytes appear in a distributable firmware file? ;)

kernel.org compromised

Posted Sep 2, 2011 0:11 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

Yes, binary firmware is definitely a weak point. People tend to think it's more important to have source for software that runs on their CPU than software running on a peripheral processor. However, plenty of those peripheral processors can initiate DMA and compromise the host system unless they are carefully restricted by an IOMMU.

kernel.org compromised

Posted Sep 2, 2011 2:59 UTC (Fri) by Duncan (guest, #6647) [Link]

That's a possibility that I thought of too, but considering that each object is separately hashed, just getting random bytes into some random firmware doesn't help all that much.

Basically, in addition to that, you'd have to:

1) Insert the payload into the SAME firmware file (a different file will have its own SHA1, so it's gotta be the same file).

2) Somehow, convince Linus to accept a patch that loads that firmware file, either for your specific target if you have one (not out of the realm of possibility), or for a rather large segment of the kernel running population (rather more difficult, given kernel modularity, but it depends on just how large a segment you want, if everyone running a specific NIC or graphics chip is enough, it's not too difficult, but if you want nearly everyone running a Linux kernel, it's VERY difficult indeed!).

Even if that occurs, you then have to wait until it's actually deployed on your target, with some targets not updating for years, hoping it's not caught in the mean time.

So successful attack via firmware is indeed theoretically possible, but still not particularly simple in practice. There's almost certainly faster and less resource intensive compromise methods, so it's unlikely to be used in practice.

Duncan

kernel.org compromised

Posted Sep 2, 2011 5:49 UTC (Fri) by joey (guest, #328) [Link]

Git's potential exposure to sha1 collisions is broader than
just files. http://kitenet.net/~joey/blog/entry/size_of_the_git_sha1_...