Bash Vulnerability Code Injection Attack

bash_ld_preload.c

#include <sys/types.h>
#include <stdlib.h>
#include <string.h>

static void __attribute__ ((constructor)) strip_env(void);
extern char **environ;

static void strip_env()
{
	char *p,*c;
	int i = 0;
	for (p = environ[i]; p!=NULL;i++ ) {
		c = strstr(p,"=() {");
		if (c != NULL) {
			*(c+2) = '\0';
		}
		p = environ[i];
	} 

}

• Compile it:

gcc bash_ld_preload.c -fPIC -shared -Wl,-soname,bash_ld_preload.so.1 -o bash_ld_preload.so

• Copy bash_ld_preload.so to /lib:

cp bash_ld_preload.so /lib/

If you wish to apply this workaround across the entire system:

• Add the following to /etc/ld.so.preload on a line by itself:

/lib/bash_ld_preload.so

• Restart all relevant services or reboot the system.

Note that this is potentially very dangerous. It is recommend that you just apply this workaround to specific services that may be exploitable on your system. This can be achieved by adding bash_ld_preload.so to the LD_PRELOAD environment variable in the script that will initialize the service. For example, for httpd on Red Hat Enterprise Linux 6:

• Add the following two lines at the top of /etc/init.d/httpd, after the #! line:

LD_PRELOAD=/lib/bash_ld_preload.so
export LD_PRELOAD

• Then restart httpd:

service httpd restart

Workaround: Using mod_security:

The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.

Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

These may result in false positives but it's unlikely, and they can log them and keep an eye on it. You may also want to avoid logging as this could result in a significant amount of log files.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

 vulnerable

 this is a test

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

 bash: warning: x: ignoring function definition attempt

 bash: error importing function definition for `x'

 this is a test

출처 : access.redhat.com