Heartbleed, Shellshock, and Erosion of Third-Party Trust
TL;DR
- Today’s software inherently depends on unreliable computer code. Devices that have the ability to impact public safety and human life should have a trust model based on assurance, not assumption.
- Our failure to manage the software supply chain undermines our ability to predict and manage effects of root cause issues like Shellshock and Heartbleed. A necessary component of reliable, trustworthy devices must be an accounting of the software supply chain.
If you’ve been paying attention to information technology and security media lately you’ve probably heard of a bug called Shellshock. This term refers to a specific vulnerability in software code written over 25 years ago. This particular computer software – a program called Bash – has made its way into dozens of computer operating systems across millions of systems and devices.
As far as we know, the Shellshock vulnerability has only been discovered within the past month. We also know that this bug has the highest severity, and allows for complete takeover of the affected computer or device. What we don’t necessarily know is which systems, to what degree they are affected, and whether the vulnerability in each of these systems could be triggered by malicious attack.
Shellshock isn’t a unique phenomenon. Since the vulnerability first became publicly known, a new one has been found in the same software package that gave us the Heartbleed vulnerability.
We are increasingly adopting computer technology into devices we depend on. Computer software is becoming a fundamental component of medical devices, automobiles, public infrastructure, and home electronics. Computer software is complex, and is not flawless. When flaws are exposed, the software tends to fail in complex ways with unpredictable behavior. Unpredictable behavior in a fundamental component of a device leads to a cascade of unreliability.
Manufacturers understand that no matter where its components come from, they have the ultimate responsibility for quality and reliability. To make a reliable device, each component must be trusted to perform predictably. This is why they spend so much time and effort on assuring the quality of what they receive through their internal or third-party supply chain. As computer technology is increasingly transplanted into devices, software is a critical component in these supply chains. And yet scrutiny of the software component of devices has not yet caught up to quality control of other pieces.
We must improve the quality and traceability of software components in devices that have the ability to impact human life and public safety. A recipe for this will have the following ingredients:
- A Secure Software Development Lifecycle helps ensure that the computer code in our supply chains is relatively free of severe defects. This allows us to prevent failures.
- A supply chain inventory, or bill of materials, allows mapping of issues to impacts. We can reliably say what computer code exists on which systems, and what functionality depends on it. This allows us to understand how systems will be affected when flaws are found in computer code.
- Implement a secure and safe way to fix software issues after device release or deployment. This protects safety at a greatly reduced cost, as compared to a recall.
- Openly share knowledge of issues and their fixes, among security researchers, manufacturers, and the public. This enables manufacturers to benefit from the decades of experience securing a software supply chain. It also puts power and responsibility into the hands of the device owners on when and how to apply the fix.
Shellshock and Heartbleed are subsets of bigger issues. We are increasingly depending on systems, undermined by unreliable software supply chains. This leads to an erosion of trust among manufacturers, their suppliers, consumers, the government, and others.
These are not intractable problems. We must think long term. We must keep pushing. We must focus on that which matters. We must lead in areas we care about.
We can get started on this today, and everyone can help. Work towards these things in your own organization and with those in your supply chain. Advocate good practices to others in your industry or a different one. Team with others (like I Am The Cavalry) looking to do the same.
Source Links and Further Reading
https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html#.VCuKZildVDk
http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html#.VCuKryldVDk
http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html#.VCuK0SldVDk
http://en.wikipedia.org/wiki/Shellshock_(software_bug)
http://www.technologyreview.com/view/531286/why-the-shellshock-bug-is-worse-than-heartbleed/
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
Also thanks for contributions to the article by:
Jeff Jarmoc (@jjarmoc)
Tim Anater (@bfbcping)
Dennis Groves (@degroves)
