Bash "shellshock" CVE-2014-6271 CVE-2014-7169

syg00 · 09-24-2014, 07:52 PM

http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

Worse than Heartbleed due to the number of exposed systems some claim.

ilesterg · 09-25-2014, 01:39 AM

Ok, so this news got me this morning. Basically, it says bash can be exploited to gain control of the shell.

From what I have gathered to far, the following can be used to test if your machine is vulnerable:

Code:

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

CentOS has immediately released a patch solve this issue.

CentOS update

Refs:
CERT
GNU

Can anyone please share what they know about this bug?

yooy · 09-25-2014, 03:25 AM

i run all upgrades on my ubuntu but according to test it is still vulnerable.

evo2 · 09-25-2014, 03:34 AM

Hi,

Quote:

Originally Posted by yooy

i run all upgrades on my ubuntu but according to test it is still vulnerable.

The Ubuntu Security Notice USN-2362-1 indicates they have fixes for the LTS releases.

Evo2.

Guttorm · 09-25-2014, 03:49 AM

For this bug to be exploitable from remote, you need to have a bash script that can be run from remote. A cgi script using bash is vulnerable. Fortunatly, the default shell is usually not bash anymore, and bash cgi scripts are not common.

I worry more about embedded systems with web interfaces.

tux100 · 09-25-2014, 07:22 AM

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true

My servers are RHEL 6.

If the bash is vulnerable, should I

A) download the latest patched bash rpm and install it ?

B) or can I safely yum upgrade ONLY the patched bash package ?
I do not want to update/upgrade anything other than bash.

C) Some sources say a reboot is required, some say a ldconfig will suffice. Does option A or B require a reboot or an ldconfig only ?

sag47 · 09-25-2014, 07:47 AM

First determine if you're affected. Do you have restricted users connecting via public key auth forced to execute a script rather than be dropped into a shell? If not then this vulnerability doesn't affect you much.

If so first update and determine if it has already been fixed.

Code:

# https://access.redhat.com/node/1207723
sudo yum update bash
sudo /sbin/ldconfig
rpm -q --changelog bash | grep CVE-2014-6271

If you can't do that then switch the shell of the user away from bash to csh, ksh, or zsh.

szboardstretcher · 09-25-2014, 09:35 AM

This has not been updated since yesterday, so realize that there is more information out there about the bug, and more fixes and patches now. Go seek them.

This is a good starting point, but IT IS NOT an exhaustive resource.

Vulnerability:
Shell shock - Bash Bug - Bash Attack

CVE
http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

Breakdown:

Quote:

The vulnerability is caused by the ability to create environment variables with values before calling the bash shell. The variables that are passed can contain code, which are executed before the shell is actually invoked. The vulnerability is then exposed in the ability to add extra code to the end of these functions.

More info:
The bug can currently be exploited through externally facing WEB servers as well as anything that listens to the world at large and sends variable info to bash. Current 0-day's include vuln scanning for Cpanel and other well known CGI scripts on the net.

The CURRENT primary attack vector is old CGI scripts.

http://seclists.org/oss-sec/2014/q3/650

There is already a worm being found based on the exploit:
https://gist.github.com/anonymous/929d622f3b36b00c0be1

As of last night there is a metasploit module to exploit the bug (brace yourselves for the script kiddies):
https://github.com/rapid7/metasploit...faf4c0d6912575

Additional info:
https://community.rapid7.com/communi...-cve-2014-6271
https://securityblog.redhat.com/2014...ection-attack/
http://lcamtuf.blogspot.com/2014/09/...ts-impact.html
http://www.smittix.co.uk/fedora-20-u...cve-2014-6271/
http://arstechnica.com/security/2014...ith-nix-in-it/
https://access.redhat.com/articles/1200223

Options:

Upgrade BASH to a patched version
Use a different shell than BASH
Disable mod_cgi
Use rules to block nefarious requests

Patches:
MANUAL Patch for Debian 6:

Code:

# check to ensure vulnerable
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
# make sure you are on debian 6
cat /etc/issue

# add the LTS sec repo
echo "#LTS security" >> /etc/apt/sources.list
echo "deb http://http.debian.net/debian/ squeeze-lts main contrib non-free" >> /etc/apt/sources.list
echo "deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free" >> /etc/apt/sources.list

# update and install patched bash
apt-get update
apt-get install bash

# run a new shell
bash
# check patch success
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

MANUAL Patch for Debian 7:

Code:

# check to ensure vulnerable
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
# make sure you are on debian 7
cat /etc/issue

# update and install patched bash
apt-get update
apt-get install bash

# run a new shell
bash
# check patch success
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

MANUAL patch for Centos 6/7

Code:

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

yum -y install bash
or 
yum -y update

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

Red Hat mod_security rules: (https://access.redhat.com/articles/1200223)

Code:

#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

#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.

tests:
# check, if 'vulnerable' appears, then you are vulnerable

Code:

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

# rpm based systems

Code:

rpm -q --changelog bash | head
 # if you are running a patched version, you should see this:
 * Mon Sep 15 2014 Ondrej Oprala <ooprala@redhat.com - 4.1.2-15.1
 - Check for fishy environment
   Resolves: #1141645

suicidaleggroll · 09-25-2014, 10:15 AM

I do have a system with a web interface that runs a bash script, however the user on the web page has no control over the bash script that's run, arguments to it, environment variables that might be in place, etc. They just click a button and internally a bash script is called.

I can't imagine this would be susceptible since the user can't set any environment variables on the system before/during/after the script is called, but I would just like some confirmation.

Habitual · 09-25-2014, 10:49 AM

Quote:

Originally Posted by Guttorm

For this bug to be exploitable from remote, you need to have a bash script that can be run from remote.

Doesn't that require a login to the system?

szboardstretcher · 09-25-2014, 10:57 AM

No.

This "mainly" has to do with CGI scripts that call bash.

Of course, there are an indefinite number of other ways as well.

Remediation Steps 1 and 2 currently is to:

Update bash to a patched version
Disable mod_cgi if you can

And keep your ears open for any other attack vectors released, and patch those as well. I'm doing my best to update my post about it here: http://www.linuxquestions.org/questi...3/#post5244106

Habitual · 09-25-2014, 11:06 AM

I support Sticky for this topic.

Guttorm · 09-25-2014, 11:23 AM

If you have a bash script in cgi-bin, you are vulnerable.

http://security.stackexchange.com/qu...d-be-exploited

Bottom comment shows an example. You don't need to login, and there is nothing the bash script can do to prevent it.

tux100 · 09-25-2014, 11:39 AM

rpm -qa |grep bash says RHEL 5.8 bash-3.2-32.el5

yum update bash will upgrade bash to 3.2-33. << Pretty sure this is not a patched bash.

==================================================================================
Package Arch Version Repository Size
==================================================================================
Updating:
bash x86_64 3.2-33.el5.1 rhel-x86_64-server-5 1.8 M

ilesterg · 09-25-2014, 11:50 AM

Quote:

Originally Posted by Guttorm

If you have a bash script in cgi-bin, you are vulnerable.

http://security.stackexchange.com/qu...d-be-exploited

Bottom comment shows an example. You don't need to login, and there is nothing the bash script can do to prevent it.

Wait, I thought only bash is vulnerable. One comment says ksh is also vulnerable. I tested my Unix machine, AIX 6.1, and it doesn't look infected using this testing string:

Code:

x='() { :;}; echo you are Vulnerable>/tmp/bashbug.out' bash -c "cat /tmp/bashbug.out || echo You are PATCHED"