Xojo Cloud or Xojo CGIs affected?

Looks like 2nd heartblead…


We are already looking into this.

A reasonably thorough analysis that points out that this is unlikely to be remotely exploitable


A different opinion which suggests this is wide open and possibly worm-able:

My hosting provider, DreamHost, seems to be on top of it already. I just tested my own server for the vulnerability :

 ModSecurity: Access denied with code 418 (phase 1). Pattern match "^\\\\(\\\\) {" at REQUEST_HEADERS:Referer. [file "/dh/apache2/template/etc/mod_sec2/99_dreamhost_rules.conf"] [line "241"] [id "1990064"] [msg "CVE-2014-6271 - Bash Attack"] 

so looks like Apache’s ModSecurity may be helpful here if configured with the latest rules…

[quote=131709:@Norman Palardy]A reasonably thorough analysis that points out that this is unlikely to be remotely exploitable


Thank you for that link, Norman. Now that I know my Mac is vulnerable with the test offered there, what I am supposed to do ?

Not that I fear too much an attack on my little self, but who knows ? I imagine this is of much more concern for any system accessible from the Internet at the command line level ?

Unless you have remote shell access OR some service that uses bash that can be remotely accessed you’re unlikely to be vulnerable to anything remotely.
To make this attack work you need to

  • be able to set an environment variable (cgi’s do a lot of their work via env vars)
  • have that service be processed via something that uses BASH (or something else like PHP that uses BASH)

On a Mac you probably have nothing to worry about EXCEPT someone sitting at your machine as all those services are usually turned off.

So that means that in order to be vulnerable, my php scripts and Xojo web apps would have to use like shells ?

My understanding is that the vulnerability is when Apache gets a HTTP request and calls out to MOD_CGI, and the malicious HTTP request sets environment variables. It may also be vulnerable in MOD_STATUS.

You can take a look at your httpd.conf file which is usually located at /private/etc/apache2 and see what’s enabled. Disabling those things and restarting apache might help, but since this seems a very fluid situation I wouldn’t count on anything at this point.

I run a few OSX web servers, and I stopped Apache on them this morning until I know what to do… YMMV

If your php never interacts with the shell it seems your likely ok.
Greg & travis are looking at how Xojo webs apps to determine what, if any exposure they have.
But there seems to be disagreement of how vulnerable different publicly exposed systems may be.

The primary vulnerability (through Apache) is calling a CGI script which in turn goes through Bash.

We don’t believe we are vulnerable to remote exploitation of this, but our servers will still be updated.

  1. Xojo Cloud is not hosted on OS X - but servers will be updated as needed as patches become available anyways
  2. xojo’s cgi isn’t using BASH