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?

[Anonymous Coward]

Lets put resources i to fixing these Bugâ(TM)s bug vs the actual product. Sadly there is one Seattle company already doing this, its called legacy support

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?

[Anonymous Coward]

This is basically security through obscurity.

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?

[Anonymous Coward]

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:Are you serious?

[Anonymous Coward]

So, you're the new guy.
Yeah man.
So what exactly do you do again?
I write custom non-exploitable bugs, man.
-- crickets --

Re:Are you serious?

[Anonymous Coward]

I think this article is just an ad for Windows.

Re:Are you serious?

[Aighearach]

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.

Re: Are you serious?

[Anonymous Coward]

ChaffBleed

Re: Are you serious?

[EETech1]

And the ROP hacker nearly shits himself with all the new gadgets he has at his disposal.

Re: Are you serious?

[Zero__Kelvin]

I came here to say essentially the same thing. This also clearly assumes proprietary software as this literally can't be done with open source, which is one more advantage of FOSS.

Re:Are you serious?

[Anonymous Coward]

Depends.

Does the honey pot install a crypto miner on the hacker's system? Is so, I suppose you at least get something out of it.

Re:Are you serious?

[locater16]

It's brilliant, don't you see it? The entire application should be so confusing, obfuscated, and aggravating in how it works that anyone trying to do anything with it kills themselves just to get rid of the PTSD nightmares of trying to understand how any of it works. It's the perfect defense.

Re:Are you serious?

[Anonymous Coward]

No, this is security through sticking your head in the sand.

Re: Are you serious?

[Anonymous Coward]

Is that you, Larry Ellison?

Re:Are you serious?

[Darinbob]

At least for once I'm ahead of the game.

Re:Are you serious?

[HiThere]

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: Are you serious?

[Anonymous Coward]

Not really. It's like hiding a needle in a haystack, where STO is like hiding the key to a lock.

Re:Are you serious?

[HiThere]

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 date last copied was included in the hash code. Or perhaps the system that installed it could have a custom id that was blended into the hash code at time of installation. That would be simpler to implement, but arguably less secure.

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?

[phantomfive]

What seriously secure software are you thinking of here?

Re:Are you serious?

[Anonymous Coward]

Security through obscurity has a particular meaning -- basically, when security relies upon an attacker not understanding the underlying structure. In a combination lock or a password, you may know and understand the underlying mechanism, but without the actual password, you cannot pass through the security. Therefore that is NOT security through obscurity. And yes, security through obscurity is all bad.

The above relies upon closed source code. If the source code was open, an attacker should be able to tell the difference between bugs and weaknesses, and possibly exploit the weaknesses in the intended bugs.

Re: Are you serious?

[LostMyBeaver]

Holy sheep shit... I was like â€oeIs this a late April 1st entry?â€

Re:Are you serious?

[Anonymous Coward]

there is no such thing as "fake bugs". If you write them into the code, they are a part of the design.

Re:Are you serious?

[Hentes]

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: 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.

Re:Are you serious?

[currently_awake]

Adding complexity always increases bug count. Adding software after you screen it for bugs always increases bug count. Automated bug screening should filter out code that does nothing, so your fake bugs will be ignored.

Re:Are you serious?

[Anonymous Coward]

Plus isn't security through obscurity proven to be breakable every time?

Re:Are you serious?

[Anonymous Coward]

In other words, the bug could have a bug.

Re:Are you serious?

[Anonymous Coward]

What we need is Genetic Algorithm designed bugs that aren't actually bugs.

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

[Anonymous Coward]

This is not really obscurity...this is security through insanity. Or Security by being disgusting.

Re: Security through obscurity? So 90s

[zlives]

the Microsoft Model.

Re:Security through obscurity? So 90s

[Anonymous Coward]

I think it is safe to assume the bugs would not be in the source, but something that is added as part of the automated process to build or push to production.

Re:Security through obscurity? So 90s

[Anonymous Coward]

Yes. If you think about it, a fake bug shouldn't be exploitable and it shouldn't break any other behaviour either. Which means these aren't fake bugs, but it's just Ruby Goldberg code. Which doesn't just mean slower performance, it also means more opportunity for mistakes and thus the introduction of more actual feature breaking or exploitable bugs. And complex code tends to lead to more complex interactions so it would also make it more likely that bugs would be introduced due to two features interacting in an unexpected way that wouldn't have been possible if both features were implemented in a straight-forward manner instead of riddled with fake bugs.

