kernel.org compromised

Posted Aug 31, 2011 23:33 UTC (Wed) by yokem_55 (subscriber, #10498)
Parent article: kernel.org compromised

Our fine editor (probably less than cheerful at the moment) has a piece on linux.com explaining for lay folk why the kernel sources couldn't be tampered with.

to post comments

kernel.org compromised

Posted Aug 31, 2011 23:54 UTC (Wed) by daney (guest, #24551) [Link] (12 responses)

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

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.

kernel.org compromised

Posted Sep 1, 2011 0:44 UTC (Thu) by hmh (subscriber, #3838) [Link] (1 responses)

I would be more worried about all the stuff in mirrors.kernel.org, binaries at boot.kernel.org, as well as the tarballs and diffs...

kernel.org compromised

Posted Sep 1, 2011 1:12 UTC (Thu) by mtaht (guest, #11087) [Link]

Breakage into mirrors.kernel.org of anything not protected by a sha1 hash worries me. Even if it was temporary - a day or two - then changed back, people that rely on those mirrors of various distros, pieces of those distros could have been compromised unknowingly.

d@bob-desktop:~/git$ host mirrors.us.kernel.org
mirrors.us.kernel.org has address 149.20.4.71
mirrors.us.kernel.org has IPv6 address 2001:4f8:1:10:1997:313:1:0
mirrors.us.kernel.org mail is handled by 10 hera.kernel.org.
mirrors.us.kernel.org mail is handled by 20 zeus1.kernel.org.
mirrors.us.kernel.org mail is handled by 30 zeus2.kernel.org.
mirrors.us.kernel.org mail is handled by 999 bl-ckh-le.kernel.org.

What bothers me right now is that I remember seeing several updates go by in the past month that weren't verifiable via gpg key on several systems I maintain... and I just did installs of them...

kernel.org compromised

Posted Sep 1, 2011 13:06 UTC (Thu) by eupator (guest, #44581) [Link] (6 responses)

This analysis assumes that the compromised git.kernel.org serves the same contents to everyone, which is not necessarily true.

kernel.org compromised

Posted Sep 1, 2011 14:39 UTC (Thu) by epa (subscriber, #39769) [Link]

Obviously instead of releasing "Linux 3.0" Linus should have announced Linux version 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe and instructed everyone to fetch it using git instead of downloading source tarballs. (Really, why are we still doing that?)

kernel.org compromised

Posted Sep 1, 2011 15:25 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

Even if it doesn't, Linus's and Greg's tags are signed and validate against a key fetched long before the compromise: and I very much doubt their private keys are on kernel.org.

kernel.org compromised

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

You may be doubting wrong. See the last paragraph of the H-Online coverage, here:

http://www.h-online.com/open/news/item/Security-breach-at...

Apparently the signatures are generated on a server @ kernel.org, and it's as yet unclear whether the crackers had access to all the necessary components for signing, or not.

Duncan

kernel.org compromised

Posted Sep 2, 2011 14:25 UTC (Fri) by nix (subscriber, #2304) [Link]

I'm not talking about the PGP signatures for the tarballs. I'm talking about the signed *tags* in the git tree: the object you see via e.g. 'git show v3.0.4'. That is part of the git repo and cannot be forged without access to Greg's private key. Now a hostile attacker could add a fake one, but the key would be different, and Greg would be certain to notice.

kernel.org compromised

Posted Sep 2, 2011 5:07 UTC (Fri) by eupator (guest, #44581) [Link] (1 responses)

A very good point about GKH - users of his stable trees are indeed protected, assuming they check the signatures. Less so, sadly, about Linus - the tip of his tree isn't signed, and even if it was, I don't have a path of trust to his key.

kernel.org compromised

Posted Sep 2, 2011 14:28 UTC (Fri) by nix (subscriber, #2304) [Link]

The tip isn't signed, but the rcs are, so you know that v3.1-rc4, released Aug 28 2011, is legitimate, and so is all the history leading up to it.

Conclusion: the git tree is not compromised up to that point.