Shellshock is a serious vulnerability. Bash, arguably the most widely distributed shell on Linux systems, fails to correctly parse environment variables with function declarations. Why the fuss over environment variables? Because these variables are often set by programs that handle network data. Examples include dhcpcd which, through this vulnerability, more or less gives you a remote shell through DHCP option 114 (and potentially others) and Apache using mod_cgi or mod_cgid when CGI scripts are either written in Bash, or otherwise spawn subshells with exported data acquired from untrusted sources -- to name a few.

The problem is located in variables.c

void
initialize_shell_variables (env, privmode)
     char **env;
     int privmode;
{
[...truncated...]

If an environment variable starts with the string "() {" then initialize_shell_variables() interprets it as a function definition:

if (privmode == 0 && read_but_dont_execute == 0 &&
    STREQN ("() {", string, 4))
 {
 string_length = strlen (string);
 temp_string = (char *)xmalloc (3 + string_length + char_index);
 strcpy (temp_string, name);
 temp_string[char_index] = ' ';
strcpy (temp_string + char_index + 1, string);

To define the bash function, the rest of the string is passed to the parse_and_execute() function.

if (posixly_correct == 0 || legal_identifier (name))
 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);

The problem here is the rest of the string is assumed to hold only a function definition, and is passed without sanitation to parse_and_execute().

builtins/evalstring.c

/* Parse and execute the commands in STRING.  Returns whatever
   execute_command () returns.  This frees STRING.
[...truncated...]
int
parse_and_execute (string, from_file, flags)
     char *string;
[...truncated...]

However, parse_and_execute() does not stop processing when it reaches the end of the function definition. Bash ends up executing all the commands in the string, even after the function definition. In essence, if an attacker can control an environment variable in a program that will spawn a shell with an environment containing that variable, command injection is possible. Since the original discovery of the vulnerability (CVE-2014-6271), the first fix has been found to be incomplete (CVE-2014-7169). Detection for the vulnerability condition (including CVE-2014-6271 & CVE-2014-7169) can be found in SIDs 31975-31978 & SID 31985.

We have observed attacks attempting to load ELF binaries onto possibly vulnerable targets via wget. ClamAV offers protection from this threat under the name "Linux.Flooder.Agent".

The following ELF binaries have been observed in the wild so far:

2d3e0be24ef668b85ed48e81ebb50dce50612fb8dce96879f80306701bc41614
3b13eef9b24919dc7e7071068a83defcc4808a41dc86fadf039e08dce1107f7d
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489
ae3b4f296957ee0a208003569647f04e585775be1f3992921af996b320cf520b

We'll be writing more on this subject early next week as we collect more information about the attacks we are seeing in the wild.