Security Notices

2018-08-06 SegmentSmack (CVE-2018-5309): Linux Kernel TCP Vulnerability

CVE-2018-5309: A new security vulnerability in the Linux Kernel known as SegmentSmack was publicly disclosed recently. It allows attackers to trigger the most resource-intensive code paths for TCP stream reassembly with low rates of specially crafted packets, leading to a remote denial of service.

Affected platforms

The affected versions of the Linux kernel are versions 4.9+ and maintaining the denial of service condition requires continuous two-way TCP sessions to a reachable open port.

To check if your system is not vulnerable, execute the command below:

$ uname -a
Debian 8 (Jessie)

Debian Jessie kernel should be equal or greater than 3.16.57-2.

Debian 9 (Stretch)

Debian Stretch kernel should be equal or greater than 4.9.110-3+deb9u1.

Ubuntu 16.04 in Azure

Ubuntu 16.04 kernel version in Azure should be equal or greater than 4.15.0-1019-azure.

Oracle Enterprise Linux

This distribution is not affected.

Other distributions: RHEL, CentOS, Ubuntu 16.04 in AWS, …

There is not any new package for these Linux distributions at the moment of writing this.

How to patch it

If your system is affected, follow the steps below for your platform.

Ubuntu and Debian

Run the following command to patch the system and then reboot:

$ sudo apt-get update && sudo apt-get dist-upgrade
$ sudo reboot
Red Hat, CentOS and Amazon Linux

Run the following command to patch the system and then reboot:

$ sudo yum update
$ sudo reboot

Once you have completed the steps above, you will have the fixed version of the kernel/operating system running on your server. If you have any question about this process, please post it in our community support forum. We will be happy to help!

2018-01-04 Spectre (CVE-2017-5753, CVE-2017-5715) and Meltdown (CVE-2017-5754) attack

On January, 4th 2018 three vulnerabilities affecting many modern processors were publicly disclosed:

Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data, which is currently available on the computer's memory. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of the secrets stored in the memory of other running programs. This might include: passwords stored in a password manager or browser, personal photos, emails, instant messages, and even business-critical documents.

Meltdown and Spectre affect the following platforms and devices:

  • Personal computers
  • Mobile devices
  • Cloud instances: Depending on the cloud provider's infrastructure, it might be even possible to steal data from other customers.

There are patches against Meltdown for Linux, Windows and OSX and some platforms also released patches for Spectre. This is translated into patched kernels, patched hypervisors and new versions of operating systems. Note that the kernel fixes for this CPU bug will have a performance impact, estimated by some sources to be from 5% to around 30%, depending on workloads.

At the moment, more work is being done to harden software against future exploitation of Spectre.

Affected platforms

Linux OS distributions

To check if your system is not vulnerable, execute the command below:

$ uname -r

The output you obtain after running the above command indicates the version of the kernel package you currently have installed and running on your system. Find in the list below which are the kernel versions you should have to make sure that your system is not vulnerable:

CentOS 7

CentOS kernel should be equal or greater than 3.10.0-693.11.6.el7.

RedHat 7

RedHat kernel should be equal or greater than 3.10.0-693.11.6.el7.

Oracle Linux 7

Oracle Linux kernel should be greater than kernel-uek-4.1.12-112.14.2.el7uek and/or 3.10.0-693.11.1.0.1.el7.OL7.

Debian 9 (Stretch)

Debian Stretch kernel should be equal or greater than 4.9.65-3.

Debian 8 (Jessie)

Debian Jessie kernel should be greater than 3.16.0-4.

Ubuntu 16.04

Ubuntu 16.04 kernel should be greater than 4.4.0-112.

Ubuntu 14.04

Ubuntu 14.04 kernel should be greater than 3.13.0-141.

Amazon Linux

Amazon Linux kernel should be equal or greater than 4.9.70-25.242.amzn1.

Windows and OS X

Check the latest updates to make sure that you have the already patched version of the kernel package.

How to patch it

It is of the utmost urgency to quickly address any security issue in applications distributed by Bitnami. Our team is working on updating all the affected Virtual Machines and Cloud Images available through Bitnami, for all our cloud providers partners. This will ensure that all the new launches will be secured against this issue. If you have any existing running server (virtual machines) or if you have a Bitnami stack installed on your computer, you will need to update the operating system on your own.

Once a new, patched kernel is available from the operating system vendor, you can update it by following these instructions (depending on your distribution/operating system):

  • Run the following command:

    • Ubuntu / Debian

        $ sudo apt-get update && sudo apt-get dist-upgrade
      
    • Oracle Linux, Red Hat, CentOS and Amazon Linux

        $ sudo yum update
      
    • Windows / OSX

      Update your system packages when the operating system suggests to.

      NOTE: Enable the "Check for updates" option in Windows in order to get the latest updates and patches.
  • Reboot your server/operating system.

Once you have completed the steps above, you will have the fixed version of the kernel/operating system running on your server. If you have any question about this process, please post it in our community support forum. We will be happy to help!

Check the official Meltdown attack webpage for more information on these vulnerabilities.

2016-10-20 Dirty COW (CVE-2016-5195): Privilege escalation vulnerability in the Linux Kernel

