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.

Re:Are you serious?

[Anubis IV]

Moreover, how is this supposed to provide any extra protection unless it's done manually? They talk about having a system for automatically inserting fake bugs (presumably during compilation, minification, or some other similar process that happens after the developer does their work, that way the developer never sees the buggy code and gets distracted trying to fix it), but such additions would be deterministic in nature and easily noticed/removed. In much the same way that we can de-compile code and can de-minify code by running it through various tools, it surely wouldn't be that difficult to de-bug code that had had "safe" bugs deterministically added to it.

Re:Are you serious?

[jellomizer]

This idea is like the Honey Pot idea for network protection.

This was popular 20 years ago, where most hacking was targeted at a network, by individuals. You get a system to similar an insecure pc, have the hackers break in think they are getting away with murder, while it collects information on who is hacking it and how. And using that information to protect your real network.

Hacking rarely works like that now. Either it is fully automated so a honey pot server would just be a statistical issue while the other servers are getting hit, or if it is more targeted it will often go in via stupid users on the inside of the firewall.

Most security glitches are not bugs in the traditional sense. For the most part buffer overflows have been fixed. But from lazy software development from developers not thinking about security at the time.

Re:Are you serious?

[bluefoxlucid]

Honeypots alert you to activity. A network scan hits them. There is nothing useful on this web server, yet someone tried to browse it. Someone tried to connect to the server's file share. You're able to identify malicious traffic and hosts.

Software bugs don't tell people anything. You put it on a non-networked machine, you probe at it, you take it apart, you crash it, you tell no one.

Re:Are you serious?

[phantomfive]

People don't care about bloat anymore. You can notice this by looking at the node_modules directory of any node project. It's huge.

Re: Are you serious?

[dcw3]

this works great until a decoy bug becomes a real bug. programmerâ(TM)s famous last words: âoeit wasnâ(TM)t supposed to do thatâ

I see you planted a couple in your sentence.

Re:Are you serious?

[dcw3]

While I'll agree that the idea is flawed, I'll disagree with you on the reason. SCA could easily be done because you know where you put the bugs. That info should get passed along to any/all reviewers, just not outside the company/dev group. That said, I'd agree that these fake bugs could and likely would introduce actual flaws, and are most likely just a waste of valuable resources that should be busy finding/fixing actual issues.

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?

Re: Security through obscurity? So 90s

[zlives]

the Microsoft Model.

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?

Just trying to make programming perpetual...

[aaronb1138]

I guess Agile isn't getting the job done, but this is just another in a long list of make work methodologies programmers are deeply entrenched in doing in order to make their jobs perpetual. Also, it's a great hedge for the CPU industry which doesn't have any killer apps to further justify increased computational capacity for the average user. In smartphone land, the approach to forced obsolescence is security / OS updates being withheld from consumers quite maliciously. For desktops and laptops, the update genie is long out of the bottle, so you have to come up with some other way to make people's computers slow. Honeypot code is definitely a new way to do exactly that.

The downfall of Waterfall is that eventually, you can have a complete and working product. But nobody wants to make a Windows XP or Office 2003 that works forever and gets the job done.

Given him some slack

[shayd2]

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

Hmm... more bugs the better.

[fahrbot-bot]

More bugs, not less, could theoretically make a system safer.

Just like how adding actual bugs to food makes it tastier.

Reminds me of the old line...

[mykepredko]

I don't like to call anybody an idiot, but I don't know any other way to end this sentence.

"Works with my... experiment", says author

[adosch]

That's all I really needed to read. I'd love to write any lengthy rant here to entertain any /.'ers, but I think that says it all. Far cry from cooking up some experimental code that isn't production worthy at all, or SaaS where it's built to drive, function, and fund a business model, no way is your experiment anything more than that.

I'm sure some one has a rank of OSS software against vulnerabilities and/or exploits in their code-base, introduced their "bug" idea into a fork of the application and saw how it went over a period of time. Skipping their academic paper, I saw nothing of that and more of a tip to promote their LAVA system, plus a but of academic accommodating and citing of peers papers.

Sounds cool in academia world as a proof-of-concept to put a paper out and get more grant money, but that's all I'll promote. Anyone who's written a bit of code, maintained anything software related at all knows this is absolutely not realistic.

Few "Exploits" not "Vulerabilities"

[DalM]

"Brendan has previously suggested that adding bugs to experimental software code could help with ultimately winding up with programs that have fewer vulnerabilities."

This is not correct. His theory seems to be that you will get fewer exploits. The number of vulnerabilities will remain constant.

Re:Brilliant idea

[ShanghaiBill]

Once a critical nuber if bugs is introduced the software becomes unusable hence making it unattractive for hacz0rz to exploit.

The bugs are not at the UI level. The "bugs" are exploitable code that is never actually executed. Black hats would find them when scanning the code, and try to exploit them, but the exploits wouldn't work because the code never executes.

The "bugs" would add a trivial amount of bloat, but will otherwise not affect performance or behavior.

int
main(void) { // ...
    if (somethingThatWillNeverHappen()) {
        char buffer[20];
        gets(buffer); // Buffer overflow target
        mysql_query(buffer); // SQL injection target // ...
    } // ...
}

Disclaimer: I think this is a dumb idea. I am just explaining it, not endorsing it.

This sounds like a form of security-thru-obscurity

[MAXOMENOS]

Let's suppose (big if) that we can cram a program with bugs that are either highly unlikely to be exploitable, or provably not exploitable. How long would it take an attacker to learn to recognize a real bug from a manufactured bug, and filter out the probably-manufactured ones?

How long would it take to build a classifier to recognize and flag probably-manufactured bugs?

This might make more sense if we combined this technique with better means for closing exploitable, or probably exploitable, bugs. But man, color me skeptical.

Re:Brilliant idea

[DarkOx]

Black hats would find them when scanning the code

unless we are talking about open source that someone might feed to an static analysis tool that is pretty unlikely.

Blackhats don't "scan" binaries they fuzz them - in other words they feed data to "ui level" inputs and than watch where those patterns land in memory. If you are talking about buffer over flow type bug where they can run software locally.

Logic bugs probably much more common today that over flows given the languages being used and the fact that everything is on the web again get exercised by things like crawlers and maybe directly parameter tampering. They key here again is the process STARTS by identifing inputs the application takes.

So if you stuff a bunch of unreachable code in the application odds are the blackhats won't ever see it and won't therefore spend any time on it. If someone does scan a binary tools like IDA are pretty good at identifying unreachable code too so its unlikely to be anything but a short lived arms race.

  Now if you put 'fake bugs' like say change all the strncpy calls back to old strcpy calls and than somehow move the bounds check to some far away part of the program while you write into a buffer inside an larger data structure you don't than use for anything you 1) risk screwing it up and creating an bug that is still exploitable 2) leave a useful gadget (code someone who has exploited an actual bug can now lever to help them gain even more control of execution 3) leave a nice hunk of process that can safely be replaced with larger shell codes 4) fail to fool anyone because you are dealing with people who will be able to spot the tells and won't be taken in.

Re:Brilliant idea

[Tablizer]

Once a critical nuber if bugs is introduced the software becomes unusable hence making it unattractive for hacz0rz to exploit.

I intraduce tuns of spailing and grammer errers so that grammer notzees get to flustured too bothur too complane. Werks ulmost evry time.