Brilliant idea

[volodymyrbiryuk]

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

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

[Anonymous Coward]

This works great, until the compiler decides that your somethingThatWillNeverHappen() function is allowed to happen because of UB that occurs later in the function.

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

[Anonymous Coward]

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

So outside of the adding of bugs, it's the exact opposite of everything Microsoft does, then: they add significant bloat and they largely adversely affect both performance and behavior.

Re:Brilliant idea

[dgatwood]

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.

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 failed logins from a specific IP, you *could* make it throw an error that makes it obvious that the IP address is burned, or you could start delaying each response for an exponentially increasing amount of time so that it looks like the attack is working, but breaking the server, or you could just stop sending requests to your database entirely, and replace them with usleep() calls for about as long as a normal auth request would take, so that the bot is kept busy, but without actually expending resources meaningfully.

Or if your service stores data in a SQL database, it should always store data correctly in a way that prevents injection, but it could *also* detect obvious attempts at SQL injection and return data that makes it look like something weird is going on under the hood, so that attackers continue trying to find ways to attack working code, rather than looking for other attack vectors.

Or if your service stores data in JSON format, it could just reject malformed JSON, or you could make it deliberately drop the connection in a way that suggests a crash might have happened. (Bonus points if you provide some sort of unique server ID and can make that server ID "disappear" for a while whenever you get attacked, to fully simulate a crash.)

You could also create a fake admin account with no actual password that bots will attack continuously. You could create fake endpoints that sound like they do something juicy, but in fact, always return errors. And so on.

Re:Brilliant idea

[redmasq]

Honey-pots are not the newest idea out there; however, I might point out that actual dead-code in the binary is often removed by compilers when using higher numbers on the optimization parameter. -O1 might not remove it, but -O3 probably would (compiler dependent). I might also make note that if there is room for a buffer overflow in a library, the inside of the if statement might make an attractive jump target if is it visible to the context (probably involving setting EAX, ES, and EDI first and doing a direct far jump to the address with the current stack).

An interesting idea, but cost and risk versus benefit, I do not think it worth it.

Re: Brilliant idea

[Zero__Kelvin]

If it's code that never executes it won't be there after the compiler gets through with it without explicit pragmas that advertise the fact that said segment of code is a red herring.

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.

Re: Brilliant idea

[guruevi]

A good compiler for a sane language would simply remove the dead code. If it's not dead code, then it's exploitable.

Re: Brilliant idea

[ShanghaiBill]

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:Brilliant idea

[tofus]

Putting in 'fake' bugs that don't actually contribute to any functionality in the actual code (like your example) will not work, as most modern compilers will automatically eliminate code without an actual function.

The if-branch containing the somethingThatWillNeverHappen() function will not be part of the actual binary if the compiler deduces this code is actually never used. If the compiler does not eliminate this code, then in theory it can be part of the *actual* execution-path and it is no longer a fake bug, but an *actual* one that can be exploited.

Re: Brilliant idea

[Aighearach]

If your compiler doesn't remove that, you probably turned off optimizations.

Re:Brilliant idea

[Aighearach]

Werks is an obsolete spelling, not an error. Dumb-ass.

Re:Brilliant idea

[Anonymous Coward]

how do you know there is a bug if the "bug" is never executed?

Re: Brilliant idea

[Anonymous Coward]

EasyPeasy...

https://www.flickr.com/photos/jpallan/6543338845

Re:Brilliant idea

[jdschulteis]

The paper 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: Brilliant idea

[Anonymous Coward]

You're not very bright are you? Obviously you make it so it's impossible for the compiler to determine *at compile time* whether the code can ever be executed. It's not rocket science.

Re:Brilliant idea

[Tablizer]

Histery Notzee!

Re:Brilliant idea

[Aighearach]

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.

Re: Brilliant idea

[Anonymous Coward]

Your compiler can only optimize away code that it can see. If foo() is in a file that is compiled separately from what you are compiling now, then the compiler has no idea what foo() does, and must assume that it could return anything.

security through obscurity

[Anonymous Coward]

... literally.

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

Re:security through obscurity

[tofus]

...Not only will the actual bugs still be there, but any decent smart compiler will have eliminated all the dummy unused code from the 'fake'-bugs from the actual binary.