CVE-2016-5195: A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.

This could be abused by an attacker to modify existing setuid files with instructions to elevate privileges.

Find more information about the issue.

Affected platforms

Ubuntu

Run the following command:

$ uname -r

You should see output like this one:

3.13.0-100-generic

or this one:

4.4.0-45-generic

These are secure versions of the library.

Debian

Run the following command:

$ uname -v

You should see output like this:

3.16.36-1+deb8u2

This is a secure version of the library.

Oracle Linux

Run the following command:

$ uname -r

You should see output like this:

4.1.12-61.1.16.el6uek.x86_64

This is a secure version of the library.

Red Hat and CentOS

Run the following command:

$ uname -r

You should see output like this:

3.10.0-327.36.3.el7.x86_64

This is a secure version of the library.

Amazon Linux

Run the following command:

$ uname -r

You should see output like this:

4.4.23-31.54.amzn1.x86_64

This is a secure version of the library.

How to patch it

If your system is affected, follow the steps below for your platform.

Ubuntu and Debian

Run the following command to patch the system and then reboot:

$ sudo apt-get update && sudo apt-get dist-upgrade
$ sudo reboot
Oracle Linux, Red Hat, CentOS and Amazon Linux

Run the following command to patch the system and then reboot:

$ sudo yum update
$ sudo reboot

2016-09-22 OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304)

A memory leak flaw was found in the way OpenSSL handled TLS status request extension data during session renegotiation. A remote attacker could cause a TLS server using OpenSSL to consume an excessive amount of memory and, possibly, exit unexpectedly after exhausting all available memory, if it enabled OCSP stapling support. You can find out more information about it in the OpenSSL Security Advisory.

Affected platforms

Check the OpenSSL version that you are currently using with the following command:

$ /opt/bitnami/common/bin/openssl version

OpenSSL versions prior to 1.0.1u, 1.0.2i and 1.1.0a are vulnareble and allow malicious client to exhaust the server's memory.

Secure the system

To secure your server, you need to update the OpenSSL version included in the system and the OpenSSL included in the Bitnami installation.

NOTE: At the time we wrote this documentation the packages of the other distributions have not been released
Debian

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo apt-get update
     $ sudo apt-get install -y openssl libssl1.0.0
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1t  3 May 2016
     built on: Thu Sep 22 06:42:20 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
Ubuntu

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo apt-get update
     $ sudo apt-get install -y openssl libssl1.0.0
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1f 6 Jan 2014
     built on: Thu Sep 22 17:59:24 UTC 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
Red Hat

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo yum -y update openssl
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1e-fips 11 Feb 2013
     built on: Thu Sep 22 05:31:09 EDT 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
Oracle Linux

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo yum -y update openssl
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1e-fips 11 Feb 2013
     built on: Tue Sep 27 05:35:00 PDT 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
CentOS

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo yum -y update openssl
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1e-fips 11 Feb 2013
     built on: Tue Sep 27 13:37:25 UTC 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
Amazon Linux

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo yum -y update openssl
    
  • Check that the version was updated (please note the "built on" date):

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1k-fips 8 Jan 2015
     built on: Thu Sep 22 19:07:16 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    

How to patch the Bitnami installation

To prevent malicious users from exploiting the vulnerability in the server, update the OpenSSL version by following the steps below:

The patch will check if your installation is vulnerable and if so, update the library version to a safe one. At the end of the patching process, it will ask for permission to restart your services (recommended) so the changes take effect. It will also save all the updated files in the /opt/bitnami/opensslfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/opensslfix/backup/ directory.

Troubleshooting

Apache fails to start after applying this patch

This usually happens because of some binary incompatibility. The installer will allow you to restore the installation back to its previous state, as shown below:

Apache configuration seems to fail after applying the patch. Do you want to restore to the previous state? [Y/n]:

Select "Y" to go back to the working (but vulnerable) version. If the rollback process fails, manually copy the files from the backup directory, as shown below:

