This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bash security vulnerbility

Hey Everyone,

With the new news (SHELL SHOCK: Bash bug blows holes in Unix, Linux, OS X systems) about the bash shell today do we know if and when Sophos is going to release a patch for this?  

I apologize if I'm posting this in the wrong section but well none of the other sections looked like this belonged in there.  Thanks.


This thread was automatically locked due to age.
  • Almost certainly sometime after SUSE releases a patch. CVE-2014-6271

    Specific to UTM/SUM, where are some likely/proven exposures to this bug in the product?  (Aside from loginuser/root shell access.)

    Is it reasonable for customers to expect the test-QA-release timeline to be quicker (or at least seriosly evaluated for improvement) than it was for Heartbleed?
  • Guys -- this bug is not really an issue for UTM users.  And it's not really an issue for secure Linux installs in general, as long as you use best practices (not exposing the shell to the public internet, restricting access to trusted IPs, etc.).  However, of course, it would be an issue on multi-user systems, etc., and of course should be patched as soon as possible.  Here's an article about it from Sophos.

    What to do about the Bash bug called “Shellshock” | Sophos Blog

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • Your mentioned article is disabled by sophos again.

    Here is the Start of the Article, which could be found by google:

    "In the light of the recent Bash vulnerability, Sophos has reviewed all of our products to understand if any are at risk from the vulnerability. We can confirm that none – including Sophos Email Appliance, Sophos Web Appliance, PureMessage for Exchange and SAV for Linux – are vulnerable. The main user-facing components of Sophos UTM..."¨

    Does anybody can provide the rest of the article?

    Due to a short research, the current UTM Version 9.206-35 is using version 3.2.51(1) of bash, which is vulnerable.

    Please send me Spam gueselkuebel@sg-utm.also-solutions.ch


  • Does anybody can provide the rest of the article?

    Yup, it is cached in my RSS reader. Here we go:

    In the light of the recent Bash vulnerability, Sophos has reviewed all of our products to understand if any are at risk from the vulnerability. We can confirm that none – including Sophos Email Appliance, Sophos Web Appliance, PureMessage for Exchange and SAV for Linux – are vulnerable.

    The main user-facing components of Sophos UTM, including the WebAdmin interface and the User Portal, do not use Bash to run commands in a way that would allow this vulnerability to be triggered by data supplied by an attacker from outside. Internal components in the UTM do use Bash, but only to run commands determined by Sophos, not based on data supplied by an outsider.

    As a matter of good security practice, we will be updating Bash as soon as a stable and effective patch is available from the Bash maintainers.

    In the meantime, we are confident that this security hole can’t be reached and exploited from outside the UTM.
  • As I mentioned, if you do not expose command line interfaces to untrusted hosts (the internet) you should be fine until bash is patched.  If you are exposing SSH, for instance, for the UTM to the public internet, you should change that setting.  The console shouldn't be exposed to the public internet in any event anyway, and we never configure it as open access for any customers we do configurations for, it's poor security practice to do so.

    My guess is that Sophos pulled the post to clarify that point...

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • Even if SSH is enabled and exposed to the internet, an attacker must authenticate before they can get access to the shell, and be able to exploit shell shock. The bigger risk is web services that may use bash cgi scripts, and specifically, may use environment variables to directly store user submitted data. In these cases, shell shock may allow an unprivileged user to do something on a web server's shell with some privilege. 

    @Gaston, I suspect someone accidentally published the article that Bruce linked before it was ready, and that's why it's not available now. It will be re-posted once all the necessary details have been gathered.

    Bruce's summary of the to-be-posted article covers the most important bits for UTM. Effectively, UTM does not appear to be vulnerable to attack from shell shock, and an update will be released later to update bash. We'll post more details publicly, later today, so keep an eye on Sophos Blog | Security made simple and Naked Security | Computer Security · News · Opinion · Advice · Research for more. Info will be posted to both, so stay tuned.
  • My only concern with this was the webserver security within UTM since it is using what appears to be apache.  I know its acting as a reverse proxy and I don't have anything using CGI exposed to the public but I just wondered for others.
  • My concern is for what is behind the UTM and whether we can effectively detect (and thwart) an attempt to access something. I'm still assessing what my web servers are running behind the UTM to try to see what might be vulnerable.

    Any thoughts on this, guys?
  • On UTM 9.x, httpd runs in chrooted jail. Nevertheless, CGI is enabled in WebAdmin and bash is the default shell for httpd processes.

    utm:/root # grep -i cgi `find /var/sec/chroot-httpd/ -name '*.conf' 2> /dev/null`
    
    /var/sec/chroot-httpd/etc/httpd/vhost/httpd-webadmin.conf:    Options Followsymlinks ExecCGI
    /var/sec/chroot-httpd/etc/httpd/vhost/httpd-webadmin.conf:    AddHandler fcgid-script .plx
    /var/sec/chroot-httpd/etc/httpd/httpd.conf[:D]irectoryIndex index.plx redirect.cgi
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:# mod_fcgid
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:LoadModule fcgid_module /usr/libexec/apache2/mod_fcgid.so
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidMaxProcesses 10
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidMaxRequestLen 536870912
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidBusyTimeout 60
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidErrorScanInterval 60
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidConnectTimeout 60
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidIOTimeout 60
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidSpawnScoreUpLimit 100
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidMaxProcessesPerClass 100
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidSpawnScore 0
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidTerminationScore 0
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidIPCDir /tmp/sock
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:FcgidProcessTableFile /tmp/fcgid_shm
    /var/sec/chroot-httpd/etc/httpd/httpd.conf:AddHandler cgi-script .pl .cgi .plc

    utm:/root # ps aufxe | grep -E "^wwwrun" | head -1 | sed -r "s/ /\n/g" | grep -E "^SHELL="
    SHELL=/bin/sh

    utm:/root # ls -l /var/sec/chroot-httpd/bin/*sh*
    -rwxr-xr-x 1 root root 554984 Sep  9 16:12 /var/sec/chroot-httpd/bin/bash
    lrwxrwxrwx 1 root root      4 Sep  9 16:12 /var/sec/chroot-httpd/bin/sh -> bash


    UTM 9.206 includes vulnerable bash:

    loginuser@utm:/home/login > export VAR1='() { ignored; }; /usr/bin/id'
    
    loginuser@utm:/home/login > bash
    uid=100(loginuser) gid=100(users) groups=100(users)
    loginuser@utm:/home/login >


    Still hoping that mod_fcgid, unlike mod_cgi, does not use shell as a "glue". I've not yet examined sources.