Shellshock

Simply put, in order for a webpage to be available to the public, it has to be hosted on a server. You can run your own server on a personal computer, but most run on dedicated machines that are optimized to perform the tasks required of a server. The server takes care of sending page content to your browser, and can be programmed to save passwords/posts/comments, mail newsletters, perform computations, etc. Some sources estimate that roughly two/thirds of all webservers run Unix and Unix-like operating systems. This is significant because virtually all Unix and Unix-like OSs use Bash, a shell that interprets commands entered into a terminal (command line). Bash allows users (and other programs) to interact with the system at a lower level (with greater flexibility) than those using Graphical User Interfaces, but GUIs are much more user-friendly and sufficient for what most users need to get done (if you see windows, start menus, and buttons, you’re using a GUI; if all you see is a black background with lines of text, you’re in the terminal).

Bash, like all shells of note, employs environmental variables (which are analogous to shortcuts in GUIs), so if you need to access a certain file that is located in a folder that is in a folder that is in a folder(…), you can save that file’s path in a variable, rather than having to type it out every single time you enter a command. For example, if you want to write and read from a “diary” file, instead of typing out (in this imaginary file system) “read /users/me/myFiles/private/dontRead/diary.txt”, you can say “set DIARY=’/users/me/myFiles/private/dontRead/diary.txt'” and then “read DIARY” (again, much in the same way you could have a shortcut to the diary file on your desktop in a GUI without having to traverse all those folders).

Unfortunately, a bug was found in Bash recently called “Shellshock”, which has existed since Bash was first used. The bug arises from a certain sequence of characters that Bash interprets as “I finished typing in my environmental variable”, so it goes on to the next command and exeuctes it without question. As a simplified example, let’s say you have a variable storing a string: x = “variable’ perform_function()'”, and then told Bash to “set VARIABLE_NAME = x”. If Bash interpreted this as “set VARIABLE_NAME = ‘variable’ perform_function() ‘ ‘ ” (that is, used whatever was in single quotes to determine what the environmental variable was), perform_function() could be a malicious function, Bash would execute it regardless. Obviously, the exact sequence of characters is more complex (if it wasn’t, it probably would have been discovered earlier), but the vulnerability exists nonetheless, and it is possible to define the entire function within the environmental variable.

You may be thinking, well it doesn’t matter that Bash can be convinced to execute any function indiscriminately, no one using my website on my server could gain access to Bash running in the terminal. Unfortunately, some programs on the server make use of Bash functionality in order to avoid having to write their own code to, say, write to a text file, and it is through the communication between those programs and Bash that problems can arise, but it is extremely unlikely that someone could exploit this bug without explicit knowledge of its inner workings.

Average users can’t really do anything to protect against this bug, but those in charge of managing servers should be sure to update Bash (which has since been patched to display an error message when it detects suspicious activity in environmental variables). More information can be found here: https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability

Comments are closed.