Sure, it may take a blackhat a bit longer to analyze the source code, but in effect all this proposal does is make the lifes of developers and QA-testers worse by making code less readable and maintainable. All for wasting a few minutes of a blackhat's time. In theory, sure it is an option. But if your project is so sensitive that it requires *this* level of protection, then chances are you want to keep your source-code as clean and readable as possible as well.

Re:security through obscurity

[Anonymous Coward]

Not only will the actual bugs still be there, but any decent smart compiler will have eliminated all the dummy unused code from the 'fake'-bugs from the actual binary.

Is everyone on here an idiot? Obviously you make it impossible for the compiler to determine at compile time if the code is executable (e.g. by making it conditional on something in a separately compiled module).

Sounds good to me

[Sqreater]

What could POSSIBLY go wrong?

Re:Sounds good to me

[Anonymous Coward]

What could POSSIBLY go wrong?

Here's one potential problem: a supposedly "fake bug" might turn out to be a real bug. Perhaps the programmer makes a tiny mistake that causes the "fake bug" to be exploitable. Or perhaps nobody can imagine that it's exploitable (just like nobody imagined that speculative execution could be exploitable), but it is! And since the software vendor has a database claiming that the bug is fake, they may not even believe reports that it's exploitable. They'll just think that a person reporting the vulnerability has been tricked by a "fake bug".

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?

Re:I don’t like to call people names, but

[Anonymous Coward]

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?

I don't exactly agree, and I think you're jumping to conclusions calling him "and idiot". There's lots of ways you could potentially make this safe, and NOT increase the complexity of the underlying software. But you're already closed your mind to any possibility this might work in some way.

What if you just wrote another layer, running on a machine completely outside of the network that listened in on the network traffic, and activated itself when it found a potential attack? i.e. someone scans your network for bugs, then redirect traffic to the fake server that's designed to waste the hackers time. Sort of like a honeypot that suddenly pops up in your real production network when it's attacked, or an application firewall that instead of blocking the user or the attack, just wastes their time giving false-positive bugs.

It DOES increase some complexity, but that doesn't have to lead to exploitable bugs. it could lead to false positives of course, but that's a different problem.

Re: I don’t like to call people names, but

[Anonymous Coward]

WTF is a non exploitable bug?

That is BS concept. Maybe if they make sure all bugs lead to a total lockup...but then they'd have to know every bug and at that point they could just patch the shit.

Re:I don’t like to call people names, but

[bluefoxlucid]

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 provides interesting opportunities for robust and flexible programming; yet as complex as this seems, polymorphism, requiring encapsulation, essentially isolates state and reduces complexity. Each part of the program achieves results by interacting with objects which are both self-contained state and the code which manages that state, reducing the amount of state in the global context. While the program still has as much (if not more) state, the code bodies affected by such state are smaller and do not interact with each others's state.

Imagine trying to introduce bugs into that. Your bugs won't be subtle. They'll be hard to hide, too. That, of course, relies on programmers adhering to those principles, and deviating in carefully-considered circumstance--meaning those windows of opportunity to introduce complex bugs get extra attention. Bugs that do appear are thus hard to spot.

Re:I don’t like to call people names, but

[Anonymous Coward]

Maybe the insertion of "fake bugs" actually exposes real bugs in compilers. Anyway the technique seems to be against the interest of any open source project as now any contributor would have to strip the fake bugs out automatically on their way to real errors (pardon the partial quote).

Re:I don’t like to call people names, but

[Wrath0fb0b]

when programmers already canâ(TM)t write bug-free code, how the heck are they going to make up 100% guaranteed non-exploitable false bug

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 -- you've got to get the tool[1] exactly right, but only in one place.

Anyway, there's a lot to criticize in the paper. But the idea that they are asking programmers to make up non-exploitable bugs is based on a fundamental misreading of what they are actually proposing.

[1] In many ways, the tool is a lot lower in complexity than other transformation tools that are currently used on mission-critical software. Certainly lower complexity than an optimizing compiler at analyzing data flows and less intrusive than some of the binary obfuscating tools used to slow down reverse engineering.

Re:I don’t like to call people names, but

[Hognoxious]

I think you're jumping to conclusions calling him "and idiot".

I could easily jump to a conclusion here. But really it's not even a jump, barely even a shuffle.

STFU, Ivan.

Re:I don’t like to call people names, but

[93 Escort Wagon]

