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

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.

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.

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.