

Why the Linux kernel is hardly at risk - danieldk
http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg

======
jbk
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.

~~~
marbu
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.

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

~~~
bonzoesc
The signature can be validated with a public key not available on the server.

~~~
recoiledsnake
"can be' is different from 'is'.

Since the attackers had root, what if they served up rootkitted kernels 1% of
the time someone downloaded a tar ball?

~~~
bonzoesc
The downloaders will have to be aware of the "no warranty" clause of the
license Linux uses, and take responsibility for the software they bring into
their environment. The kernel developers provide instructions[1] on how to
cryptographically verify the authenticity of a downloaded kernel, including
building a PGP "trust path" to their key.

1: <http://kernel.org/signature.html>

~~~
recoiledsnake
The signatures themselves are hosted on kernel.org...

~~~
bonzoesc
So? An attacker's not going to have the private key they were created with,
and probably won't have a private key that you have an existing trust
relationship to.

------
andrewcooke
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...](http://www.schneier.com/blog/archives/2005/02/sha1_broken.html)

~~~
weavejester
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.

~~~
andrewcooke
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.

~~~
weavejester
Your comment was accurate, but somewhat combative, which may be why it was
down-voted. I suspect if you had said the same thing, but had phrased it a
little differently, it would have been up-voted.

That said, it was not an unreasonable question to ask, and so I've up-voted
you.

What doesn't help is calling everyone "mindless fucking morons" after only one
or two down-votes. It's not constructive, and won't get you anywhere. Also:
chill. Just because one or two individuals didn't like the tone of your
original comment, doesn't mean everyone on HN is out to get you. Well, at
least not _before_ you insulted them.

------
bsiemon
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
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/>

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

~~~
Xurinos
Speaking as a regular git user, I assure you that a hash change would be
noticeable. Rebase would look for a common hash between your history and the
remote history you just fetched and rebase your commits on top of it. When
there is a mismatch, you experience a twilight zone where there are attempted
merges of code that your changes had nothing to do with. At this point, it is
apparent the remote history has changed, and in the process of trying to
figure out how to rebase cleanly, your eyes will be on that foreign code.

Given the number of changes coming in every release, more twilight zone
experiences increases the number of eyes on the discrepancy.

I am confident in the sanctity of the git-sourced code, thanks to there being
multiple version of the same repository around that people are actively
working on. I am more worried about all the stuff I might rely on that is not
git-sourced.

~~~
tonfa
If the history is tampered during a rebase how would you notice?

Suppose a tree well known for rebasing frequently is rebased on kernel.org,
and the dev doing it works from the k.org servers (might be possible, since
they give shell access).

Then downstream would just see it as yet another rebase, no?

~~~
Xurinos
Is this the hypothetical situation of someone doing an interactive rebase on
public/published branches and making changes midway through? My current
understanding is that, although it is possible, the community avoids doing
that (policy: published code history set in stone). That style requires strong
communication between developers. It makes people do extra investigation and
work, and we all hate doing extra work, right? :)

I cannot speak for what they really do over at kernel.org, but if they do
rebase their public repositories often (which will break people doing pushes
and fetch/merges without some regular communication), yes, it is possible to
sneak something in because the public rebase will not be as exceptional.

This is where you tell me that's what they do there and make me scared again.
;)

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

------
beza1e1
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. ;)

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

------
ghshephard
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
No - Linus' machine is still just another node. Git is fully distributed.
Everything in that article still holds.

~~~
ori_b
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.

~~~
exDM69
Not without going through a quite extensive review process and then finally
getting signed off (with a crypto signature) by several people.

It's not entirely impossible but there are far more easier ways of getting
malware out there.

~~~
gnosis
The ultimate goal might not be to simply get malware out there per se, but to
discredit Linux's reputation as a secure OS.

If that is the case, going to extra trouble to infect Linux kernel source may
well be worth it for the attackers.

