shellshock and the B2/3

[Ubi]

There's been a few threads on the shellshock bug already. This thread is meant to discuss the impact that this bug has on the default installation of the B3, not on theoretical implications that the bug could have in modified systems

Be aware that in principle (at this stage at least) it is only useful to look for web pages that have public exposure (i.e. that do not require login). This is on the assumption that malicious users do not get a login from you, and if attackers can login your problems are much bigger than the shellshock bug. Below however is an analysis of the complete "Bubba front-end" code, just to be complete. The code can be downloaded here:https://github.com/excito

Good news is that there aren;t that many pages accessible by the public.

[Ubi]

I found https://securityblog.redhat.com/2014/09 ... on-attack/ to be well worded:

Code: Select all

The vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the Bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:

    ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
    Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in Bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
    PHP scripts executed with mod_php are not affected even if they spawn subshells.
    DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
    Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
    Any other application which is hooked onto a shell or runs a shell script as using Bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Fortunately, the B2/3 software is mostly written in perl and php, and there has been a lot of sanitation. For example, spawn.php restricts the header that are allowed to propagate:

Code: Select all

export FCGI_WEB_SERVER_ADDRS
...
export PHPRC
ALLOWED_ENV="PATH USER"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS FCGI_WEB_SERVER_ADDRS PHPRC"

# copy the allowed environment variables
E=
for i in $ALLOWED_ENV; do
  E="$E $i=$(eval echo "\$$i")"
done
...

the subshell command "shell_exec" is not used, but "exec", is used 12 times. If 'exec' inherits environment vars from PHP (which it should not do according to spec, as described above), then this could pose an attack vector.

Question is what happens to the environment vars from the HTTP request and how these are parsed in the front-end. Apache conveniently takes the USERAGENT and HOST vars and puts these in the environment. Not much you can do here if you run a bash-based CGI script. The B3 however does not have bash CGI scripts by default (I havent found any yet). There is upload.cgi and php5, both in /usr/lib/cgi-bin. Both these files are not vulnerable through e..g. this test:

Code: Select all

curl -k -H 'User-Agent: () { :;}; echo aa>/tmp/aa'  https://localhost/cgi-bin/php5

. This logs to

Code: Select all

127.0.0.1 - - [26/Sep/2014:14:41:52 +0200] "GET /cgi-bin/php5 HTTP/1.1" 500 2088 "-" "() { :;}; echo aa>/tmp/aa"

[Ubi]

As for perl, I did not find any system calls in the perl scripts yet.

[Ubi]

Let's say we want to actually patch this bug , somebody already helped us out:

http://martin-jones.com/2014/09/25/deal ... e-for-arm/


Here is also a redhat code patch for the bash 4.1 branch (the B3 has 4.1.5)

Code: Select all

*** ../bash-4.1.11/builtins/common.h	2009-12-22 16:30:42.000000000 -0500
--- builtins/common.h	2014-09-16 19:27:38.000000000 -0400
***************
*** 36,39 ****
--- 36,41 ----
  
  /* Flags for describe_command, shared between type.def and command.def */
+ #define SEVAL_FUNCDEF	0x080		/* only allow function definitions */
+ #define SEVAL_ONECMD	0x100		/* only allow a single command */
  #define CDESC_ALL		0x001	/* type -a */
  #define CDESC_SHORTDESC		0x002	/* command -V */
*** ../bash-4.1.11/builtins/evalstring.c	2009-10-17 21:18:50.000000000 -0400
--- builtins/evalstring.c	2014-09-16 19:27:38.000000000 -0400
***************
*** 262,265 ****
--- 262,273 ----
  	      struct fd_bitmap *bitmap;
  
+ 	      if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)
+ 		{
+ 		  internal_warning ("%s: ignoring function definition attempt", from_file);
+ 		  should_jump_to_top_level = 0;
+ 		  last_result = last_command_exit_value = EX_BADUSAGE;
+ 		  break;
+ 		}
+ 
  	      bitmap = new_fd_bitmap (FD_BITMAP_SIZE);
  	      begin_unwind_frame ("pe_dispose");