I suppose an alternative statement - which I probably should’ve used - is “this idea is idiotic”.

Re:I don’t like to call people names, but

[Aighearach]

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:I don’t like to call people names, but

[Aighearach]

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:I don’t like to call people names, but

[bluefoxlucid]

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't versioning filesystems all the rage today? If journaling was so good, why was it only in a few filesystems for about a decade? It's in everything now.

Argumentum ad populum.

Besides that, L4/Minix would be better from a microkernel design standpoint, due to the performance of L4 and its capability-based permissions model. Minix's servers could adjust to run on L4's IPC, which gains you Minix resurrection (driver crashes are a performance issue, but don't break your system). A new kernel built from scratch around L4/Minix lessons might actually be warranted at this point: we've designed completely-different major approaches to operating systems and could implement full preemptability, checkpointing, and kernel replacement (hot patching) from the ground up. This isn't just a refactor; it's complete rearchitecting, and pretending we're "improving" an existing code base is a waste of time.

Fun considerations, but people just use Windows 95.

Re:I don’t like to call people names, but

[jdschulteis]

The chaff bugs would be inserted by an automated tool. 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.

They can't be serious

[Anonymous Coward]

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.)

Stupid people spewing stupidity.

[Anonymous Coward]

Wow. If this isn't the stupidest idea to come out of an idiot in a long time. Let's review this carefully. The suggestion is to spend time to come up with 'bugs' that are proven not to be a problem to the software. Hmm, In addition, these 'bugs' cannot be used to exploit any known and even unknown coding issue.

For those who don't have an education in writing safe software which is 90% of Android and Apple developers this alone would take up more time than it does to program an application in the first place. In fact, this is a GREAT idea for how to put exploitable bugs into programs. No one would have a clue as to why the code is present and when asked by the IT staff the answer given would be, "we don't know so it must be necessary"?

Or, better yet, Garbage in, garbage out. Let's add more garbage.

Re:Stupid people spewing stupidity.

[laurencetux]

the best and only response to this is

https://i.kym-cdn.com/photos/i...

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??

Legitimately Good Idea

[NicknameUnavailable]

But might be tough since it might only be a matter of time before someone makes a mechanism by which to filter out auto-generated "bugs."

Re:Legitimately Good Idea

[Sqreater]

I agree with this. That which a man can make a man can break.

Re: Legitimately Good Idea

[Anonymous Coward]

And generally breaking stuff is quicker and easier than creating it in the first place.

Re: Legitimately Good Idea

[Aighearach]

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.

Re: Legitimately Good Idea

[NicknameUnavailable]

I think that was his point. E.g. it's easier to break something than it is to create it for each individual instance of a thing (break or thing created.)

Isn't this called a honey pot?

[p4nther2004]

the real advantage is: when your boss comes up to you and asks about a bug...."No, no" That's a chaff bug...honest.

Oil, tobacco, ... Researchers

[Anonymous Coward]

Oil and tobacco companies did the same thing. Panic that the public is going to find out what terrible products they have, sponsor a bunch of fake research to waste everyone's time by claiming that all worries are unfounded, and take in the dough. Now security researchers want us to do the same thing? I'm all for wasting the enemy's time but the collateral damage here is again... the public. Because now everyone who would be legitimately interested in finding and fixing bugs will also be wasting their time. And if there's a "key" for finding the automatically inserted bugs and ignoring them, how would we keep this away from blackhats if the project is open source? And how will we keep users away from these fake bugs?

Same idea as a honey pot

[plague911]

This is an application of an age old conflict strategy. Tricking your enemy into thinking they have found a weakness is a well proven tactic if effort is put in to correctly prepare for the situation.

Re: Same idea as a honey pot

[Anonymous Coward]

Not exactly. A honey pot is still exploitable as hell. It just isn't connected to anything of value and is monitored.

These guys want a fantasy to be real. They want the valuable thing to be the honeypot and still be secure...you know what they say about that. Pick 2.

The whole point of a honeypot is that there are only traces or honey...

Re: Same idea as a honey pot

[guruevi]

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...

