Hello readers,
I am Andrea Barisani, founder of Inverse Path, which is now part of F-Secure. I lead the Hardware Security team within F-Secure Consulting.
You may have heard of our USB armory product, an innovative compact computer for security applications that is 100% open hardware, open source and Made in Italy.
We’ve recently published a Proof-of-Concept (PoC) relating to the product and a security advisory, and I’d like to take this opportunity to discuss a traditional (but always relevant) topic that I consider of critical importance in information security.
The information security community has a long-established tradition of publishing PoC code to demonstrate security vulnerabilities. This is considered a welcome and essential practice in security research for many reasons. Publishing PoC code encourages further investigation and testing of issues among vendors or other affected parties; it promotes security research; and it empowers other skilled parties to further verify the scope and impact of vulnerabilities.
The most important and compelling reason to take this approach, however, is this: In scenarios where detailed technical information has already been made public, the lack of a working PoC does not, and should not, constitute any form of “protection.”
In other words, if there is enough public information describing a security vulnerability, we must always assume that it is being actively exploited, particularly by parties holding working exploits but not so keen on their release.
This generic rule applies to software, hardware and all kind of security vulnerabilities and it can be argued even when only a little proof is given for a valid finding.
Earlier this year our friends at Quarkslab coordinated the release of two secure boot vulnerabilities for the NXP i.MX6 series of application processors.
At Inverse Path we immediately began working to convert their advisory into a working PoC so that we could assess applicability on other processors, such as the USB armory i.MX53, as well as fully understand the impact of the resulting secure boot bypass.
In little more than a man-day we were able to patch our own Open Source code signing tool to integrate a working PoC for one of the reported vulnerabilities.
This allowed us to:
-
- validate the applicability of the reported issues on a new target
- assess the complexity and time effort required to develop the PoC from the advisory contents
- fully understand the vulnerability impact and scope
- notify affected customers with full confidence of impact and mitigations
One might argue that we are putting customers who leverage the secure boot feature at risk by releasing the PoC, raising the decades-old controversy between information security researchers and parties not familiar with this kind of disclosure process.
In short: We truly are not putting customers at risk, and in fact we are doing quite the opposite.
The illusion of protection, given by the lack of a PoC and while technical details are out there, is far more dangerous than our disclosure.
In fact, especially when dealing with safety-critical industries such as avionics or automotive, which distinguish Inverse Path’s background, protection by obscurity is never an option.
The responsible disclosure of this PoC is a benefit to customers, vendors and the research community. We are proud to show that we follow such principles even when it comes to breaking our own products.
It should be emphasized that the vulnerabilities reporting, investigation and disclosure has been fully coordinated among affected parties such as ourselves, applicable CERTs, the vendor and original reporters.
If you are interested in the full details and impact of the vulnerabilities please read our full Github advisory.
If you are interested in how to abuse X.509 ASN.1 certificate parsing, you can find the gory details in our PoC function.
You might be interested to know that F-Secure promotes security research against our products and services with our own Vulnerability Reward Program, a program that is also made available to company employees that want to volunteer in hacking company products. The VRP effort is a complement, not a replacement, to the ongoing company effort to secure our products and services without compromise.
I would like to personally thank our friends at Quarkslab for the findings and coordination in handling the vulnerabilities.
It is only with this kind of harmonized cooperation, sharing the same tradition and principles, that we can help vendors as well as ourselves in improving security without relying on obscurity.
Categories