Among many developers and technology writers, it has become cliche to say that open source software is more secure than any proprietary alternative. The argument seems persuasive on the surface: The code of open source projects are visible to anyone who wants to access it. Interested parties need not be employed by any particular company involved in the development, quality assurance and marketing of the software at hand. Instead, they could, for example, just have a GitHub account and review a repository’s commits at will. With this setup, cybersecurity reviews from the community ought to be frequent and routine.
Ideally, the transparency of open source means that a large number of eyeballs constantly look at important code and find critical flaws before they are incorporated into a large-scale release. There’s a lot riding on the assumption that open source is safe – the Linux kernel, OpenStack APIs and the OpenSSL cryptographic library, to name but a few, underpin much of the current and emerging infrastructure of the Internet due to their flexibility, economy and apparent safety.
Heartbleed and Shellshock call open source security into question
But the revelatory Heartbleed flaw uncovered earlier this year challenged the prevailing wisdom about the security advantages of open source. While thousands of individuals had likely perused the freely available OpenSSL code, only a few project leaders could actually change it. Plus, their time for such review was limited by the pressure to add features – which could in turn spawn their own bugs. Heartbleed may have gone unnoticed for almost two years.
More recently, following the discovery of the Shellshock exploit in GNU Bash (after more than 20 years in the wild), servers around the world were once again at risk. Trend Micro has estimated that it could affect up to 500 million websites as well as countless IP-enabled devices, including routers and phones. The Trend Micro Security Intelligence Blog pointed out that Web servers were particularly vulnerable and that there were significant risks to OS X and most Linux distributions, which between them power more than 10 percent of PCs.
Overall, though, popular consumer hardware such as the Mac or iPhone are at less risk than Linux-based servers and embedded endpoints that can be remotely accessed with greater ease. Shellshock can and should lead to renewed conversations about network and endpoint security in the Internet of Everything.
“Many embedded devices that make up the Internet of Everything are built on embedded versions of Linux, raising the risk that they could be compromised,” explained the blog authors. “This would allow the information in these devices to be stolen, as well as for the devices themselves to be used in various malicious activities by becoming part of a botnet
What Shellshock means for the Internet of Everything
Heartbleed was a serious bug, but it was patched in short order. Shellshock not only opens up possibilities for more damaging attacks than Heartbleed did, (i.e., it allows for arbitrary execution of code) but it is also harder to fix, given the scale of affected assets as well as the security and updating infrastructure currently in place.
- In an early 2014 blog post, before Heartbleed or Shellshock came to light, Trend Micro’s Robert McArdle argued that the IoE was “the next big security challenge.” He pointed to virtual reality headsets and industrial automation systems as possible targets, illustrating how extending IP connectivity to so many new devices would necessitate fresh approaches to cybersecurity.
- A Hewlett-Packard report from August 2014 presciently estimated that 70 percent of IoE devices were vulnerable to attack. Risk factors included insecure Web interfaces, a lack of transport encryption and flawed firmware, and software update processes. Many of these issues are not caused by actual applications but by weaknesses in underlying tools such as Bash and OpenSSL.
- More than two-thirds of Web servers use an operating system with Bash installed, an estimate that Trend Micro vice president Mark Nunnikhoven echoed in recent comments about Shellshock. However, these servers are usually easier to patch than IoE devices like routers which may have a Web interface that is rarely if ever updated and often manually, rather than automatically. Popular IoE endpoints like the Raspberry Pi and BeagleBone also run OSes with Bash.
- Many users have to rely on vendors to patch their products and services. Self-patching (e.g., of a personal computer running HTTP services) is technically complicated and would not necessarily close off all vulnerable avenues.
This widespread reliance on embedded systems that may be difficult to update, along with the popularity of Bash and other open source projects, makes Shellshock a serious matter. CloudFlare CEO Matthew Prince tweeted that his company was seeing more than 1 million Shellshock attacks each day across its servers.
“[W]e don’t even have a good sense of how many systems even use Bash, and many that do have no mechanism in place for software/firmware updates,” observed security expert Frederick Lane, according to Lifehacker Australia.
What can consumers and CIOs do to protect themselves from flaws like Shellshock?
Still, as Nunnikhoven and Lane advised in the Lifehacker Australia piece, it’s important to maintain perspective. Plenty of hyperbolic language is tossed around when talking about Shellshock et al, but the basics of staying safe haven’t changed and individuals need not lose too much sleep over these exploits just yet.
Backing up files, monitoring financial information, and keeping antivirus and deep discovery software up to date are all good tenets of sound security management. There are also plenty of tools, ranging from browser extensions to server scanners, that can vet a system for Shellshock vulnerabilities.
IT administrators are already patching their systems and many will continue to do so. It may be overkill to treat Shellshock as the end of the world, but a balanced “healthy paranoia,” as suggested by Trend Micro’s guide to Shellshock, can be useful in assessing what could be affected by the bug and then making smart adjustments.