Cramming Software With Thousands of Fake Bugs Could Make It More Secure, Researchers Say (vice.com) 179
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.
Are you serious? (Score:5, Insightful)
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: (Score:3, Insightful)
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 mi
Re: (Score:2)
In most cases a C compiler would already remove the unused bugs, and it wouldn't really be that hard to alter an SCA tool to know about a few of the tricks that could be used to prevent it getting optimized out.
I write decoy bugs all the time (Score:2)
And they generally get though our vigorous internal security scans just fine (i.e. the code generally compiles). And none of this fake bugs, my decoy bugs are real ones. Genuine bugs. Lots of then.
So many that even the most determined hacker is unlikely to figure out how to make the software work correctly, let alone hack it.
Re: (Score:2)
Want more reliable more secure software. Simply take all the flixibility out of it, so it can only do what it is programmed to do. That and make real software warranties regulated and compulsary. Treat purposefully bad software like fraud, hand out custodial sentences for code coming out the door that they knew was bad.
Want better software, start throwing bad coders in prison, simply the truth. You watch the quality of code improve over night, you all know it is true.
Software is as bad as it's warranties
Re: (Score:2)
And watch the cost of code shoot through the roof, along with the time it takes to bring things to market....over night my ass.
Re: (Score:2)
Well, my feeling is that it would cause tremendous software bloat. That said, if the addition of the bugs is automatic, they could be added AFTER the secure development step. And it would mean that those trying to decipher what actual bugs are there would find many of their tools nearly useless.
So...maybe. It sounds like a long shot, and not terribly good even if it works properly, but it might work. And the code bloat would explode.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
On the contrary, that's exactly the environment where introducing fake bugs could be useful. Not for misleading attackers, but for testing whether the QA department can find them. I agree that deliberately including bugs in the final product is bad design, but putting them into an internal version to check whether you can find them might give you useful information.
Re: (Score:3)
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.
Re: (Score:3)
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 d
Re:Are you serious? (Score:5, Informative)
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? (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
At least for once I'm ahead of the game.
Re: Are you serious? (Score:2)
Re: Are you serious? (Score:1)
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â
Re: (Score:2)
And the ROP hacker nearly shits himself with all the new gadgets he has at his disposal.
Re: (Score:3)
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: (Score:2)
A lot of things are "security through obscurity". Every combination lock or password is an example of that. It's not always bad.
I think, however, that it would be better to have each piece of code have an individual hash value, one that's different for every instance. And when installing the code, have it register itself with the system giving it's valid hash code. Then you could always check whether it had been corrupted. This requires a customizable way of computing the hash such that, perhaps, the d
Security through obscurity? So 90s (Score:3, Insightful)
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 (Score:1)
This is not really obscurity...this is security through insanity. Or Security by being disgusting.
Re: (Score:3)
the Microsoft Model.
Security through chaos (Score:2)
The Tesla model?
Brilliant idea (Score:2)
Re:Brilliant idea (Score:5, Interesting)
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 // ... // Buffer overflow target // SQL injection target // ... // ...
main(void) {
if (somethingThatWillNeverHappen()) {
char buffer[20];
gets(buffer);
mysql_query(buffer);
}
}
Disclaimer: I think this is a dumb idea. I am just explaining it, not endorsing it.
Re:Brilliant idea (Score:5, Interesting)
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: (Score:2)
Or, for Internet-based services, the bugs can be non-exploitable code that will fool fuzzing attacks into thinking that it is wreaking havoc, when in fact it is doing exactly what it was programmed to do.
For example, if your service can detect an inappropriate number of fai
Re: Brilliant idea (Score:2)
A good compiler for a sane language would simply remove the dead code. If it's not dead code, then it's exploitable.
Re: (Score:2)
A good compiler for a sane language would simply remove the dead code. If it's not dead code, then it's exploitable.
That's why you don't say if (0} { ...
Instead you do something like:
if (findCounterExampleForGoldbachsConjecture()) { ...
Good luck deciding if that code is dead.
Or just call something like foo() { return FALSE; } in a separately compiled module.
Re: (Score:2)
If your compiler doesn't remove that, you probably turned off optimizations.
Re: (Score:2)
The paper [arxiv.org] says the injected bugs are triggered by comparing an input value to a trigger constant. Dead code elimination cannot remove them because they depend on values that will not be known until run time.
It also explains that they make the chaff bugs unexploitable (or at least, attempt to do so) by limiting what memory locations they overwrite or which values are written.
Re: (Score:3)
I intraduce tuns of spailing and grammer errers so that grammer notzees get to flustured too bothur too complane. Werks ulmost evry time.
Re: (Score:2)
Werks is an obsolete spelling, not an error. Dumb-ass.
Re: (Score:2)
histery (n) A building in which artificial wombs or similar devices are made.
Usage: I just ordered a new `pocket' from some random histery, I hope it isn't contaminated!
From the ancient Greek "hustera."
First use: 2018
Zee is Netherlands for the sea. I think you said something about a Dutch sex toy factory on solid ground not below sea level. If it was below sea level it would be Histeridam or something.
security through obscurity (Score:3, Insightful)
... literally.
The bugs _are_ still there. They're just harder to find.
Sounds good to me (Score:2)
I don’t like to call people names, but (Score:5, Insightful)
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?
Reminds me of the old line... (Score:4, Funny)
I don't like to call anybody an idiot, but I don't know any other way to end this sentence.
Re: (Score:2)
Segregating complexity reduces complexity. The monolith vs microkernel argument is a familiar model for this: a monolith can connect any part of its code to any other part, as any operation can affect any internal state for any other operation; whereas a microkernel has defined communication channels and segregates blocks of code so they can only affect their own state and the state of information sent to them.
In object-oriented programming, objects abstract and encapsulate state. Polymorphism provide
Re: (Score:2)
whereas a microkernel has defined communication channels and segregates blocks of code so they can only affect their own state and the state of information sent to them.
If that was actually true, GNU Hurd would be something useful that people work on, instead of something useless that was abandoned!
Re: (Score:2)
Not really. Popularity and utility are different things. Score voting advocates try to use that argument because they think voting is about marginal utility (finding the candidate most-useful to the electorate), rather than social choice (finding the greatest consensus among the greatest mutual majority).
Think about it. People actually use FreeBSD as an everyday desktop, yet Linux is the most popular. Why does anyone use FreeBSD? For that matter, why don't BSD users switch to Dragonfly BSD? Why aren
Re: (Score:2)
If you RTFA, you would see that the bugs are introduced by an automated source to source transformation tool at build time, not by the original programmer. So the question is, can the writer of the tool guarantee that the bugs it inserts are not exploitable. While I wouldn't sign off on it per-se, that does seem a whole lot easier than having each developer do so -- yo
Re: (Score:2)
when programmers already can’t write bug-free code, how the heck are they going to make up 100% guaranteed non-exploitable false bugs
Machine learning.
I'd put a /s, but no, I'm seriously predicting that they'll try this.
Re: (Score:2)
The chaff bugs would be inserted by an automated tool. [arxiv.org] No need for programmers to make up anything.
They would not be indistinguishable from the real thing to a skilled hacker; the idea is that they would be so numerous as to make the effort of finding the actual exploitable bugs uneconomical.
Re: (Score:2)
I could easily jump to a conclusion here. But really it's not even a jump, barely even a shuffle.
STFU, Ivan.
Re: (Score:2)
I suppose an alternative statement - which I probably should’ve used - is “this idea is idiotic”.
They can't be serious (Score:1)
We have enough issues with trying to make bug free code. So let's add bugs that we "think" aren't exploitable. So we now have the following categories of bugs.
1. Organic, non-exploitable (we already have these)
2. Organic, exploitable (we already have these)
3. Deliberate, non-exploitable (we "want" to introduce these)
3. Deliberate, exploitable (we hope to not introduce any of these... Just like we already hope to not introduce any of type 1 and 2 bugs above... Yea, right.)
Legitimately Good Idea (Score:1)
Re: (Score:2)
Re: (Score:2)
And generally breaking stuff is quicker and easier than creating it in the first place.
That's never once been my experience with QA. Breaking it always takes longer and is more expensive, because it only gets written in the first place one time, and it gets broken again and again and again and you'll never know if it is done breaking.
Isn't this called a honey pot? (Score:2)
I thought honey pots involved... (Score:2)
Babes with big tits, speedboats and mountains of cocaine.
Otherwise, what's the point?
Re: (Score:2)
Same idea as a honey pot (Score:2)
Re: Same idea as a honey pot (Score:2)
Sun Tzu was talking about real human armies. Imagine an army that never tires and the verse no longer applies.
Just trying to make programming perpetual... (Score:4, Interesting)
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: (Score:1)
I'll respond to this post, as it reflects best the current "state of art", and false perpetuated culture of fear/survival. This is what you get.
As if your "needle in the haystack", isn't someone else's rather fun and innovative disruptive ML sideproject.
Btw, waterfall was meant as a joke by the original author, and thought nobody would be so ignorant as to follow it by the letter.
Also, the Agile consultancy industry follow "Agile" to the letter with a straight face, while Agile Manifesto states the exact op
What About The Real Bugs? (Score:1)
1) if you have 500 fake bugs then how are the white hat hackers going to tell you about the real bugs that lurk in your system?
2) how do you prevent the fake bugs from being miscoded to accidentally becoming real bugs? Developers think it's a dummy fake bug and ignore all bug reports about it but it's truly a real bug.
Given him some slack (Score:4, Insightful)
Hmm... more bugs the better. (Score:4, Funny)
More bugs, not less, could theoretically make a system safer.
Just like how adding actual bugs to food makes it tastier.
Convince a Product Manager to add bugs to App? (Score:2)
I can't see how to do this without spending a lot of time ensuring that the bugs you are adding are non-exploitable.
So, during product definition phase, you're going to have to convince the Product Manager that you want to take more time on the application development by adding exploit bugs and then testing said bugs to ensure that they can't be exploited?
Great non-intuitive idea that clearly came out of academia. Clearly Dolan-Gavitt has never worked for a living.
Re: (Score:2)
I can't see how to do this without spending a lot of time ensuring that the bugs you are adding are non-exploitable.
Oddly enough, the authors of the paper explain this in section IV-B Ensuring Non-Exploitability [arxiv.org]
Great non-intuitive idea that clearly came out of academia. Clearly Dolan-Gavitt has never worked for a living.
What's with the hostility toward academia? Lots of great ideas have come out of academia. No academic myself, just decades of writing real-world software, during which I've learned not to judge other people, especially without reading their work.
I knew it all along... (Score:2)
If cramming code with bugs increases security, the code I write is incredibly secure.
Comment removed (Score:3)
Re: (Score:2)
I am not yet entertained.
Re: (Score:2)
Few "Exploits" not "Vulerabilities" (Score:5, Informative)
"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.
Rather Publish, Dolan-Gavitt should have Perished (Score:2)
This idea comes under the heading of "Well, I don't have any useful research, so why don't I publish a paper taking a contrary tack and get noticed."
Clearly the author has, never written a line of code in his life that somebody has to maintain, dealt with product managers that want more for less, worked with QA and security or documented anything that he has written (how do you document that you've put deliberate bugs in the code that should be ignored down the road?).
So, write up a paper extolling the virt
Re: (Score:2)
Not a problem for coder or documentation, the compiler would insert these non-bugs
oh my dog! (Score:2)
and
"...once they had a way to fill a program with bugs..."
I think I've found my natural calling
Re: (Score:2)
Re: (Score:2)
Shit, I just realized all my unreleased vaporware is suddenly worth a fortune!
I've got thousands or millions of bugs that are non-exploitable, and as long as nobody releases the software, they'll stay that way!
It's my time to shine (Score:1)
Yay, I can finally get a job as a programmer!
Hire me! Hire me!
Obligatory xkcd and Dilbert (Score:2)
I can honestly say that this idea is so dumb that it hasn't been parodied in the comics (yet).
Re: (Score:2)
http://dilbert.com/strip/1995-... [dilbert.com]
First result for "dilbert bug bounty minivan"
and the hard part? (Score:2)
determining that they're benign.... now that's the hard part; who signs off on that?
This sounds like a form of security-thru-obscurity (Score:3)
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: (Score:2)
How long would it take to build a classifier to recognize and flag probably-manufactured bugs?
In an arms race, "how long does it take to (reach the next level playing field)" is a relevant factor. A temporary measure is temporary, but it protects for as long as it lasts.
this is not a new concept (Score:2)
Whut (Score:2)
This would only make it even more difficult if researchers have to navigate their way through decoy code designed
against finding real bugs in the first place.
Not to mention, bloated code becomes even MORE bloated code. :|
So the entire idea is " If you can't fix the bugs in the code, hide it amidst a bunch of fake bugs in code ? "
In the history of anything, has security through obscurity EVER worked in the long term ?
This is an old idea and pretty stupid (Score:2)
Most attackers use fuzzing for finding bugs to analyse further. Hence these need to be bugs that can be found by fuzzing. Fuzzing needs either a crash or crass bad behavior to detect a bug. So all these "non exploitable" bugs can actually be exploited for DoS or will break your application for the right input data. That is the first reason this is unworkable. The second one is that this makes software hard to maintain and hard to test. It is already hard to maintain and test software, and tthis will make it
Re: (Score:2)
They did in fact test their chaff bugs against a fuzzer, which found them. They took steps to ensure that the bad behavior is actually harmless (for example, overwrites go to areas of memory that aren't actually used).
How do you see this making software harder to maintain? The chaff bugs are inserted by an automated tool, maintainers looking at the source code will never see them.
For testing, run the test cases against chaffed and unchaffed builds. Test cases that fail in both are probably real bugs. Test c
Re: (Score:2)
You cannot have much experience with writing software in an enterprise environment. "Probably real bugs" does not cut it. Maintainers "will never see them" does not cut it. Anything that can be hit by a fuzzer can be hit by some other application doing something stupid. You will find arbitrarily misbehaving code in any enterprise environment. If you the have this crap in your way when trying to find out what is wrong, a problem turns into a disaster.
Fake bugs? (Score:2)
I do that one better. My programs are full of REAL bugs.
That's just silly (Score:2)
This one needs the foot icon. The first rule of application security is that obscurity is not security. Also assuming a hacker who's compulsively raiding your software will ever run out of energy is also an incredibly stupid idea. I like the way this one plays out. It's hilarious, but it won't work.
Madness from the security guys (Score:2)
"fake" bugs? No, these are real bugs, just non exploitable ones.
I don't want software to crash or do funny things if it can be avoided. Security is nice but it comes after functionality. If it is not functional, there is no point using the software at all. It is almost like the security guys want to make everything unusable, just because things that are unusable can't be exploited.
Hire on merit (Score:2)
Code thats full of bugs is not a feature. Secure your code and have real experts help with that.
Nothing new (Score:2)
I was taught the bebugging technique during my CS degree over 20 years ago.
https://en.wikipedia.org/wiki/... [wikipedia.org]
two other problems... (Score:2)
First is this is going to contribute to code bloat and make it harder to maintain the code. I've seen a few programmers here on slashdot admit that they've had serious "WTF?" moments when reviewing their own code years or even just months later. Having deliberately non-functional code is going to make su
No (Score:2)
No. The idea is so stupid, it's not worth even discussing. It's like we haven't had 50 years of KISS concept.
This headline reminds me of Trump's tweets... (Score:2)
Dumbest idea I've heard today (Score:2)
This would be pretty stupid. Bugs are bad, mmm-kay? It would be better to just make the code convoluted and redundant but without bugs if you want to wear out attackers.
On the plus side, you'll know when to stop testing! Since you know all the bugs you planted, if QA finds all of them, you've got a great QA team doing their job, and it's likely they found the ones you did not plant as well.
This is why we need both researchers and coders (Score:2)
brilliant (Score:2)
pointy haired boss had two choices;
let's hire more programmers to add fake bugs to our programs
or
let's hire more security people to help audit and remove security issues from our programs.
his advisor tried to make it simple and steer him in the right direction, it worked so many times before.
except for this time.
Sheesh (Score:2)
I know this is Slashdot and nowadays people don't even read the summary, let alone the article, much less the actual paper [arxiv.org] to which the article links, but there's an awful lot of straw littering the floor here.
The chaff bugs are inserted by an automated tool, they will not have to be written or worked around by people writing the actual code.
The authors are aware that the chaff bugs must not be exploitable.
The authors are aware that they will face automated tools for finding bugs and determining their explo
Re: (Score:2)
the best and only response to this is
https://i.kym-cdn.com/photos/i... [kym-cdn.com]
do we need to get the Matriarchs of Computing to explain why this is a BAD IDEA to the point where it qualifies as EVIL BAD AND WRONG??
Re: (Score:2)
Microsoft already tried
I heard that it was an abject failure. They ended up with an O/S with no bugs.