EmergencyEMERGENCY? Get 24/7 Help Now!

‘Bash Bug’ giving you Shellshock? CVE-2014-6271 update

 | September 26, 2014 |  Posted In: MySQL

PREVIOUS POST
NEXT POST

'Bash Bug' giving you Shellshock? CVE-2014-6271 updateThe media train is in full steam today over the the CVE-2014-6271 programming flaw, better known as the “Bash Bug” or “Shellshock” – the original problem was disclosed on Wednesday via this post. Firstly this issue exploits bash environment variables in order to execute arbitrary commands; a simple check for this per the Red Hat security blog is the following:

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

If you see an error:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’

Your version of bash is not vulnerable, if you see the text “vulnerable” – however you are.

The question becomes “how much of a problem is this really?” It’s a valid question given that even with the potential to exploit this issue via AcceptEnv for ssh connections; the attack appears to be a “local user” exploit.

I’d like to point out that it has been noted that there’s the potential for this to be exploitable in CGI web applications; and it’s also worth being aware of this new metasploit module which exploits an issue in dhclient where code injection can occur via crafted hostname response to DHCP requests, in my personal opinion this is a far wider issue in dhclient itself.

Redhat also notes that the current fix for “shellshock” is incomplete as per CVE-2014-7169

Is MySQL affected?

It does not appear to be directly affected at this time; unless you have a UDF allowing shell command execution.

MySQL documentation on environment variables as per here modified local behavior of the client only not the server. (without local modification server side).

Additional resources:

Is my application affected?

There’s no singular answer here given the diversity of applications. For instance if you’re using PHP and putenv then you potentially have quiet a large attack surface in you application for this specific vulnerability; the best recourse here is to ensure your follow best practices – e.g. update to the latest packages, test the vulnerability, ensure you application is running as a non privileged user, ensure you application only has access to the MySQL permissions it needs; and ensure you’re running a mandatory access control e.g. SELinux / Apparmor as an additional layer of defense.

Suricata and Snort signatures for shellshock as per this volexity blog post

Suricata

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:”Volex – Possible CVE-2014-6271 bash Vulnerability Requested (header)”; flow:established,to_server; content:”() {“; http_header; threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;

Snort


alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:”Volex – Possible CVE-2014-6271 bash Vulnerability Requested (header) “; flow:established,to_server; content:”() {“; http_header; threshold:type limit, track by_src, count 1, seconds 120; sid:2014092401;)

PREVIOUS POST
NEXT POST
David Busby

Information Security Architect

5 Comments

  • David,

    Thank you for sharing. I guess MySQL databases can be seriously impacted through Application being compromised in this way. If I can run any bash in my compromised PHP application I can probably get the Database access to the MySQL at least the one application has and as such either steal confidential database content or modify it – ie resetting user account passwords to something I know.

  • They updated the package again and now there are no errors when not vulnerable:

    [root@abc ~]# rpm -q –changelog bash-4.1.2-15.el6_5.2.x86_64|head
    * Thu Sep 25 2014 Ondrej Oprala – 4.1.2-15.2
    – CVE-2014-7169
    Resolves: #1146322

    * Mon Sep 15 2014 Ondrej Oprala

Leave a Reply