The 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:
- Redhat bugzilla
- Redhat CVE-2014-6271 page
- Redhat announcement
- Qualys CVE-2014-6271 page
- Mubix’s github page covering Shellshock and variants
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;)
The post ‘Bash Bug’ giving you Shellshock? CVE-2014-6271 update appeared first on Percona Performance Blog.