[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:Just trying to make programming perpetual...

[Anonymous Coward]

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 opposite.
SAFe is anything but, a suicide machine, etc.

What About The Real Bugs?

[Anonymous Coward]

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

[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.

Re:Hmm... more bugs the better.

[Anonymous Coward]

I guess it can work in theory, but you are adding potential vulnerabilities that you assume to be unexploitable. If you make a mistake in proving that you potentially added several exploitable bugs. I think this is a very likely outcome, since you will need to produce bugs that look very much exploitable, or they will be discounted automatically during the bad guys research phase.

Re:Hmm... more bugs the better.

[Anonymous Coward]

I've had cricket tacos, bug protein and various chocolate covered insects - they were all, in fact, quite tasty.

Re:Hmm... more bugs the better.

[Anonymous Coward]

At what point does food become 'mothy'

Microsoft

[Anonymous Coward]

Microsoft already tried it with Windows. It didn't work.

PS - Feel free to include sendmail, openssl, or tons of other projects with tons of bugs. But seriously, as others have pointed out, if we can't deal with fixing bugs, adding "safe" bugs is just a recipe for making more exploits.

Re:Microsoft

[PPH]

Microsoft already tried

I heard that it was an abject failure. They ended up with an O/S with no bugs.

Re:Microsoft

[Anonymous Coward]

Exactly. To Microsoft, security exploits are a feature.

Finally it's my time to shine.

[Anonymous Coward]

My code is full of FEATURES, boss!

Convince a Product Manager to add bugs to App?

[mykepredko]

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:Convince a Product Manager to add bugs to App?

[jdschulteis]

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

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.

How to decontaminate Flint's water

[Anonymous Coward]

Add enough kool-aid to dilute it.

I knew it all along...

[werepants]

If cramming code with bugs increases security, the code I write is incredibly secure.

Come on

[Anonymous Coward]

When did Slashdot become a "focus test my dumb idea" site? Can you make reasonably secure code that looks insecure at first glance? Sure - you just spend a relative large amount of time securing that particular code. The problem is once you've created those patterns that you know works, hackers can just exclude those same patterns from their searches. In order to be secure, they have to be predictable in terms of how they interact with the rest of the code, which makes them obvious to someone knowing what they're looking for. And even if it's less likely that these pieces of code are exploitable because of the amount of work that went into making them, you now have 100 fold more attention from the hacker community looking to break them because once you break one, you break every software they're in.

I thought honey pots involved...

[mykepredko]

Babes with big tits, speedboats and mountains of cocaine.

Otherwise, what's the point?

Re:I thought honey pots involved...

[p4nther2004]

Damn I love your post.

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.

Re: Reminds me of the old line...

[Zero__Kelvin]

You actually began the sentence that way, not ended it that way ... Idiot.

"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.

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

[Aighearach]

I am not yet entertained.

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

[skovnymfe]

Works in dev, ready for production.

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:Few "Exploits" not "Vulerabilities"

[jimbobxxx]

Correct - the number of vulnerabilities will be constant. Unless one of the fake bugs has a bug in it - making it a real one.

Re:Few "Exploits" not "Vulerabilities"

[Anonymous Coward]

But if a tree falls in the forest and no one is there to hear it, does it make a sound?

Great idea

[Anonymous Coward]

From someone that doesnâ(TM)t have to maintain the code

what the heck?

[Anonymous Coward]

What if you bug insertion tool has a bug and 1% of fake bugs you insert are actually exploitable bugs?

Remember
1) Every program contains at least 1 bug
2) Every program can be reduced by at least 1 line of code
3) By induction from 1,2 every program can be reduced to a single line of code which is incorrect.

They will create another software more.

[Anonymous Coward]

Fake bugs will bring you DIRTY source code.

Oh, yes, i did remember the god of spaghetti monster.

Rather Publish, Dolan-Gavitt should have Perished

[mykepredko]

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 virtues that would be picked apart by any competent professional knowing that others in academia will never think about the practical implications of what's being suggested.

oh my dog!

[jm007]

"... techniques to automatically put bugs into programs..."
and
"...once they had a way to fill a program with bugs..."

I think I've found my natural calling

Re:oh my dog!

[jm007]

finally!! now's there's a good reason to include some code samples on my resume

Re: oh my dog!

[Anonymous Coward]

A new job listing has emerged.

Looking for skilled bug writers. Must have 15 years experience in writing non exploitable bugs.

Re: oh my dog!

[Aighearach]

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

[TimothyHollins]

Yay, I can finally get a job as a programmer!

Hire me! Hire me!

Obligatory xkcd and Dilbert

[mykepredko]

I can honestly say that this idea is so dumb that it hasn't been parodied in the comics (yet).

