What should vendors do when they discover that a hardware 0-day has been used to exploit systems built on their product?
Some vulnerabilities may permit vendors to patch the vulnerability using microcode updates. For instance, a mitigation for the row hammer DRAM attack was to reduce the frequency of DRAM refreshes (to be clear, this appears to be a firmware update not a microcode update but you get the idea). This, of course, assumes the hardware is connected, or is in a reachable location, which it usually is, but this not a very convenient mitigation.
If the root cause for the 0-day cannot be mitigated using patches, vendors may attempt to mitigate the issue by counteracting the attack method. For instance, if the exploit binary has a particular signature, traditional AV software may be used to keep it out. This is obviously a cat-and-mouse game that needs constant update of signatures and other operational difficulties, but our experience suggests that there is very limited flexibility available to the attacker to exploit hardware vulnerabilities. So using signatures may not be such a terrible idea.
Irrespective of the mitigation method, the cost of a hardware 0-day is very high to the vendor as it will either result in product recalls (a car with a unpatchable hardware 0-day is essentially a lemon), or at the very least, cause significant brand damage. Once a product is in the field, the best worst-case outcome for the vendor to know about vulnerabilities and attacks before the bad guys deploy them.
This is where bug bounty programs come in. In the software world, many companies welcome researchers to identify vulnerabilities in their products and reward researchers with a modest token bounty for finding and reporting the vulnerability. This is a rarity in the hardware world and needs to change.
One unsolicited input to hardware companies thinking about setting up bug bounty programs. Software bug bounty programs aren’t a great model for hardware 0-days: recognize that hardware 0-day bug bounty programs can prevent ‘Black Swan’ events for your company. This means that you might want to suitably reward the hardware 0-day researchers to make it profitable for them to report vulnerabilities to you rather than to questionable entities or your competitors. Also start working on mitigations for the next generation and current products right away.
If you are hardware company leave a link or comment below on your policy for hardware 0-days. Also I’d be interested in hearing how much you think researchers should get for a hardware 0-day. Drop a note in the comment. If you have further questions feel free to email me.
Finally, watch out for a paper on a new hardware 0-day by my PhD student Adrian Tang in early August at Usenix Security. This hardware 0-day, it turns out, is not a hardware bug but arises from a fundamental architecture design requirement!
About the author: Simha Sethumadhavan is an associate professor at Columbia University. His interests are in computer architecture and computer security. He is the founder of Chip Scan Inc. His website is: http://www.cs.columbia.edu/~simha
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
