kernel.org compromised

Posted Aug 31, 2011 23:54 UTC (Wed) by daney (guest, #24551)
In reply to: kernel.org compromised by yokem_55
Parent article: kernel.org compromised

This is based on the axiom that SHA-1 is not breakable. Do we really know that this is the case?

to post comments

kernel.org compromised

Posted Sep 1, 2011 0:02 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

given the large numbers of researchers working on looking for weaknesses, and the publicity that comes from even a slight weakening of it, there is no reason to believe that is has been broken.

yes, it's always possible that there is some black hat out there that has broken it and not told anyone about it, but this is extremely unlikely (the black hat could get rich by just publishing this data, no need to do anything more with it)

In any case, I'm pretty sure that the kernel.org team is going to be double-checking everything by using multiple checksum/hash algorithms and the odds of all of them being able to be bypassed is vanishingly slim

kernel.org compromised

Posted Sep 1, 2011 0:53 UTC (Thu) by lutchann (subscriber, #8872) [Link] (1 responses)

> the black hat could get rich by just publishing this data, no need to do anything more with it

Famous, yes, but rich? I suppose you could get a new job with a sexy title and a fat salary, but you'd probably make more money more quickly by keeping your technique a secret and selling it to somebody.

value of zero day versus public reputation

Posted Sep 2, 2011 12:04 UTC (Fri) by copsewood (subscriber, #199) [Link]

Whoever would pay you to keep a SHA1 crack as a zero day vulnerability would have to pay more than the value of all the book sales and conference keynote speech fees. Also the kind of organisations who would want you to keep this secret are likely to be more difficult to negotiate with and dangerous to your health if negotiations go wrong than book publishers and conference organisers.

kernel.org compromised

Posted Sep 1, 2011 0:03 UTC (Thu) by njs (subscriber, #40338) [Link]

If you can break SHA-1, you have a few options:

Announce it to the world and instantly become famous for your mathematical genius, then take your pick of jobs in academia, at the NSA, etc.
Use the secret to screw with world governments, banks, and other such juicy targets. (Risky, but high possible payoff.)
Crack kernel.org, sneak a short-lived and soon-discovered back-door into the Linux upstream sources (which nobody important uses directly), and then wait to see which major government tracks you down first.

I wouldn't lose any sleep over this.

kernel.org compromised

Posted Sep 1, 2011 0:05 UTC (Thu) by jonabbey (guest, #2736) [Link] (4 responses)

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.

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_...

kernel.org compromised

Posted Sep 1, 2011 5:47 UTC (Thu) by iabervon (subscriber, #722) [Link]

There are two extents to which SHA-1 could be broken: (1) it could be possible to find one or many collisions, where the attack generates both colliding texts; (2) it could be possible to find a different text that collides with a provided text. Unless you're able to take your pair of texts and have one of them pass code review and the other introduce a back door, (1) is useless for attacking a project hosted in git with a reasonable development strategy. On the other hand, (1) will probably get you EV certs for *.google.com from a reputable CA, because x509 tools don't tend to be suspicious of chunks of random data in the certificate request like Linus is of chunks of random data in a patch. Based on the fact that MD5-based certs *have* seen this attack, and SHA-1 certs have seen less effective attacks, SHA-1 is probably not this broken. On the other hand, MD5 *is* that broken, but it's still not known to be so broken as (2), even with the algorithm changed to be weaker. There's a huge gap between (1) and (2), significantly bigger than between the strengths of different hashes, so it's implausible that (2) would have actually occurred before evidence of (1) being exploited had turned up.

kernel.org compromised

Posted Sep 1, 2011 7:21 UTC (Thu) by raalkml (guest, #72852) [Link] (1 responses)

Not just this axiom. It takes much more than a hash collision to introduce a commit into a git repository or change the recorded history.

See http://git-blame.blogspot.com/2011/08/how-to-inject-malic... for details

kernel.org compromised

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

Junio's blog post, strangely, does not mention sha1 collisions at all. sha1 collisions would allow bypassing exactly the mechanisms he describes.