Shell shock

Skip Navigation

Shell shock

/ September 25, 2014

In this article I want to spend a few words about the Bash ShellShock Remote Code Execution Vulnerability CVE-2014-6271 that shook the interwebs security people yesterday. I will give a very brief description of the vulnerability and how we protect the Mendix infrastructure from this sort of vulnerabilities.

It is a constant battle

Everyday an army of system administrators, developers and operators fight their silent battle against chaos, entropy and malfunctions to keep services up and running so everybody on the internet can safely do their own serious business like transfer millions of dollars, break the latest news, create a new startup and browse kitten pictures.

Since the beginning of time (a.k.a. Thursday, 1 January 1970), these brave men and women have built their own weapons to help them fight the fight. New weapons are invented everyday, but some of them proved to be so effective that are still in use nowadays. This is the case of the Bourne-again Shell, or Bash, arguably the most widespread Unix shell in use today.

A Unix shell is truly something mighty, a sort of interpreter between man and machine: enter a command in form of text and that command results in an action executed by the computer. It might be the command that fixes the nasty bug that prevents your internet page to render, or retrieves the content of a folder on your hard drive, or even turns off the computer itself. Pretty much everything can be done. Mastering the Unix shell is the most valuable way to survive in the heat of the battle.

All your bash are belong to us

But what would happen if this very same weapon would get seized by the enemy and turned against you? With such a powerful weapon in the enemy’s hands we would be doomed: no more money transfers, no more news sites, no more cool startups, no more kittens!

And unfortunately this is exactly what happened yesterday: a vulnerability has been found in Bash which would allow anybody, including the enemy, to execute every command they want!

The problem lies in how Bash handles certain commands. Here is an example:

env VAR='() { disregard;}; echo ALL YOUR BASH ARE BELONG TO US!' bash 

What this command does is invoke an execution environment in which a variable (VAR) is defined, in this variable there is a function definition specifically crafted to trick Bash and trigger the wrong behaviour. If we append a command after the function definition () { disregard;};, then that command gets executed! This is horrible! In the example the command simply outputs some innocuous text, but it could be literally anything!

To make the situation even worse, consider that some applications on the web (CGI applications) are ultimately sending commands to Bash to perform their tasks. In these scenarios anybody could trigger a different behaviour instead of the intended one, gather protected information or disrupt services for fun and profit.

Luckily, this nasty vulnerability has already been fixed and patches are available for the vast majority of operating systems.

Be vigilant, be safe

The enemy never sleeps, but we do. So how can you safely sleep at night if something like this can happen? Well, to counter powerful enemies you need powerful allies. That is why here at Mendix we put our machines to work for us. Our systems are able to receive software updates directly from the maintainers of the operating systems we use. If there is any security patch that fixes some bugs that the enemy could use to infiltrate our network, we can readily apply it. But there is more: the best part is that our systems can do that automatically, by themselves, keeping the infrastructure safe even while we sleep.

If you want to protect yourself from the enemies enabling unattended upgrades on your Debian based hosts, you can simply install the related packages:

apt-get install unattended-upgrades

And configure which upgrades you want to receive automatically by editing the configuration file /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Origins-Pattern {
        // Archive or Suite based matching:
        // Note that this will silently match a different release after
        // migration to the specified archive (e.g. testing becomes the
        // new stable).
        "o=Debian Backports";

You can even prevent the updating of specific packages by blacklisting them in the same configuration file:

// Regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
    // The following matches all packages starting with linux-
//  "linux-";

    // Use $ to explicitely define the end of a package name. Without
    // the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

    // The following matches packages like xen-system-amd64, xen-utils-4.1,
    // xenstore-utils and libxenstore3.0

    // For more information about regular expressions, see

A note on blacklisting: as stated in this bug report, the expressions in the list of packages to blacklist are actually treated as regular expressions, therefore you risk to blacklist packages that you actually want to upgrade. For example, ‘vim’ would also blacklist any other “vim-*” package, including plugins that you might want to keep up to date.

Finally, to have apt periodically fetch the list of package updates and perform the upgrades, you can enable the relevant options in the apt-cron configuration file /etc/apt/apt.conf.d/02periodic like this:

#  APT::Periodic::Update-Package-Lists "0";
#  - Do "apt-get update" automatically every n-days (0=disable)

APT::Periodic::Update-Package-Lists "1";

#  APT::Periodic::Unattended-Upgrade "0";
#  - Run the "unattended-upgrade" security upgrade script 
#    every n-days (0=disabled)
#    Requires the package "unattended-upgrades" and will write
#    a log in /var/log/unattended-upgrades

APT::Periodic::Unattended-Upgrade "1";

Also, quit using CGI applications, if you can.

Copy link