Enterprises have gone from an age of vendors not patching bugs or acknowledging vulnerabilities to an age where...
a cute and entertaining name is required for every high-profile vulnerability.
These cute- and entertainingly-named vulnerabilities and attacks have gotten widespread attention outside of the information security industry, which has helped bring positive attention to many serious issues.
Shellshock is one of those vulnerabilities. In this tip, I will cover what the flaw is, the effect it has had on enterprises, and what it means for the future of shell security.
What is the Bourne Again Shell?
The Bourne Again Shell, better known as Bash, is a command-line shell and scripting language intended as a free replacement for the not freely available Bourne Shell. Bash is also a command processor that executes individual commands for user-typed command lines.
Some Bash scripts may be used for Web scripts, since it is an easy-to-use scripting language. But since it wasn't intended as a Web scripting language and there are other languages that are relatively easy to use, it is not widely used for Web applications. Any Web application using Bash would be limited to the same access as the user the script was run under, in most cases a non-privileged user. While most enterprises do not use Bash scripts for Web applications, many use Bash shell scripts in system administration tasks. Some hardware vendors also use Bash since it is easy to automate hardware maintenance tasks to include in an administrative Web interface to manage a device over the network.
The effect Shellshock has had on enterprises
The Shellshock flaw is a collection of vulnerabilities identified in Bash that allow an attacker to execute Bash commands on unauthenticated remote hosts. The vulnerabilities lie in how Bash sets and interprets environment variables used in scripts. Not all vulnerable systems have the same level of risk; high-risk systems are ones that use Bash for Web applications. However, Bash vulnerabilities can still be exploited in many other ways. Shellshock had massive media coverage from the time of its disclosure and has prompted enterprises to assess if their systems are vulnerable. As similar widespread vulnerabilities have been identified, enterprises have realized the benefits of being able to scan their networks quickly for the vulnerability and then deploy patches to a large number of systems in a timely manner. Many of the vulnerable systems may not be normally centrally managed (like IP cameras, network-attached storage and other systems) and will require manual interaction unless they are set to auto-update.
Incorporating defense-in-depth controls to a system using Bash scripts -- such as running the scripts as a non-privileged user, using SELinux or AppArmor to strictly limit what the user running Bash has access to, or using the restricted option in Bash -- could help limit the risk from Shellshock or future Bash vulnerabilities. A Web application, intrusion prevention system or next-generation firewall may also block attacks over the network.
What Shellshock means for the future of shell scripting security
Shellshock should cause software developers to migrate to secure scripting languages that are specially designed for the task at hand rather than general-purpose scripting languages. This will help limit the risks from the additional functionality of the general-purpose scripting languages. It may also prompt developers to use secure software development lifecycles, as well as include input validation and defensive programming in future developments.
The need for shell scripts will always exist, so migrating to languages that have been designed with security in mind is essential. A new scripting language named Shill was developed by Harvard researchers with a focus on security to strictly limit access to only what is needed, but it has a long way to go before it should be adopted by enterprises. Other similar languages will likely appear in the future, or similar concepts might be incorporated into other shell scripting languages.
Shellshock has brought much-needed attention to the security of open source software. Many pieces of open source software are widely used, but are supported by only minimal resources. Bash, SSL and whatever the next widely used piece of software identified with a significant vulnerability is will need additional attention and resources to ensure the long-term security of the systems they are used on.
As the open source community examines the core components of the software ecosystem, more software projects will be identified that will need additional resources to ensure the security of the system.
About the author:
Nick Lewis, CISSP, is a program manager for the Trust and Identity in Education and Research initiative at Internet2, and previously was an information security officer at Saint Louis University. Nick received Master of Science degrees in information assurance from Norwich University in 2005 and in telecommunications from Michigan State University in 2002.