Interesting paper: "Chaff bugs"

[jim mcnamara]

https://arxiv.org/abs/1808.00659
Popular version: https://techxplore.com/news/2018-08-defensive-technique-software-buggier.html

The basic idea here is to create a large number of non-exploitable bugs, then add them to existing code. Do not worry as much about remediating existing bugs.

The "bad guys" have a greatly reduced chance of finding and exploiting a real bug because they keep finding chaff bugs instead. Wasting resources. The most time consuming task facing intruders is locating bugs to exploit. Analogy: It is like having a tub of cubic zirconium "diamonds" with one or two real ones mixed in. Finding the real diamonds takes a large amount of time. Cubic zirconium fakes can be detected but takes some time. If it becomes sufficiently tedious it may not be worth the huge amount of time spent.

Abstract:

Sophisticated attackers find bugs in software, evaluate their exploitability, and then create and launch exploits for bugs found to be exploitable. Most efforts to secure software attempt either to eliminate bugs or to add mitigations that make exploitation more difficult. In this paper, we introduce a new defensive technique called chaff bugs, which instead target the bug discovery and exploit creation stages of this process. Rather than eliminating bugs, we instead add large numbers of bugs that are provably (but not obviously) non-exploitable. Attackers who attempt to find and exploit bugs in software will, with high probability, find an intentionally placed non-exploitable bug and waste precious resources in trying to build a working exploit. We develop two strategies for ensuring non-exploitability and use them to automatically add thousands of non-exploitable bugs to real-world software such as nginx and libFLAC; we show that the functionality of the software is not harmed and demonstrate that our bugs look exploitable to current triage tools. We believe that chaff bugs can serve as an effective deterrent against both human attackers and automated Cyber Reasoning Systems (CRSes).

The red-highlighted phrase seems to me to be the hard part. Disguising the fake bugs. If all of the fake bugs are similar somehow then one can write algorithms to find and then mark the fakes as fake.

 

[anorlunda]

I see. Pretty clever. Good name too: chaff.

But I'm skeptical if it would really work unless the benign bugs were very cleverly designed. Clever design means taking design effort away from the legit purposes of the code. I can't see management ever approving that.

 

[jedishrfu]

I think it’s too early to say here that it can be defeated so easily and it’s too early to say if it will even work. I am reminded of all the “junk” dna we carry which might come back into play at some time in the future.

If the hacker had access to the source then this would be harder to hide as someone would inevitably leave a helpful comment. However, if this is inserted into the binary executable with blocks of junk code then it could make reengineering more difficult. If we could also insert code that makes it difficult for a debugger to follow then that too would make it more difficult to figure out. The downfall of course is the allgorithm doing the insertion. It would give hackers a key to figuring out what code to ignore in the obfuscate binary.

 

[Vanadium 50]

The basic idea here is to create a large number of non-exploitable bugs, then add them to existing code. Do not worry as much about remediating existing bugs.

Microsoft has been trying this strategy for years.

 

[jim mcnamara]

@Vanadium 50 - do you have some kind of link for that? You would think the researchers could have been aware of it.

 

[anorlunda]

@Vanadium 50 - do you have some kind of link for that? You would think the researchers could have been aware of it.

No no. V50's post was sarcasm.

 

[jim mcnamara]

Well, duh...

 

[Rive]

I see it a little bit problematic that unfortunately the bug-hunt of end-products are often made by security specialists not related to the owner of the code. Their work also will get harder, no?
For me this idea quite sounds like a big rug to cover up the real issue instead of addressing it.

 

[sysprog]

Maybe this is why some programmers use "foo" for an arbitrary character string:
Name: Tom Foo Lery
Occupation: bug coder

 

[Baluncore]

No no. V50's post was sarcasm.

If the response to bugs is to throw more programmers at the project, then those programmers will probably measure their productivity in lines of code written per month. That will increase the total number of bugs in the project code base.
Very rarely will you find an analyst who can work out how to partition the project into testable chunks, then find and fix the bugs.
Read "The Mythical Man Month" by Frederick Brooks.
https://archive.org/details/mythicalmanmonth00fred

 

[anorlunda]

Read "The Mythical Man Month" by Frederick Brooks.
https://archive.org/details/mythicalmanmonth00fred

I loved that book. Haven't heard it mentioned in years.