Why the Linux kernel is hardly at risk

http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg

by microtonal • 15 years ago

76 35 15 years ago

ghshephard• 15 years ago

My reading of this article is that Linus's machine is the real target if you want to inject malware into the kernel undetected.

mstroeck• 15 years ago

No - Linus' machine is still just another node. Git is fully distributed. Everything in that article still holds.

ori_b• 15 years ago

Linus, however, is not distributed. If a malicious commit was discreetly slipped into his repository as a seemingly Linus-sourced change, there is enough trust in him that the change would likely propagate.

dolbz• 15 years ago

Really the point is that nothing can be injected into the git history undetected. To add any new code to the repository it needs to be put at the top of the 'stack' as the last commit. So even if someone got access to Linus' (or any other high level dev) machine they wouldn't be able to inject malware undetected as a look at recent commits would show the changes made.

kahawe2• 15 years ago

Yep, the very detailed article comes down to one basic fact: "we always have lots of copies on our and other people's machines so we can always track ANY possible modifications."

In that regard, I guess it could be more "likely" to sneak in a very, very well hidden and cryptic exploit in contributed code.

bsiemon• 15 years ago

I guess the best an attacker could hope for would be to modify the git binaries on the server. Even that would amount to little it seems.

extension• 15 years ago

If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/

tonfa2• 15 years ago

Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...

sneak• 15 years ago

What if they wanted to modify the source archives of some other project hosted there? Obviously the kernel is a big target, but it seems there are lots of other less-widespread things on there that would be useful to backdoor.

jbk• 15 years ago

A large portion of people and distributions take the kernel from tarballs, not from the git.

So, this is very annoying for people who took kernels tarballs in the past from kernel.org.

Sure, they can regenerate all the tarballs from the git repositories, but this isn't the point for the past actions.

stygianguest• 15 years ago

Perhaps this is a good opportunity to change that. Actually, I'd expect at least the bigger distributions to use git already. Git enables them to pick and choose from the updates and merge it with their own patches (alternative schedulers and the like).

But you're right, as long as they serve tarballs, they should make sure they are safe. I've rolled some kernels myself and always used th e tarballs from kernel.org. Time to practice what I preach an rebuild from git.

marbu2• 15 years ago

All tarbals are signed via linux kernel archives gpg key, which according to the kernel.org security breach announcement was not compromised. So I don't see a problem here.

recoiledsnake3• 15 years ago

Don't you see the problem with the server hosting both the tar balls and the signature being compromised?

beza1e1• 15 years ago

The latest git SHA1 sum is not enough to check. The interesting part for intruders are "grafts":

"Graft points or grafts enable two otherwise different lines of development to be joined together. It works by letting users record fake ancestry information for commits." https://git.wiki.kernel.org/index.php/GraftPoint

Still easy to check though. ;)

lloeki2• 15 years ago

IIRC grafts are local and not propagated by clone/push/fetch. Replacements via git-replace(1) are, though.

andrewcooke2• 15 years ago

this post assumes (if i have understood the argument correctly) SHA-1 is secure. it's isn't - it is well and truly broken. people don't use SHA-1 for security any more (well, they certainly shouldn't). is their any real analysis that shows that git is secure, given the weak nature of SHA-1?

http://www.schneier.com/blog/archives/2005/02/sha1_broken.ht...

weavejester2• 15 years ago

It's not quite that simple. When cryptographic functions are broken, practical vulnerabilities are usually years away. A reduced SHA-1 collision time is certainly a good reason to move away from SHA-1, but it doesn't mean that an attacker can compromise an existing piece of code secured by a SHA-1 hash.

In this case, it is not merely sufficient to find a collision, but to find a collision that is also a valid Git commit, implements a vulnerability, and, ideally, is not immediately obvious at first glance it is a hack (i.e. having kilobytes of garbage data in the commit diff). This is much harder than just finding a random set of bytes that just happens to match the commit SHA-1.

Now, it could be that an organisation like the NSA is sufficiently ahead of public crypto technology that it is capable of not only finding a SHA-1 collision in feasible time, but is also able to craft a malicious Git commit with an identical SHA-1 to a legitimate commit. Inserting such a commit into the Linux source in an appropriate place might result in compromised kernels appearing in commercial products.

But... I kinda doubt anyone is that far ahead, and in any case, it seems extremely risky to try to play such a high-value advantage in a public repository. If someone happens to spot your faked commit, suddenly everyone knows what you are capable of.

So whilst Git would be more secure using SHA-512 or an equivalent, it's currently very unlikely that anyone has the practical capability and will to compromise the kernel's commit log.

andrewcooke2• 15 years ago

i am not saying git is insecure - i am saying someone needs to do exactly the analysis you are sketching. you can wave your hands and say that this is not a problem, but it's been 6 years since sha-1 was broken and that's an awfully long time.

also, i find it absolutely typical of the place that HN has become that my original post asking a reasonable, informed question with reference is voted down. you're a bunch of mindless fucking morons.

Why the Linux kernel is hardly at risk

Related Stories