kernel.org compromised

Posted Sep 2, 2011 18:54 UTC (Fri) by dlang (guest, #313)
In reply to: kernel.org compromised by zooko
Parent article: kernel.org compromised

I actually see what the kernel.org folks are doing as one of the best examples of dealing with a compromise that I've seen.

as for your objection that they are running commands on the system to track the extent of the problem, that is something that they pretty much must do, having a spare system with those sort of specs laying around just in case it's needed isn't practical (the thing holds 66 drives for crying out loud, that's _expensive_ and there is a good case to be made for keeping all of that expensive hardware that's been donated in use rather than just sitting around.

they have said that as far as they can tell the git repository has not been tampered with (and they say how they know that), so if you downloaded via git and compiled, you should be good.

it's not just assuming that the filesystem hasn't been changed, it's also the fact that all of the people who pull through the git interface (that you are saying may send trojened source) are automatically doing checks on the data.

yes it's theoretically possible to backdoor git so that it sends valid data to some people and invalid data to other people, but since the git transport layer isn't encrypted, it would be far easier to do this via a man-in-the-middle attack on your network than it would be to compromise kernel.org to do this for you.

to post comments

kernel.org compromised

Posted Sep 5, 2011 11:53 UTC (Mon) by hein.zelle (guest, #33324) [Link]

> yes it's theoretically possible to backdoor git so that it sends valid
> data to some people and invalid data to other people, but since the git
> transport layer isn't encrypted, it would be far easier to do this via a
> man-in-the-middle attack on your network than it would be to compromise
> kernel.org to do this for you.

As long as we're looking at the theoretical possibilities (can you be 100% sure you're not compromised), that argument doesn't really matter. Also, if the aim is to infect a large number of machines with a modified kernel, it certainly would make sense to use a backdoor in git on the server, instead of using a man-in-the-middle attack on a local network.

In this case I personally would be fine with running that kernel and trusting the research of the kernel.org sysadmins. However, for systems with truly critical security levels, I can imagine that's not acceptable.
I would certainly start with assuming that someone hacking kernel.org is very clever and came extremely well prepared, if only because they might have been.

Independent sources for checksums or signatures sound like a viable solution (to someone who knows very little about security or checksums). That may be worth implementing for those administrators who truly depend on 100% secure verification. As for not running make before verifying what you downloaded - that definitely sounds like the responsibility of the person downloading and building the kernel.