Cramming Software With Thousands of Fake Bugs Could Make It More Secure, Researchers Say (vice.com)

It sounds like a joke, but the idea actually makes sense: More bugs, not less, could theoretically make a system safer. From a report: Carefully scatter non-exploitable decoy bugs in software, and attackers will waste time and resources on trying to exploit them. The hope is that attackers will get bored, overwhelmed, or run out of time and patience before finding an actual vulnerability. Computer science researchers at NYU suggested this strategy in a study published August 2, and call these fake-vulnerabilities "chaff bugs." Brendan Dolan-Gavitt, assistant professor at NYU Tandon and one of the researcher on this study, told me in an email that they've been working on techniques to automatically put bugs into programs for the past few years as a way to test and evaluate different bug-finding systems. Once they had a way to fill a program with bugs, they started to wonder what else they could do with it. "I also have a lot of friends who write exploits for a living, so I know how much work there is in between finding a bug and coming up with a reliable exploit -- and it occurred to me that this was something we might be able to take advantage of," he said. "People who can write exploits are rare, and their time is expensive, so if you can figure out how to waste it you can potentially have a great deterrent effect." Brendan has previously suggested that adding bugs to experimental software code could help with ultimately winding up with programs that have fewer vulnerabilities.

Comments

Are you serious?

[mhkohne]

We can't manage to build the smallest bit of software without bugs, and now we're supposed to introduce large numbers of fake bugs that are, in fact, provably not exploitable.

Sure...that'll work.

Right up until the 'fake' bugs turn out to actually be exploitable (because, you know, we were wrong about them), and the bad guys win again.

Re:Are you serious?

[Xest]

Most seriously secure software goes through a number of procedures to ensure the highest level of security possible, static code analysis is an imperfect, but still helpful step in such a process. Doing this would likely kill any point in trying to decipher the output of an SCA tool.

As such, in software that's truly developed under a secure software development lifecycle including a multitude of approaches including things like an SCA would be near impossible with this approach.

Thus, even if in theory it might seem like a good idea, in practice it'd be impractical and would never fit into any sane secure software development lifecycle because it would inherently defeat a number of such processes in that lifecycle.

As such, this approach would have to be so good that it would have to be better than a series of tasks including things like peer reviews, static code analysis, pen testing and so on and so forth to justify using it over the aforementioned defence in depth approach of multiple layers of security assurance and risk mitigation during development.

In reality therefore, I'd agree with you absolutely and say whatever the theory on this, it's just not practical. Anyone wanting to maximise security would find this runs completely counter to any sane secure development lifecycle, and anyone not wanting that degree of layered security assurance, sure as hell wouldn't have the time and energy to introduce a ton of fake bugs and maintain such a codebase instead, because it'd simply be even more expensive than just having a sane defence in depth style secure development lifecycle as above.

Security through obscurity? So 90s

[jimmifett]

Before you know it, those fake bugs can easily turn into actual bugs. During porting, during updating, during review, etc.

Instead of laying a minefield of false positives to hide sloppy mistakes, why not just fix the exploitable mistakes in the first place and learn from the experience about what NOT to do?

security through obscurity

[Anonymous Coward]

... literally.

The bugs _are_ still there. They're just harder to find.

I don’t like to call people names, but

[93 Escort Wagon]

This guy is an idiot. An increase in complexity - which this most certainly would entail - will always lead to an increase in genuine bugs. And, as was said by someone further up... when programmers already can’t write bug-free code, how the heck are they going to make up 100% guaranteed non-exploitable false bugs which - at the same time - are indistinguishable from the real thing to a skilled hacker?

Given him some slack

[shayd2]

This might work. Right up until day 2 when someone leaks the list of "chaff bugs"