These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Remote bash vulnerability in all distros on the new forum.
Web Hosting and Cloud Computing Control Panels
Is Virtualmin in fcgid mode vulnerable to this? I.e. does the bash instance that starts the php5-cgi instance get passed environment variables from HTTP requests?
^^^ is Fast-CGI at risk here?
Howdy,
I just talked to Joe about this. On a theoretical level, we're not entirely certain.
Any Bash CGI scripts would be vulnerable.
The question is around the wrapper scripts being used for launching PHP. There seem to be conflicting opinions there, and we haven't yet reproduced a malicious attack using that avenue. But it's certainly plausible there could be a problem. And any script that performs a call to the shell (ie, via a system call) is subject to that problem.
I'm going to spend some time looking into that today to see what I can come up with.
Though we'd of course certainly recommend performing any bash upgrades that are made available as soon as they're available.
Joe thought you guys might be interested in this
https://access.redhat.com/articles/1200223
Also, there is a preliminary fix for the second BASH issue on Ubuntu here (though note that this is not an official fix, and has not been tested or gone through Ubuntu's QA process.. I wouldn't recommend this unless you're feeling particularly paranoid, or unless you test it first):
http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html
-Eric
Howdy,
Okay, I spent some time doing some testing this afternoon, and here is what I discovered.
The first of the Bash vulnerabilities -- the one that had updates made available for it yesterday -- using CGI as an execution mode is quite vulnerable to attack.
Using FCGID appeared to be much safer.
FCGID made it much harder to exploit. I don't wish to go as far as saying it's not vulnerable, as this is a pretty severe bug, but it does a lot to make exploitation harder (and in my testing, I wasn't able to exploit it).
-Eric
Thanks so much for the follow-ups Eric.
What about Postfix, which seems to call the local delivery Procmail wrapper via a command? According to the Postfix documentation, the environment is populated with several infos from the email prior to calling the command.
And what about SpamAssassin, ClamAV, Postgrey and the greylist-milter, are any of those vulnerable? Or other components that Virtualmin uses?
Howdy,
Unfortunately, I'm not really sure... Apache is the one that's simple to remotely exploit.
However, it's definitely possible one could take advantage of those other services, though I don't have example exploits of those off-hand. They'd be trickier to take advantage of.
Any service which performs a system call could potentially be taken advantage of though, if a vulnerable Bash version is installed.
With that in mind, nearly every service out there is a potential target.
All the distros supported by Virtualmin have released updates for Bash -- my recommendation at this point would just be to upgrade Bash, that's the only way to be sure it's safe.
The Bash issue is pretty serious, and we highly recommend installing any and all Bash updates as soon as possible.
-Eric
Yeah sure, I've already patched all my Bashes (multiple times meanwhile), via auto-update and also manually. Well, the Linuxes at least. For my Android stuff I still need to look for updates, though I hope an Android client device is not as easily exploitable (I don't use any public DHCP servers).
I'm thinking along the lines here of "what if this bug has been found in the past, before the patches came out"... they say the bug existed for 20 years. So do we have to consider each and every Debian/Ubuntu server installed and used on the Internet in the last 20 years potentially compromised? :(
So, from what I've read, Postfix may protect against this bug. There is a documented feature of Postfix where it munges headers that have control over the ENV. Whether this is sufficient, or prevents all such exploits, is unknown to me at the moment, though I'm planning to test it as soon as I've got a few minutes to spare to bring up a VM with an exploitable bash on it.
The credible example of a potentially dangerous exploit I've seen is this:
https://pastee.org/5vebd
If the Postfix ENV munging magic doesn't apply to this header, it'd lead to an exploitable condition. It is, obviously, not exploitable on systems that have been updated with the latest bash patches.
The RHEL bash update contains Florian Weimar's suggested patch which effectively separates the exported function name space from the ENV namespace, so none of these types of exploits can work anymore (ENV changes can no longer cause execution), as I understand it. Even new exploits coming at the problem from different angles, that might slip past the earlier patches simplistic parsing fixes won't be useful against the newer patch.
--
Check out the forum guidelines!
There's an interesting site here, which lists confirmed and suspected vulnerable services of the Shellshock issue:
https://github.com/mubix/shellshocker-pocs/blob/master/README.md
I did all the patches, but I am getting 10,000+ /bin/bash ./shock.sh processes - HELP
I have know idea how or what to do. Bash is updated per all the instructions.
Running Virtualmin with COS6
David Calderwood - Euro-Pacific Digital Media
The command being "/bin/bash ./shock.sh" tells me it's being run by a local user. This is not a remote exploit of shellshock...what user is running this process?
And, using lsof or other tools, can you find the location of the shell.sh file? (There are techniques for retrieving running scripts and programs from memory or disk, even after they've been deleted; a couple of options are documented here: http://superuser.com/questions/692947/is-it-possible-to-retreive-the-con... )
The is probably not actually a successful exploit of shell shock, though it probably does indicate some exploit has happened in the past (possibly via shell shock), since somebody had to have some way of running that script locally for it to be started like that. If your bash has been updated to a non-exploitable version, a remote attacker would not be able to cause this behavior anymore, but a local user (possibly an account exploited using shell shock) would be able to. Finding out what's in that script, and finding out what user is running it, would be the first steps to figuring out what's going on.
--
Check out the forum guidelines!
I tracked down the problem. Even though I did the BASH patch upgrade somehow it did not delete an old bash file and that was running wild. Basically, the update failed and I didn't notice.
I ran
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"and this confirmed that my version of BASH was vulnerable - yet I had applied the patch. However, the directions that I had for applying the patch were not correct.You need to update to the latest version of BASH:
First, run:
yum clean all && yum update bashTo check which version of BASH is installed, run the following command:rpm -qa | grep bashIf your version of BASH is earlier than bash-4.1.2-15.el6_5.2 you may be vulnerable - find the patch for your system and install. To check on your whivh version you need:uname -mFor my system - CentOS 6 64bit:
rpm -Uvh http://mirror.centos.org/centos/6/os/x86_64/Packages/bash-4.1.2-29.el6.x86_64.rpmTest your server by running the following command:
cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echoA correctly-patched server will return:datecat: /tmp/echo: No such file or directory
David Calderwood - Euro-Pacific Digital Media
Thanks for the Bash updating instructions. I don't have any server currently online that is able to be exploited via Shelshock, but nevertheless this stuff is useful.