$ cp -rp /opt/bitnami/opensslfix/backup/* /opt/bitnami/common
$ /opt/bitnami/ctlscript.sh restart apache

Post a question in the community so we can help you troubleshoot the issue.

2016-08-18 Off-Path TCP Linux Kernel Vulnerability (CVE-2016-5696)

A new security vulnerability in the linux kernel has been discovered. You can find out more information about it in the following research report: "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous".

Since the Linux kernel code affected was implemented in 2012 (in Linux Kernel 3.6), all Bitnami-packaged images might be affected by this issue if the kernel hasn't been updated. As of 18 Aug 2016, all the affected cloud images and virtual machines have been successfully patched. If you are using a Bitnami Cloud Hosting instance, you can easily patch it following the guide below while we upgrade the base images.

Apply the following patch to your system:

$ sysctl net.ipv4.tcp_challenge_ack_limit=1073741823; grep -q tcp_challenge_ack_limit /etc/sysctl.conf || echo "net.ipv4.tcp_challenge_ack_limit=1073741823" >> /etc/sysctl.conf
NOTE: This is just a temporary solution that makes it a lot harder for attackers to succeed in exploiting this vulnerability.

Once the new kernel is available, you can update it by running the commands shown below for your platform or distribution.

Ubuntu

Run the command below:

$ sudo apt-get update && sudo apt-get dist-upgrade 

Reboot the server to apply the new kernel.

2016-07-18 httpoxy: A CGI application vulnerability (CVE-2016-5385, CVE-2016-5387, CVE-2016-1000110)

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict:

  • RFC 3875 (CGI) puts the HTTP Proxy header from a request into the environment variables as HTTP_PROXY
  • HTTP_PROXY is a popular environment variable used to configure an outgoing proxy

This leads to a remotely exploitable vulnerability. If you're running PHP or CGI, you should block the Proxy header now.

A number of CVEs have been assigned, covering specific languages and CGI implementations:

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python

Find more information about the vulnerability on the httpoxy website.

How to patch it

The most immediate mitigation is to block Proxy request headers as early as possible, and before they hit your application. This is easy and safe.

Apache

Follow these steps:

  • Modify the IfModule headers_module in the /opt/bitnami/apache2/conf/httpd.conf file to unset the Proxy header. It will look like this:

    <IfModule headers_module>
        RequestHeader unset Proxy
        <IfVersion >= 2.4.7 >
            Header always setifempty X-Frame-Options SAMEORIGIN
        </IfVersion>
        <IfVersion < 2.4.7 >
            Header always merge X-Frame-Options SAMEORIGIN
        </IfVersion>
    </IfModule>
    
  • Save the file and restart the service:

     $ sudo /opt/bitnami/ctlscript.sh restart apache 
    
Nginx

Follow these steps:

  • Add this line at the end of the /opt/bitnami/nginx/conf/fastcgi_params file:

     fastcgi_param  HTTP_PROXY "";
    
  • Save the file and restart the service:

     $ sudo /opt/bitnami/ctlscript.sh restart nginx 
    

How to check that the Proxy request headers are blocked

Follow these steps:

  • Create a httpoxy.php file at the Apache document root:

     <?php
     if (isset($_SERVER['HTTP_PROXY']) && $_SERVER['HTTP_PROXY'] == 'vulnerable') {
       echo 'Vulnerable!';
     }
    
  • Run the following command at the server console:

     $ curl --header "Proxy: vulnerable" http://localhost/httpoxy.php
    

It will print "Vulnerable!" if the server is vulnerable.

2016-05-04 ImageTragick: Remote execution vulnerability (CVE-2016-3714)

Several security vulnerabilities have been recently discovered for certain ImageMagick coders. Specifically, the vulnerabilities include possible remote code execution and the ability to render files on the local system.

A number of image processing plugins depend on the ImageMagick library, including, but not limited to, PHP's Imagick, Ruby's RMagick and Paperclip, and Node.js's imagemagick.

Find more information about the vulnerability on the ImageTragick website.

How to patch it

If you use ImageMagick or an affected library, we recommend you mitigate the known vulnerabilities with these steps:

  • Edit the /opt/bitnami/common/lib/ImageMagick-6.7.5/config/policy.xml file of ImageMagick and add the following policy rules:

     <policymap>
       <policy domain="coder" rights="none" pattern="EPHEMERAL" />
       <policy domain="coder" rights="none" pattern="URL" />
       <policy domain="coder" rights="none" pattern="HTTPS" />
       <policy domain="coder" rights="none" pattern="MVG" />
       <policy domain="coder" rights="none" pattern="MSL" />
       <policy domain="coder" rights="none" pattern="TEXT" />
       <policy domain="coder" rights="none" pattern="SHOW" />
       <policy domain="coder" rights="none" pattern="WIN" />
       <policy domain="coder" rights="none" pattern="PLT" />
     </policymap>
    
  • Verify your policies with the following command:

     $ convert -list policy
    

Below is an example of the policy output:

Path: [built-in]
  Policy: Undefined
    rights: None 
Path: /opt/bitnami/common/lib/ImageMagick-6.7.5/config/policy.xml
  Policy: Coder
    rights: None 
    pattern: EPHEMERAL
  Policy: Coder
    rights: None 
    pattern: URL
  Policy: Coder
    rights: None 
    pattern: HTTPS
  Policy: Coder
    rights: None 
    pattern: MVG
  Policy: Coder
    rights: None 
    pattern: MSL

2016-03-01 OpenSSL Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800 and CVE-2016-0703)

A number of OpenSSL security vulnerabilities were announced on 2016-03-01 that affect to the versions of OpenSSL currently in use. The most significant one were CVE-2016-0800 and CVE-2016-0703, which allows an attacker to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data.

All the Bitnami-packaged applications are NOT VULNERABLE because Apache disables SSLv2 and EXPORT algorithms for HTTPS by default. Having say that, it is recommended to update the OpenSSL version of your system for other services following the next steps.

Secure the system

Ubuntu and Debian

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo apt-get update
     $ sudo apt-get install -y openssl libssl1.0.0
    
  • Check that the version was updated:

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1f 6 Jan 2014
     built on: Mon Feb 29 18:11:15 UTC 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
RedHat Enterprise Linux, Oracle Linux and CentOS

Follow the steps below:

  • Update the system OpenSSL library with these commands:

     $ sudo yum -y update openssl
    
  • Check that the version was updated:

     $ /usr/bin/openssl version -a
     OpenSSL 1.0.1e-fips 11 Feb 2013
     built on: Wed Feb 24 09:48:57 EST 2016
    
  • Restart any service using libssl:

     $ sudo /opt/bitnami/ctlscript.sh restart
    
Amazon Linux

These images are not affected by this issue. Read more.

Test the system

  • Browse to https://drownattack.com/ and check if your server is vulnerable.

  • DROWN Scanner is a tool scans for vulnerability to the DROWN attack against TLS. It is distributed under the GPLv2 license. Download it from Github and then run the commands below:

     $ python scanner.py localhost 443
     Testing localhost on port 443
     localhost: Case 3d; Server hello did not contain server hello
     localhost: Server is NOT vulnerable with cipher RC2_128_CBC_EXPORT40_WITH_MD5, Message: 3d: no tls
    
     localhost: Case 3d; Server hello did not contain server hello
     localhost: Server is NOT vulnerable with cipher RC4_128_EXPORT40_WITH_MD5, Message: 3d: no tls
    
     localhost: Case 3d; Server hello did not contain server hello
     localhost: Server is NOT vulnerable with cipher RC4_128_WITH_MD5, Message: 3d: no tls
    
     localhost: Case 3d; Server hello did not contain server hello
     localhost: Server is NOT vulnerable with cipher DES_64_CBC_WITH_MD5, Message: 3d: no tls
    

2016-02-17 glibc getaddrinfo() stack-based buffer overflow (CVE-2015-7547)

It was discovered that the GNU C Library incorrectly handled receiving responses while performing DNS resolution (CVE-2015-7547). A remote attacker could use this issue to cause the GNU C Library to crash, resulting in a denial of service, or possibly execute arbitrary code.

All versions of glibc after 2.9 are vulnerable. Version 2.9 was introduced in May 2008.

The defect is located in the glibc sources in the resolv/res_send.c file as part of the send_dg and send_vc functions which are part of the __libc_res_nsend (res_nsend) interface which is used by many of the higher level interfaces including getaddrinfo (indirectly via the DNS NSS module.)

Find more information about the issue.

Affected platforms

Ubuntu

Run the following command:

$ ldd --version

You should see output like this:

2.19-0ubuntu6.7

This is a secure version of the library. Any version between v2.9 and this one is affected.

Debian

Run the following command:

$ ldd --version

You should see output like this:

2.13-38+deb7u10

This is a secure version of the library. Any version between v2.9 and this one is affected.

RedHat Enterprise Linux and Oracle Linux

Run the following command:

$ rpm -q glibc

You should see output like this:

2.12-1.166.el6_7.7

This is a secure version of the library. Any version between v2.9 and this one is affected.

Amazon Linux

Run the following command:

$ rpm -q glibc

You should see output like this:

glibc-2.17-106.166.amzn1.x86_64

This is a secure version of the library. Any version between v2.9 and this one is affected.

How to patch it

If your system is affected, follow the steps below for your platform:

Ubuntu and Debian

Run the following command:

$ sudo apt-get update && sudo apt-get install unattended-upgrades && sudo unattended-upgrade
RedHat Enterprise Linux, Oracle Linux and Amazon Linux

Run the following command:

$ sudo yum update glibc

2016-01-20 Linux kernel vulnerability (CVE-2016-0728)

CVE-2016-0728 is caused by a reference leak in the keyrings facility and it affects any Linux Kernel v3.8 and higher.

The keyrings facility is primarily a way for drivers to retain or cache security data, authentication keys, encryption keys and other data in the kernel. Each process can create a keyring for the current session using keyctl(KEYCTL_JOIN_SESSION_KEYRING, name) and can choose to either assign a name to the keyring or not by passing NULL. The keyring object can be shared between processes by referencing the same keyring name.

Even though the bug itself can directly cause a memory leak, it has far more serious consequences. The outline of the steps that to be executed by the exploit code is as follows:

  • Hold a (legitimate) reference to a key object
  • Overflow the same object's usage
  • Get the keyring object freed
  • Allocate a different kernel object from user-space, with a user-controlled content, over the same memory previously used by the freed keyring object
  • Use the reference to the old key object and trigger code execution

Find more information about the issue.

Affected platforms

Ubuntu

Run the following command:

$ uname -r

You should see output like this:

3.13.0-76-generic

This is a secure version of the library. Any version between v3.8 and this one is affected.

Debian

Run the following command:

$ uname -v

You should see output like this:

3.16.7-ckt20-1

This is a secure version of the library. Any version between v3.8 and this one is affected.

RedHat Enterprise Linux

This issue does not affect the Linux kernels shipped with Red Hat Enterprise Linux 5 and 6. The Bitnami images of RedHat are not affected as we provide images for RedHat 6.6.

Oracle Linux

Run the following command:

$ uname -r

You should see output like this:

3.8.13-118.2.5.el6uek.x86_64

This is a secure version of the library. Any version between v3.8 and this one is affected.

Amazon Linux

Run the following command:

$ uname -r

You should see output like this:

4.1.13-19.31.amzn1.x86_64

This is a secure version of the library. Any version between v3.8 and this one is affected.

How to patch it

If your system is affected, follow the steps below for your platform.

Ubuntu and Debian

Run the following command to patch the system and then reboot:

$ sudo apt-get update && sudo apt-get dist-upgrade
$ sudo reboot
Oracle Linux

Run the following command to patch the system and then reboot:

$ sudo yum update
$ sudo yum upgrade
$ sudo reboot
Amazon Linux

Run the following command to patch the system and then reboot:

$ sudo yum clean all
$ sudo yum update kernel
$ sudo reboot

2015-11-16 libpng security issue (CVE-2015-8126)

A recent vulnerability was discovered that affect several libpng versions: before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19. This issue allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a small bit-depth value in an IHDR (aka image header) chunk in a PNG image.

Find more information about the issue.

Affected platforms

Check the libpng version that you are currently using with the following command:

$ /opt/bitnami/common/bin/libpng-config --version

This issue affects libpng versions before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19.

How to patch it

  • Patch the library located in the /opt/bitnami directory, by downloading and installing an update for your platform.

    • For Ubuntu Linux 14.04 64-bit systems:

      $ wget https://downloads.bitnami.com/files/libpngfixer/1.5.24-0/bitnami-libpngfixer-1.5.24-0-linux-x64-installer.run
      
    • For Ubuntu Linux 14.04 32-bit systems:

      $ wget https://downloads.bitnami.com/files/libpngfixer/1.5.24-0/bitnami-libpngfixer-1.5.24-0-linux-installer.run
      
  • Install the patch using the commands below:

     $ chmod +x ./bitnami-libpngfixer-1.5.24-0-linux-x64-installer.run
     $ sudo ./bitnami-libpngfixer-1.5.24-0-linux-x64-installer.run
    

The patch will check if your installation is vulnerable and if so, update the library version to a safe one. It will also save all the updated files in the /opt/bitnami/libpngfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/libpngfix/backup/ directory.

Troubleshooting

Apache fails to start after applying this patch

This usually happens because of some binary incompatibility. The installer will allow you to restore the installation back to its previous state, as shown below:

Apache configuration seems to fail after applying the patch. Do you want to restore to the previous state? [Y/n]:

Select "Y" to go back to the working (but vulnerable) version. If the rollback process fails, manually copy the files from the backup directory, as shown below:

$ cp -rp /opt/bitnami/libpngfix/backup/* /opt/bitnami/common
$ /opt/bitnami/ctlscript.sh restart apache

Post a question in the community so we can help you troubleshoot the issue.

2015-07-09 Alternative chains certificate forgery (CVE-2015-1793)

A recent vulnerability was discovered that affect several OpenSSL versions: 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication.

Find more information about the issue.

Affected platforms

Check the OpenSSL version that you are currently using with the following command:

$ /opt/bitnami/common/bin/openssl version

This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o.

NOTE: Bitnami Cloud Hosting servers are not affected, as they do not ship any of these versions.

How to patch it

To prevent malicious users from exploiting the vulnerability in the server, update the OpenSSL version by following the steps below:

  • Patch the library located in the /opt/bitnami directory, by downloading and installing an update for your platform.

    • For Ubuntu Linux 12.04 64-bit systems:

      $ wget http://downloads.bitnami.com/files/stacks/opensslfixer/1.0.1p-1/bitnami-opensslfixer-1.0.1p-1-linux-x64-installer.run
      
    • For Ubuntu Linux 12.04 32-bit systems:

      $ wget http://downloads.bitnami.com/files/stacks/opensslfixer/1.0.1p-1/bitnami-opensslfixer-1.0.1p-1-linux-installer.run
      
  • Install the patch using the commands below:

     $ chmod +x ./bitnami-opensslfixer-1.0.1p-1-linux-installer.run
     $ sudo ./bitnami-opensslfixer-1.0.1p-1-linux-installer.run
    

The patch will check if your installation is vulnerable and if so, update the library version to a safe one. At the end of the patching process, it will ask for permission to restart your services (recommended) so the changes take effect. It will also save all the updated files in the /opt/bitnami/opensslfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/opensslfix/backup/ directory.

Troubleshooting

Apache fails to start after applying this patch

This usually happens because of some binary incompatibility. The installer will allow you to restore the installation back to its previous state, as shown below:

Apache configuration seems to fail after applying the patch. Do you want to restore to the previous state? [Y/n]:

Select "Y" to go back to the working (but vulnerable) version. If the rollback process fails, manually copy the files from the backup directory, as shown below:

$ cp -rp /opt/bitnami/opensslfix/backup/* /opt/bitnami/common
$ /opt/bitnami/ctlscript.sh restart apache

Next, execute the OpenSSL Fixer as follows, with the --forceversioned 1 parameter:

$ chmod +x ./bitnami-opensslfixer-1.0.1p-1-linux-x64-installer.run
$ sudo ./bitnami-opensslfixer-1.0.1p-1-linux-x64-installer.run  --forceversioned 1    

Post a question in the community so we can help you troubleshoot the issue.

2015-01-27 GHOST: glibc gethostbyname buffer overflow CVE-2015-0235

A recent vulnerability was discovered that affect common versions of Linux distributions. It is a serious problem that if left unpatched may lead to remote compromise of your server.

Find more information about the issue.

Affected platforms

Only Linux systems are affected:

  • Ubuntu 10.04, 12.04 are affected. Ubuntu 14.04 is not affected.

  • Debian Squeezy, Wheezy are affected. Debian Jessie, Sid are not affected.

  • CentOS and RHEL 5, 6, 7 are affected.

  • Recent downloadable virtual machine users are not affected, as they are based on Ubuntu 14.04, which is not vulnerable.

  • Bitnami Google Compute platform cloud images are based on Debian 7 and were vulnerable. All of the images have been patched so new server launches will not be vulnerable. If you have older running images, please see the patching instructions.

  • Recent Bitnami Amazon Web Services cloud images are not vulnerable as they are based on Ubuntu 14.04. Older versions based on Ubuntu 12.04 and 10.04 are vulnerable. We have currently removed them from the AWS catalog so no new launches are possible, until they are fixed. Bitnami RHEL and CentOS-based images were similarly vulnerable and if you are running a server based on those you will need to upgrade. Amazon Linux cloud images are affected as well.

How to patch it

Ubuntu and Debian

Execute these commands:

$ apt-get update
$ apt-get -y install libc6

Read the Debian advisory and the Ubuntu advisory.

RedHat Enterprise Linux, Amazon Linux and CentOS

Execute these commands:

$ yum clean all
$ yum update glibc

Read the RedHat advisory and the Amazon advisory.

2014-10-15 POODLE issue with SSLv3 (CVE-2014-3566)

The POODLE issue (CVE-2014-3566) is a vulnerability in the design of SSL version 3.0. This vulnerability allows the plaintext of secure connections to be calculated by a network attacker.

All current Bitnami stacks have already disabled the SSLv3 protocol so they are not affected by this issue. To check this is the case, you should look for the following line in the Apache configuration file /opt/bitnami/apache2/conf/bitnami/bitnami.conf.

SSLProtocol all -SSLv2 -SSLv3

Detect whether your server is vulnerable

If you are running a Bitnami stack that was released earlier than 2014/04, you should check whether your server is vulnerable. You can run the command below from your local machine or from the server itself. Replace the DOMAIN placeholder with the domain of your server:

$ curl --sslv3 https://DOMAIN

If you get the following result, SSLv3 protocol is disabled for HTTPS:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

If you see the web page in the command line, your server allows the SSLv3 protocol for HTTPS, so you should disable it, as described in the next section.

Secure your server

Apache

The best way to secure your server is to disable the SSLv3 protocol for HTTPS URLs. Follow the steps below:

  • Edit the SSL configuration for Apache in the /opt/bitnami/apache2/conf/bitnami/bitnami.conf file and add the SSLProtocol all -SSLv2 -SSLv3 configuration option:

     Listen 443
     SSLProtocol all -SSLv2 -SSLv3
    
  • Check the Apache configuration:

     $ sudo apachectl -t
    
  • Restart the server:

     $ sudo apachectl restart
    

To check if the SSLv3 protocol has been correctly disabled, use the curl command from the previous section.

Nginx

If you are using Nginx instead of Apache, follow these steps:

  • Edit the /opt/bitnami/nginx/nginx.conf configuration file and add the ssl_protocols TLSv1 TLSv1.1 TLSv1.2; directive in the default http section:

     http {
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         ...
    

To check if the SSLv3 protocol has been correctly disabled, use the curl command from the previous section.

2014-09-25 Critical security issue in bash (CVE-2014-6271, CVE-2014-7169)

The CVE-2014-6271 (Shellshock) is a critical vulnerability in the bash shell that is remotely exploitable. The bash fix for CVE-2014-6271 was incomplete and command injection is possible even after the patch has been applied. The issue is being tracked as CVE-2014-7169 (Aftershock). After these vulnerabilities other issues has been found.

Find more information.

Secure your server

Ubuntu 14.04

Execute the following commands:

$ sudo apt-get update
$ sudo apt-get install bash
Ubuntu 12.10

Users of Ubuntu 12.10 may not be able to download the latest bash version from the repositories, as support for Ubuntu 12.10 officially ended on May 16 2014.

In this case, download and install the latest Debian package for Ubuntu 14.04:

  • For 64-bit Linux systems:

     $ wget http://security.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.5_amd64.deb
     $ sudo dpkg -i bash_4.2-2ubuntu2.5_amd64.deb
    
  • For 32-bit Linux systems:

     $ wget http://security.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.5_i386.deb
     $ sudo dpkg -i bash_4.2-2ubuntu2.5_amd64.deb
    

Detect whether your server is vulnerable

Shellshock (CVE-2014-6271)

To test that you have successfully updated your installation, type:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see the following, you have successfully patched bash:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

If you see the following, you are still vulnerable:

vulnerable
this is a test
Aftershock (CVE-2014-7169)

To test that you have successfully updated your installation, type:

$ env var='() {(a)=>\' bash -c "echo date"; cat echo; rm -f echo

If you see one of the following outputs, you have successfully patched bash:

bash: var: line 1: syntax error near unexpected token `='
bash: var: line 1: `'
bash: error importing function definition for `var'
date
cat: echo: No such file or directory

or

date
cat: echo: No such file or directory

If you see the following (with the current date at the end), you are still vulnerable:

bash: var: line 1: syntax error near unexpected token `='
bash: var: line 1: `'
bash: error importing function definition for `var'
Fri Sep 26 09:20:00 UTC 2014

2014-06-05 OpenSSL CCS Injection Vulnerability

A number of OpenSSL security vulnerabilities were announced on 2014-06-05 that affect most versions of OpenSSL currently in use. The most significant one was CVE-2014-0224, which allows an attacker to intercept communications between two vulnerable OpenSSL implementations (such as a browser and a web server). In most scenarios, this is not an issue since most consumer browsers do not use OpenSSL.

Having said that, this is an important security issue and we recommend that all Bitnami users upgrade their servers if their Bitnami application or server was released previous to 2014-06-05.

Secure your machine

Follow the steps below:

  • Patch the library located in the /opt/bitnami directory, by downloading and installing an update for your platform.

    • For Ubuntu Linux 14.04 64-bit systems:

      $ wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1h-0-linux-x64-installer.run
      
    • For Ubuntu Linux 14.04 32-bit systems:

      $ wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1h-0-linux-installer.run
      
  • Install the patch using the commands below:

     $ chmod +x ./bitnami-opensslfixer-*-installer.run
     $ sudo ./bitnami-opensslfixer-*-installer.run
    

The patch will check if your installation is vulnerable and if so, update the library version to a safe one. At the end of the patching process, it will ask for permissions to restart your services (recommended) so the changes take effect. It will also save all the updated files in the /opt/bitnami/opensslfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/opensslfix/backup/ directory.

  • Update the system OpenSSL library:

    • For Ubuntu and Debian systems:

      $ sudo apt-get update
      $ sudo apt-get install -y openssl libssl1.0.0
      
    • For RedHat, CentOS and Fedora systems:

      $ sudo yum -y update openssl
      
  • Check that the library was updated:

    $ /usr/bin/openssl version -a
    OpenSSL 1.0.1 14 Mar 2012
    built on: Mon Jun  2 19:37:18 UTC 2014
    
  • Restart any service using libssl. To find the list of those services, use the command below:

    $ sudo lsof -n | grep ssl | grep DEL
    vsftpd     481       root  DEL       REG              202,1              393314 /lib/x86_64-linux-gnu/libssl.so.1.0.0
    monit     1269       root  DEL       REG              202,1              393314 /lib/x86_64-linux-gnu/libssl.so.1.0.0
    

    Then, restart the services. Using the example above, here are sample commands:

    $ sudo /etc/init.d/monit restart
    $ sudo /etc/init.d/vsftpd restart
    

2014-04 Heartbleed Bug

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by SSL/TLS encryption.

OpenSSL versions from 1.0.1 through 1.0.1f (inclusive) are vulnerable and make it possible to steal information, including the encrypted content and the secret key used for the encryption. The attack is also undetectable.

If you are running any of the affected versions on an SSL-enabled website, meaning that you can access it using HTTPS instead of HTTP, patch the libraries in your system and replace the certificates and keys that may have been compromised. Please notice that remote access using SSH is NOT affected.

Find more information about the issue.

Detect if your machine is vulnerable

  • If you are running a Web server with SSL enabled, test whether it is vulnerable using this website.

  • Alternatively, log into the server and check the OpenSSL version by executing the command below:

     $ openssl version -a
    

    If the version in the output is greater or equal to v1.0.1 and lower than or equal to v1.0.1f, you may be affected. An example of an affected version would be:

       $ openssl version -a
       OpenSSL 1.0.1 14 Mar 2012
       built on: Wed Jan  8 20:45:51 UTC 2014
       platform: debian-amd64
    

    An example of a secure version would be:

       $ openssl version -a
       OpenSSL 1.0.1g 7 Apr 2014
       built on: Tue Apr  8 09:07:07 CEST 2014
       platform: linux-x86_64
    

    In this example, the OpenSSL version is greater than v1.0.1f and so it may be considered secure. This is the output you will see if you use our patch installer to update your SSL version (described in the next section)

    Another detail to check is the "built on" date. Some Linux distributions have provided security patches that fix the vulnerability without upgrading OpenSSL. The "built on" date should be newer or equal to April 2014 to consider it secure. An example of a patched OpenSSL version would be:

       $ /usr/bin/openssl version -a
       OpenSSL 1.0.1 14 Mar 2012
       built on: Mon Apr  7 20:33:29 UTC 2014
       platform: debian-amd64
    

    In this example, the OpenSSL version is in the vulnerable range but it may be considered secure as it was patched in April 2014.

Secure your machine

Follow the steps below:

  • Patch the library located in the /opt/bitnami directory, by downloading and installing an update for your platform.

    • For Ubuntu Linux 12.04 LTS 64-bit systems:

      $ wget  http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
      
    • For Ubuntu Linux 12.04 LTS 32-bit systems:

      $ wget http://downloads.bitnami.com/files/download/opensslfixer/bitnami-opensslfixer-1.0.1g-1-linux-installer.run
      
  • Install the patch using the commands below:

     $ chmod +x ./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run
     $ sudo ./bitnami-opensslfixer-1.0.1g-1-linux-x64-installer.run 
    

The patch will check if your installation is vulnerable and if so, update the library version to a safe one. At the end of the patching process, it will ask for permissions to restart your services (recommended) so the changes take effect. It will also save all the updated files in the /opt/bitnami/opensslfix directory and the replaced files (in case they are needed to perform a rollback) in the /opt/bitnami/opensslfix/backup/ directory.

  • Update the system OpenSSL library:

    $ sudo apt-get update
    $ sudo apt-get install -y libssl1.0.0 openssl
    
  • Check that the library was updated:

    $ /usr/bin/openssl version -a
    OpenSSL 1.0.1 14 Mar 2012
    built on: Mon Apr  7 20:33:29 UTC 2014
    
  • Restart any service using libssl. To find the list of those services, use the command below:

    $ sudo lsof -n | grep ssl | grep DEL
    vsftpd     479   root  DEL  REG     202,1         394910 /lib/x86_64-linux-gnu/libssl.so.1.0.0
    monit     1254   root  DEL  REG     202,1         394910 /lib/x86_64-linux-gnu/libssl.so.1.0.0
    

    Then, restart the services. Using the example above, here are sample commands:

    $ sudo /etc/init.d/monit restart
    $ sudo /etc/init.d/vsftpd restart
    

Next steps

After applying the patches above, double-check if your website is still vulnerable using this website.

The vulnerability allows an attacker to steal private keys, which would allow it to decrypt any information, as well as impersonating your server. It is advisable to revoke potentially-compromised keys and reissue and redistribute new ones. This is only necessary if you configured HTTPS using your own certificate. In this case, regenerate new certificates and configure them again in your server.

Please direct any questions you have about this issue on our community website. Bitnami Cloud Hosting customers can use the Bitnami helpdesk.

2013-11 PHP security issue

PHP versions 5.3.x before 5.3.12 and 5.4.x before 5.4.2 are vulnerable and allow attacks via remote code execution.

Please note that even if your machine has been compromised, the attacker scripts run with the same permissions as the Apache web server (the daemon user), so the attacker does not have rights to modify any files owned by the bitnami user or root user. The attacker scripts are usually used to scan other machines.

Find more information about the issue.

Prevent access

To prevent unauthorized access, log into your servers and remove the following files by executing the command:

$ sudo rm -f /opt/bitnami/apache2/cgi-bin/php-cgi /opt/bitnami/apache2/cgi-bin/php-cgi.bin

Detect if the system is compromised

  • Check Apache log files and search for cgi-bin/php-cgi requests. If there are any present, it is possible that your machine has already been attacked. Use the command below:

     $ egrep 'POST /cgi-bin/php-cgi.*6E HTTP.* 200 ' /opt/bitnami/apache2/logs/access_log
    
  • Alternatively, detect if your machine has been compromised by executing the following commands:

     $ ls -asl /tmp /var/tmp
     $ sudo ps -Udaemon -u daemon
     $ sudo crontab -l -u daemon
     $ sudo atq
    

    If you notice any processes running apart from atd or httpd, or if you see any suspicious files owned by the daemon user in the /var/tmp or /tmp directories, or if you see any strange cron jobs defined for the daemon user, it means your machine is affected.

Remove attacker scripts

Follow these steps:

  • Ensure that your Apache configuration is correct to avoid problems on restart.

  • Execute the following script:

     mkdir -p /home/bitnami/201311-security-issue
     cd /home/bitnami/201311-security-issue
     sudo sh -c '. /opt/bitnami/scripts/setenv.sh && /opt/bitnami/apache2/bin/apachectl -t'
     if [ $? != 0 ]; then
       echo 'APACHE CONFIG PROBLEM!!!'
     else
       cp -r /opt/bitnami/apache2/cgi-bin .
       sudo rm -f /opt/bitnami/apache2/cgi-bin/php-cgi /opt/bitnami/apache2/cgi-bin/php-cgi.bin
       mkdir -p attacker_files
       cd attacker_files
       sudo mv /var/spool/cron/crontabs/daemon crontabs_daemon
       mkdir -p daemon_tmp_files daemon_var_tmp_files
       find /var/tmp/ -maxdepth 1 -user daemon -print0 | sudo xargs -0 mv -t daemon_var_tmp_files --
       find /tmp/ -maxdepth 1 -user daemon -print0 | sudo xargs -0 mv -t daemon_tmp_files --
       sudo ps -Udaemon -u daemon | grep -v PID | awk '{print $1}'| sudo xargs kill -9
       sudo /opt/bitnami/ctlscript.sh restart apache
     fi
    
  • At the end of this process, reboot the system.

azure

Bitnami Documentation