Notice: Undefined offset: 1 in /usr/local/src/wordpress/wp-content/themes/montezuma/includes/parse_php.php on line 79

About This Bash Bypass Bug

There’s been alot of news in the past couple of days about this Bash bug, some of it hysterically saying that 500 million sites could be impacted.   Well maybe that’s how many sites are running the Bash command-line utility susceptible to the bug, but only a small fraction of those are actually exploitable.   And exploitable is what matters.   This has been an issue with Bash for 20 years, since inception.

First of all, if you’re a Debian user you can relax.   Almost all scripts call /bin/sh, symlinked to /bin/dash, which does not have the vulns.

Second, what are these vulns?   The “ShellShock” bug could allow an attacker to remotely execute code on a Linux or Unix system running some configurations of Apache (those using CGIs), or the Git software version control system, DHCP network configuration, SSH, CUPS printing, or certain other software which use Bash to interact with the underlying OS.   These are each daemons which provide services to the outside world, and if you’re not running any of them you are not vulnerable.   Find out by opening a Terminal and:
# lsof -i -n -P
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
avahi-dae 987 avahi 12u IPv4 15779 0t0 UDP *:5353
avahi-dae 987 avahi 14u IPv4 15781 0t0 UDP *:45521
cups 1175 root 3u IPv4 15941 0t0 TCP *:631 (LISTEN)
exim4 2584 Debian-exim 4u IPv4 21321 0t0 TCP 127.0.0.1:25 (LISTEN)
sshd 25603 root 4u IPv4 531624 0t0 TCP *:22 (LISTEN)

Uh oh, the guy above has a problem.   Notice he’s running CUPS and SSHd, open on all interfaces.   Each of these daemons calls on Bash to do some of their functions, and could be subverted to gain complete control of the machine at the privilege level of the daemon compromised, in this case root.   For some reason these daemons are not running as a non-prived user.   The safest measure then, given that there are already hundreds of worms running around looking for this vuln, is to shut down the susceptible daemons until Bash can be updated.   And change the config of these daemons to run as a non-prived user.

Embedded devices such as wifi routers, switches, and so on, are not generally susceptible to ShellShock as most run BusyBox, a stripped-down command-line utility specifically for embedded devices, although these boxen do have a number of other vulns.   It’s just a good idea to turn off SNMP, SSH, and remote admin in these devices, or install in them a professional OS like OpenWRT with some sort of IDS, and needless to say, an effective firewall like Shorewall.

~~   The Mechanism   ~~

The way Shellshock works is, an attacker sends a request to a webserver (or etc) which uses Bash internally.   This command includes data stored in an environment variable.   In this case, the data is malformed so as to trick Bash into handling it as a command…   and that command is executed, which is the vuln.   So through offering a simple env to examine environment variables, Bash is subverted into executing any command as the user running the daemon.   And the attacker can run binaries with the same privileges as the daemon launching a Bash shell.   This is exactly why it is important to run daemons as a dead-unprivileged user whenever possible.   Some applications are not amenible to this, such as Evolution, but we do the best we can.   Security is about layers.   Don’t let amateurs talk you out of that.

Try this command:
# env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
… and you will get one of two responses:
vulnerable
this is a test

… or
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test

The first is bad of course, and the second means your env vuln has been fixed.   But that isn’t the end of it.   It’s now emerging that Bash is still exploitable, by storing malicious data in a variable named the same as frequently run commands.   Using an environment variable called cat (the name of a Unix utility which can list contents of files – catalog) one can bypass the fixes in the latest Bash patch and pass through executable commands.

The problem at the core of this constellation of vulns is that Bash’s parser automatically parses normal environment variables…   all other shells just pass them through;   so Bash was just never designed to be security-relevant.   Any change to fix this will be awkward as it will break backward-compatibility, although hopefully this won’t affect the vast majority of Bash-dependent systems.

~~   Interim Countermeasures   ~~

Until a comprehensive and vetted fix comes out, either set all listening daemons to step down their run-as user, or shut off the daemon.   If you use “ForceCommand” directives in SSH, you can’t rely on Dash if you let your users run Bash. (Effectively you allow them un-restricted shell access)   But I think you could mitigate this by forcing them to run /bin/sh instead (or let them run mksh, which is significantly more user friendly)   And if you don’t use “ForceCommand”, it doesn’t matter.

dhclient runs shell scripts in /etc/dchp/dhclient-enter-hooks.d and /etc/dchp/dhclient-exit-hooks.d, but unless something insane was done, it will execute them with /bin/sh.

As you create these non-prived users to run apps and daemons, be aware of when to set a password.   If an actual login isn’t needed don’t set a password, which will prevent login.   And set the shell only if necessary.   Many daemons and background functions don’t even need a shell, so set it to /bin/false for them.

In summary:

  • Turn off non-mission-critical daemons for now;
  • Do a dist-upgrade daily for now;
  • telnet, rsh, finger daemons, and friends must be disabled, but hopefully you did that ten years ago.
  • Check to see whether you run any bash scripts from inetd/xinetd, and if so make sure they’re calling /bin/sh.
  • Check all your custom scripts (which belong in /usr/local/bin if you’re Posix-compliant, which you should be) and make sure all are #!/bin/sh, not #!/bin/bash.
  • If you use many different non-privileged users like I do, make sure they use as their shell /bin/sh, or if it’s possible, /bin/false.   And do not set their passwords if at all possible, so a login cannot be done.

    Did you know that all these years, there has been one man maintaining Bash;    in his spare time,   as a project?    With no pay?   And 500 million people and companies are using it?   To make a more stable and secure technology environment, we have to peel back the layers, start at the bottom and work up.   I advocate a microkernel architecture.   Or at least Xen.

    ,'after' => '

    ') )