What is a chaff bug? How adding bugs to apps may make them more secure

Cyber criminals prefer the path of least resistance. They want quick and easy access to your systems, and if they can’t find it they’ll move on to a more vulnerable target. So, what if there was a way to make your applications so time-consuming to exploit that it’s just not worth the effort?

In a new research paper, Chaff Bugs: Deterring Attackers by Making Software Buggier, Brendan Dolan-Gavitt, assistant professor of computer science at the NYU Tandon School of Engineering, and two PhD students, Zhenghao Hu and Yu Hu, suggest a new method of intentionally adding software bugs into code in order to deter attackers. Dubbed “chaff bugs,” the idea is to pack applications with seemingly legitimate-looking but ultimately unexploitable bugs that outnumber and obscure real vulnerabilities.

“I have friends who do exploit development professionally, and one thing they emphasize is how difficult it is to go from discovering a bug to creating a working exploit for it,” says Brendan Dolan-Gavitt. “So, we thought that this was something we could take advantage of by creating thousands of non-exploitable bugs.”

Will making software buggier deter criminals?

There will always be legitimate bugs and vulnerabilities within code despite the best efforts of developers and security teams. With chaff bugs, instead of finding a genuine flaw, attackers will discover one of the intentionally placed, non-exploitable bugs and waste their resources trying to build a working exploit. After repeatedly finding dead-ends, the hope is the attacks will give up and move on. The aim, as the paper describes it, is to “drown attackers in a sea of enticing-looking but ultimately non- exploitable bugs”.

Research by Rand Corporation suggests most exploits take a median of 22 days to develop, meaning the thought of attackers spending that much time on only a few of the hundreds or even thousands of theoretically legitimate-looking bugs only to find dead-ends could well make an application a less appealing target or a good use of resources.

The idea of leaving false breadcrumbs to fool criminals is not new and is growing in popularity.  Analysts predict the market for deception technology such as honeypots – where networks leave false targets for attackers to attack, thereby wasting their time and leaving clues around methods – could be worth over $1 billion by 2020. The idea of chaff bugs is similar in that it is designed to create decoys that attackers will find enticing.

“Where honeypots are usually designed to gather information about attacker capabilities, chaff bugs are intended to deter attackers by making it very difficult to find real, exploitable bugs in a program,” explains Dolan-Gavitt.

Dolan-Gavitt and his team developed the concept after previously working on a system called Large-scale Automated Vulnerability Addition (LAVA), which is designed to add vulnerabilities to a program with the aim of testing the effectiveness of bug-finding software. “LAVA works by analyzing a program as it processes some input and then looking for places where the program’s input data could be used to trigger a bug like a buffer overflow or other memory corruption,” he says. “Once we had this system we started thinking about what else we could do with it, and we hit on the idea of using it for defensive purposes.”

In the research around chaff bugs, the team re-used the parts of LAVA that analyze the program and how it handles its data to locate places to add bugs. In the paper, the team suggests these additions would be an extra stage in the build process to avoid added complication for the coders during application development.

“The hard part is crafting the bugs to make sure that they’re not exploitable. Since we’re initially working just with buffer overflows, we do that in two ways: either by making sure that the data overwritten by the overflow is not used by the program, or by making sure that the content of the overwrite is restricted to safe values.”

Security experts aren’t impressed with chaff

While it may be a novel concept filed under “crazy enough that it might just work,” many a developer and security expert would scoff at the idea of intentionally adding even inert vulnerabilities into their code. Dolan-Gavitt acknowledges the idea of chaff bugs has caused controversy online. “The reaction has been split between people who find it hilarious and think it just might work, and people who find it hilarious and don’t want it anywhere near their code.”

Discussions online cited concerns around increasing code complexity, inadvertently adding real bugs or bugs that could be chained to create more critical vulnerabilities, making life harder for penetration testing (as well as finding a way to securely share unchaffed or chaff-reversal code for such purposes), and the danger of reverse engineering the process has potential issues.

“If we move to a model in which security defects are less efficient to identify, we haven’t made the software any more secure – we have just slowed down finding where the problems exist,” says Paul Farrington, director of solution architecture at CA Veracode. “While chaff bugs may impede a determined attacker, we haven’t come any closer to eliminating the underlying risk.”

“I think the use of chaff bugs have a place for training purposes of up and coming security researchers,” adds Dennis Chow, CISO at consulting firm SCIS Security. “However, I do not believe they are valuable for real world, widespread use.”

Regardless of reaction from the community, research on the concept and techniques will continue in an effort to remove some of the current limitations. LAVA is already open source and the team plans to add the code around chaff bugs to the project to encourage further development. 

Chaff bugs not ready for deployment yet

The research around chaff bugs is still in its early stages, and Dolan-Gavitt admits there are still numerous drawbacks that make it currently unsuitable for production use, even if there is potential in the idea. “The main one is that the bugs are currently very artificial looking; attackers could learn to recognize what our bugs look like and then ignore them when bug-hunting,” he says.

Future work includes techniques for making the fake bugs blend in with the surrounding code as well as changing triggering conditions to make them look more authentic. The types of bugs used in the research were limited to buffer overflows; meaning attackers could simply ignore certain heap overflows. The paper identifies use-after-free, time of check to time of use, and integer overflows bugs as potential candidates for the future. “It’s also still an open question how this technique would interact with new releases of the software,” says Dolan-Gavitt. “We’d need to figure out how to re-inject the same bugs into the same places while making sure that they’re still non-exploitable.”

There is also the issue of performance trade-off. During testing with an nginx web server, the team found that adding 2,000 bugs reduced performance by around 30 percent in the of number of requests served per second. Dolan-Gavitt admits this could likely be improved with further work but argues that there are likely use cases where attacker deterrence might be worth taking the performance hit.

The paper also acknowledges making such techniques work with open source code may also be difficult. Developers are unlikely to want to work with purposefully buggy source code, and finding a way to add the chaff afterwards without giving attackers access to the pre-bugged code would be difficult.

“I think people are right to be skeptical of it at this stage – there are still a lot of research challenges to be solved,” says Dolan-Gavitt. “But we do think this is a promising area of research, and we wanted to put the idea out there to get feedback and let other people build on our research.”