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.

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.

Original article: http://news.slashdot.org/story/01/01/25/1343218/directvs-sec...

Fascinating background story here: http://www.wired.com/politics/security/news/2008/05/tarnovsk...

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?