Identifying Backdoors in Production-Ready Code

By Ido Sarig

Ido Photo

The security world is abuzz with news about a “backdoor” – undocumented  access to its programmatic interface –  found in a popular FPGA manufactured in China and used in US military applications.

Whether you are concerned that this is a deliberate Chinese plot to attack Western militaries, or relieved to hear that this is just a "common" backdoor, put in for debugging purposes, you should take note of the following:

"Backdoors are a common problem in software. About 20% of home routers have a backdoor in them, and 50% of industrial control computers have a backdoor. The cause of these backdoors isn't malicious, but a byproduct of software complexity. Systems need to be debugged before being shipped to customers. Therefore, the software contains debuggers. Often, programmers forget to disable the debugger backdoors before shipping.” 

Sometimes, this is not an inadvertent omission. Developers may deliberately leave “test APIs” in the code, thinking it may be useful in the future, for diagnostics, should a problem surface at a customer site.

One of the key benefits of an automated software testing solution is its ability to easily identify such debug APIs and backdoors that are inadvertently (or worse – deliberately!) left in production code.  For example, Wind River Test Management can analyze uninstrumented, production-ready binaries – the same code you will be shipping to your end users after all the “debug only” APIs should have been removed – and provide you with detailed reports on the coverage achieved by your entire test suite running against that binary image. If there are any “debug-only” APIs in the code, they will typically not be touched by any of your  test cases, since they have no requirements associated with them and hence no test cases to validate those requirements. They will be quickly highlighted by Wind River Test Management’s reports.

Additionally, using Wind River Test Diagnostics (a system that links product development teams in an intelligent, collaborative workflow so they can efficiently validate embedded devices and rapidly resolve issues) you do away with the need to leave such backdoors in the code for diagnostic purposes in the first place. Utilizing our patented Sensorpoint technology, Wind River Test Diagnostics can dynamically add diagnostic code  to a running, uninstrumented binary, delivering you with all the needed diagnostic information without the security risk of a backdoor.

The good news is that when issues like this arise, it gets the conversation started, and it is a very important conversation to be having.  I’d be interested know what you’re hearing.

 

For additional information from Wind River, visit us on Facebook.

1 Comment

  1. McNowel

    The wind doesn’t start blowing just bacsuee you turned on a switch so you’re gambling that wind energy would be available when you need it. There’s a capital investment in both land and in the generator itself, there’s maintenance, there’s transmission costs, basically it amounts to a high startup cost, a constant operational cost but results in a variable uncontrollable generation of energy. The risk is that you won’t have the power when you can sell the power and you may have too much power when you can’t sell the power.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>