***************
*** 322,325 ****
--- 330,336 ----
  	      dispose_fd_bitmap (bitmap);
  	      discard_unwind_frame ("pe_dispose");
+ 
+ 	      if (flags & SEVAL_ONECMD)
+ 		break;
  	    }
  	}
*** ../bash-4.1.11/variables.c	2010-03-26 12:15:39.000000000 -0400
--- variables.c	2014-09-16 19:27:38.000000000 -0400
***************
*** 348,357 ****
  	  strcpy (temp_string + char_index + 1, string);
  
! 	  parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
! 
! 	  /* Ancient backwards compatibility.  Old versions of bash exported
! 	     functions like name()=() {...} */
! 	  if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
! 	    name[char_index - 2] = '\0';
  
  	  if (temp_var = find_function (name))
--- 348,355 ----
  	  strcpy (temp_string + char_index + 1, string);
  
! 	  /* Don't import function names that are invalid identifiers from the
! 	     environment. */
! 	  if (legal_identifier (name))
! 	    parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
  
  	  if (temp_var = find_function (name))
***************
*** 362,369 ****
  	  else
  	    report_error (_("error importing function definition for `%s'"), name);
- 
- 	  /* ( */
- 	  if (name[char_index - 1] == ')' && name[char_index - 2] == '\0')
- 	    name[char_index - 2] = '(';		/* ) */
  	}
  #if defined (ARRAY_VARS)
--- 360,363 ----

[MouettE]

I recompiled the patched bash version from debian squeeze-lts. All the files and sources are here :

bash_4.1-3+deb6u2_armel.deb
bash-builtins_4.1-3+deb6u2_armel.deb
bash-doc_4.1-3+deb6u2_all.deb
bash-static_4.1-3+deb6u2_armel.deb
bash_4.1-3+deb6u2.diff.gz
bash_4.1-3+deb6u2.dsc
bash_4.1-3+deb6u2_armel.changes
bash_4.1.orig.tar.gz

Quick how-to :

Open a ssh root session on the b3, download the main debian package and install it :

Code: Select all

wget http://files.la-mouette.net/bubba/bash_4.1-3+deb6u2_armel.deb
dpkg -i bash_4.1-3+deb6u2_armel.deb

You are more than welcome to test it on your b3s !

[Ubi]

You beat me to it =)

I confirm that your package works on my B3 and passes the shellshock test. Thanks for this work MouettE!

[bIO]

I spent the last night digging around the ShellShock bug (CVE-2014-6271) and its follow-up CVE-2014-7169. Since the supposed patch for the latter was not integrated at that time, I patched the parse.y source myself and built bash from source.

Now that the second update is there (bash_4.1-3+deb6u2, which also contains variables-affix.patch and parser-oob.patch) MouettE did a quick job at supplying a package for the B3 even though it might not be at immediate risk.

@MouettE: Just for the sake of completeness, could you fix the link for bash_4.1-3+deb6u2_armel.changes?

This fix is not supplied via automatic update, maybe we should add the quick how-to to apply the update to the Wiki.

Regards
bIO

[Ubi]

Because the update server is in transition, it may take a while for this fix to be included. So tjanks biO for making this howto and wiki page

[MouettE]

@MouettE: Just for the sake of completeness, could you fix the link for bash_4.1-3+deb6u2_armel.changes?

Done !

[bIO]

Because the update server is in transition, it may take a while for this fix to be included. So tjanks biO for making this howto and wiki page

Who is responsible for granting Wiki access? johannes?

[johannes]

yep, appears so. Request granted now!

[bIO]

yep, appears so. Request granted now!

Thank you. Wiki entry added: http://wiki.mybubba.org/wiki/index.php?title=Security