Regarding the kernel.org hack: Even with git’s hashing, wouldn’t an attack on Linus’ – or even a subsystem maintainer’s – computer still be a viable way to get code into the kernel, as said code would be a variant of new, unpublished code rather than changed old code?
It wouldn't be particularly easier to do it that way than just submitting your subversive code normally. Either way your change would need to be "underhanded" such that anybody viewing it wouldn't suspect anything.
In fact, trying to slip it in under the radar like that would actually just increase the chances of getting caught, because then it becomes something that isn't suppose to be there instead of merely something that does something that it isn't suppose to do.
If you can come up with a backdoor that requires the non-obvious interaction of multiple parts of the kernel (or parts of the kernel and certain user-space actions) then it would be reasonable to break up the necessary changes and slip each one in as a part of a larger demonstrable improvement to each specific subsystem.
For example (completely hypothetical), you could create a race condition in the kernel's page allocator that can be reliably be triggered by filling up physical ram and then forcing the kernel to allocate more memory for itself by filling up the proc table past a certain size. So in one patch you include an improvement to the allocator that has this obscure race condition but otherwise makes the allocator work much faster. Then in another patch you increase the maximum size of the proc table (under the pretense of supporting some big-iron system that practically no one outside of some HPC centers own) so that filling it up will force a kernel page allocation. So then you can force the exploit to occur on any system with both patches installed simply by allocating all the physical ram and then creating a ton of do-nothing processes that max out the proc table.
If you are an organization like the NSA you could even have the submissions come from what appear to be completely independent developers.
It is kind of the exploit version of "parallel construction." You know the exploit you want to put into the kernel, you just need to come up with reasonable sounding explanations for every little patch that ultimately gets you to the end goal.
That reminds me of a story I read about how the satellite companies foiled carders by slowly building up a new decryption system out of apparent garbage released across a long string of updates. I don't dare to search for it though, so I don't have a link.
There is every possibility, however, that there is open-source code in the Linux kernel that, at runtime, interacts with specific microcode instructions that can backdoor a system. Runtime remote backdoor triggers are more useful anyway, because the one thing the NSA can't do is hide from network sniffers. (Of course the best way to hide would be piggybacking on something like automatic software update requests - which I happen to disable, as a nod to my tinfoil wearing brethren.)
How many security exploits have been found in the Linux kernel, or other trusted software? How many of those were around for a "long time"? Every one of those got by the normal peer review process.
So the question is, which is harder: does it take more skill to accidently insert a bug that gets by (sometimes for years), or to do so on purpose?