Re:Obligatory xkcd and Dilbert

[Tablizer]

I can honestly say that this idea is so dumb that it hasn't been parodied in the comics (yet).

It's in the fake comics. It was put there to throw off slashdot googlers.

Re:Obligatory xkcd and Dilbert

[Anonymous Coward]

Actually, I recall a Dilbert strip in which PHB announces a bug bounty program, and all 3 group members cheer. Then the little guy who always carries his mug says, "I'm gonna code me a mini-van!"
No, I'm not going to hunt it down.

Re:Obligatory xkcd and Dilbert

[Aighearach]

http://dilbert.com/strip/1995-...

First result for "dilbert bug bounty minivan"

and the hard part?

[jm007]

putting bugs into software.... pffft.... been doing it for years now, as have most others in the biz

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

[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.

Wouldn't fake bugs be detectable?

[Anonymous Coward]

The software would know to avoid them and hackers would simply look at the code to figure it out. Got to love these security through obscurity ideas.

Re:Rather Publish, Dolan-Gavitt should have Perish

[iggymanz]

Not a problem for coder or documentation, the compiler would insert these non-bugs

this is not a new concept

[kelemvor4]

The real vulnerabilities will still be there. This is an age-old concept called "security through obscurity" and is only minimally effective.

Re:this is not a new concept

[Anonymous Coward]

is only minimally effective.

If that were even remotely true, OpSec in the sense that tools tend to throw the word around wouldn't exist.

Whut

[nehumanuscrede]

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

[gweihir]

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 much worse.

If you want to demotivate attackers, use careful input validation, input normalization and privilege separation and you are pretty much done. But these elementary measures are apparently already beyond most people writing software. And that is the real problem here. There is no magic technology that will make insecure software secure. There is only getting people that are experienced, know what they are doing and understand security write it. Nothing else will help.

Re:This is an old idea and pretty stupid

[jdschulteis]

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 cases that fail only in chaffed are probably chaff bugs. Test cases that fail only in unchaffed are probably serious trouble.

Re:This is an old idea and pretty stupid

[gweihir]

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?

[Cro Magnon]

I do that one better. My programs are full of REAL bugs.

Finally!

[NotFamous]

I was right all along - they are not bugs, they are features!

sure sure

[Anonymous Coward]

Pretty damn secure if it doesn't actually work.

Steps:

[Tablizer]

1. Get your coders all drunk and stoned.
2. Pressure them to write lots of code.
3. Have testers find all the bugs.
4. Have the (now sober) coders plug their bugs with end-point logic, but not outright remove them.
5. Profit!

Microsoft Windows

[Anonymous Coward]

This is exactly why I believe that Microsoft has the most secure OS on the market today.

That's just silly

[cshark]

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

[GuB-42]

"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.

Re:Madness from the security guys

[fish_sauce]

There is also the issue of performance. Fake bugs is code that runs and does nothing.

Until there are bugs in your bugs

[Anonymous Coward]

then you look dumb (or possibly have legal liability) for intentionally creating vulnerabilities in your code.

Or just use a better programming language!

[Anonymous Coward]

How about stopping using programming languages that enable any bug to be exploited (like C/C++), and starting using programming languages (which created in the internet age!) which naturally strong against anyone/anything exploiting any bugs???

Idiocy

[Anonymous Coward]

People who cannot write secure software are incapable of judging whether these inserted "bugs" are actually non-exploitable. Most likely, the much smarter attackers will just find a veritable cornucopia of exploits.

auto

[Anonymous Coward]

because none of this can be automated, making this claim irrelevant.

Encrypted Code

[Anonymous Coward]

This starts to sound like inserting a complex set of data to obscure the real code. Rather like encryption, only those who had the roadmap to the bogus bugs would be able to tinker safely...

Great marketing

[Anonymous Coward]

but poor engineering

Good news is we can claim that our bugs were on purpose.

Bad news is these 'safe' bugs are sort of like additional requirements on the s/w.
This adds complexity, which adds to the likely hood of more unsafe bugs.

Kelly Johnson once said never wound a bad idea, kill it dead, dead, dead.
If there ever was an idea that needed this rule, this is it.

Any odds on who with reliability issues embraces it?

dead code gets stripped

[Anonymous Coward]

so it never in anyone's execution path, so it matters not.
why look for exploits in the source when you have binaries to step through!?

NSA trying to hide their backdoor in the noise!

[Anonymous Coward]

Make it impossible for security researchers to find the NSA sanctioned holes. Good idea (if you're down with the deep state)!

Vice.com, nuff said...

[Anonymous Coward]

News for baristas, shit that's hip!

Hire on merit

[AHuxley]

and clean up your code.
Code thats full of bugs is not a feature. Secure your code and have real experts help with that.

Nothing new

[Martin S.]

I was taught the bebugging technique during my CS degree over 20 years ago.

https://en.wikipedia.org/wiki/...

What about automatic software?

[fish_sauce]

Finding bugs can be done automatically. Research is being done to use AI to locate bugs and exploit them. I can see such software with a feature to identify fake bugs aka non-exploitable bugs.

I write decoy bugs all the time

[aberglas]

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:I write decoy bugs all the time

[rtb61]

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 and software warranties are by far the shittiest warranties on the planet, to use the slashdot favourite car analogy. I seriously could imagine how bad a car would be if it was sold on the same warranty basis as the majority of closed source proprietary software, at a guess it would be bloody scary to drive at any speed over say 5km per hour, sort of the safe maximum speed at which you could leap from the moving vehicle as it starts going totally out of control. That is far more accurate than it should be.

Re:I write decoy bugs all the time

[Anonymous Coward]

Welcome to a world without software

Re:I write decoy bugs all the time

[dcw3]

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.

two other problems...

[morethanapapercert]

Others have pointed out the problems of ensuring a) that the bugs really aren't exploitable b) that the bugs are preserved by the compiler and not corrected. I'd like to add a few other sources of problems:

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 support programmers brains hurt, I just know it.

Second is: Your going to have to do a lot more testing to make sure those do-nothing bugs really are inert on your customers systems. What do you do when your code on a customers system conflicts with some obscure factor in their run-time environment? This will add another level to the "It works on our systems" problem.

Third: Software licensing terms aside, I think deliberately adding to flaws to code has the potential to open a can of worms in terms of liability.

No

[mapkinase]

No. The idea is so stupid, it's not worth even discussing. It's like we haven't had 50 years of KISS concept.

Security through chaos

[Latent Heat]

The Tesla model?

Re: Security through chaos

[Anonymous Coward]

The Feminist model.

Opportunity Cost

[Anonymous Coward]

One must ask the question: What is the opportunity cost of adding "thousands of fake bugs"?
Also, how do you prevent your programmers from accidentally fixing those fake bugs, thus not only wasting their time, but undermining your deception effort? This means you must track every fake bug and document them as features.

Yeah, this isn't going to happen in the real world. I can just imagine the software manager agreeing to create a "fake bug features database" and attempting to lasso all his programmers into referencing it every single time they make a code change. You know, so they don't accidentally-on-purpose remove that brilliant diversionary defense of a phalanx of pseudo bugs.

This has "Stupid and Impractical, Not to mention Significantly Alarming To Customers and with Detrimental Reputational Effects", written all over it.

This headline reminds me of Trump's tweets...

[mark-t]

I did a double-take and went, "like, what? did I see what I thought I saw? " And then I go and look more closely and lo, the absurdity is sincere.

Dumbest idea I've heard today

[jhoger]

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

[Floyd-ATC]

Obviously, this researchers knows nothing about how coding works. More complexity means more bugs and even intentional "harmless" bugs (if such a thing even exists) can have unintentional side-effects that could be leveraged by an attacker. And now the team of coders working on a project should all agree that "oh these bugs are there on purpose so don't fix them, just test them properly to make sure they can't be exploited".... All because of the idea that we want to waste the time of attackers who, by definition, have unlimited time. Unlike devs.

brilliant

[sad_]

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.

Re:This sounds like a form of security-thru-obscur

[TuringTest]

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.

REALLY?

[Anonymous Coward]

This is about the most half-baked idea I have seen in the programming world for ages....

Sure...

[Anonymous Coward]

It sounds good until you realize that your non-exploitable bug has a serious problem. And that, because you were lazy, that same âoefakeâ bug is used all over the place. Oops!

No

[Anonymous Coward]

No

Sheesh

[jdschulteis]

I know this is Slashdot and nowadays people don't even read the summary, let alone the article, much less the actual paper 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 exploitability.

The authors are aware that this is just a proof-of-concept and would require refinement to be useful in the real world.