Wednesday, July 20, 2016

Security notification: httpoxy A CGI application vulnerability (CVE-2016-5385, CVE-2016-5387, CVE-2016-1000110)


On July 18th, a vulnerability named ‘HTTPoxy’ was announced, affecting some server-side web applications that run in CGI or CGI-like environments, such as some FastCGI configurations.

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
More information about the vulnerability can be found on the httpoxy website.

Any PHP-based, Python-based or Tomcat-based Bitnami application is affected by this security issue.

We believe it is of the utmost importance to quickly address any security issues in applications distributed by Bitnami and our team is working to update all of the affected Cloud Images, Virtual Machines and Native Installers available through Bitnami.

Please take a moment to check if your image is vulnerable by following the instructions in the security section of our wiki.

You can mitigate the issue by blocking the Proxy request headers as early as possible, and before they hit your application. This is easy and safe.

Apache


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

  •  Save the file and restart the service of Apache
sudo /opt/bitnami/ctlscript.sh restart apache 

Nginx


  • Add this line at the end of the file at /opt/bitnami/nginx/conf/fastcgi_params.
fastcgi_param  HTTP_PROXY "";

  • Save the file and restart the service of Nginx
sudo /opt/bitnami/ctlscript.sh restart nginx 


If you have any questions about this process, please post to our community support forum and we will be happy to help!

Update: 2016-07-22


The Bitnami Team has been working on releasing all the affected stacks in the different cloud vendors and we have to announce that the images of Google, Azure, 1&1 and GoDaddy have been updated properly. 

We continue working on releasing pending cloud platforms, virtual machines and the native installers. 

Update: 2016-07-26


All the cloud images, virtual machines and native installers that were affected by this security issue have been successfully patched and they are already available through Bitnami and our cloud partners. 

If you are using a Bitnami Cloud Hosting instance, you can easily patch it following the guide above while we upgrade the base image. 

Monday, June 27, 2016

Develop Collaboratively with Eclipse Che, Now on Bitnami!

Eclipse Che is an open source cloud IDE and developer workspace server featuring containerized workspaces that accelerate agile software development. Containerized workspaces let developers bootstrap projects without having to install software, and collaborate on projects from anywhere. With Eclipse Che in Bitnami, you can now launch the application in your own cloud account on the most popular platforms like AWS, Google Cloud Platform, and Oracle, in just a few clicks.

Shareable workspace server

Each Eclipse Che instance is given its own hostname, and is designed to be accessed by multiple clients at the same time- the only limit is the system’s disk and memory.

Each developer workspace in Eclipse Che consists of a project (your code) and the runtime for the language the project is written in. You can use the included runtimes or create your own by referencing Docker images or Dockerfiles. The Eclipse Che configuration file encompasses project sources, build/debug runtime, and execution commands in a single JSON object. The config file is used to launch the workspace in its own Docker container, thereby eliminating conflicts among dependencies no matter how many runtimes you are using. Developers can use the Eclipse Che workspace from its lightweight browser IDE or use their favorite desktop IDE by mounting the workspace over SSH. Workspaces are even reachable via API, enabling them to be created/altered programmatically or run as part of your CI/CD system.


Thin, lightweight, yet powerful IDE

The application’s browser IDE enables developers to access the workspace from any device and from anywhere in the world without needing to download any software. Hosting the IDE in the cloud and running it in the browser eliminates time wasted configuring and maintaining the environment for each individual contributor. The browser IDE allows you to work in multiple workspaces in different browser tabs so you can switch back and forth between projects with a simple keyboard shortcut.


Extensibility and open source community

Eclipse Che has a vibrant community, with contributions from large corporations like Microsoft and Red Hat alongside individual open source contributors from across the globe. There is a large and growing number of extensions for the IDE, the workspace agent, or core server, and you can also develop your own custom extensions using the SDK.

This introduction only scratches the surface of what Eclipse Che is capable of -- for more information on the application’s features, please visit their features page. Or you can launch Eclipse Che in your own cloud account and get up and running in just a few minutes!

Saturday, June 25, 2016

Security Release: Node.js 4.4.6

The Node.js project has just released a new version that fixes a vulnerability under certain conditions: V8 may improperly expand memory allocations in the Zone::New function. This is related to the CVE-2016-1669.

Read more about the security issue on the Node.js blog.

We want to let Bitnami users know that Node.js 4.4.6 installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your Node.js applications to the latest version.

If you work with containers, Stacksmith already has the latest versions of Node.js available.

Do you have questions about Bitnami Node.js or the security issues? Please post to our community forum and we will be happy to help.

Security Release: PHP 5.5.37

A PHP security issue that affects previous versions of PHP was recently announced. A signedness vulnerability (CVE-2015-8874) is present that allows remote attackers to cause a denial of service via a crafter imagefilltoborder call. 


We want to let Bitnami users know that all MAMP, LAMP, WAMP Stacks installersvirtual machines and cloud images have been updated and released. We strongly suggest that you update your PHP stacks to the latest version.

If you work with containers, Stacksmith already has the latest versions of PHP available.

Do you have questions about Bitnami PHP stacks or the security issues? Please post to our community forum and we will be happy to help.

Sunday, June 19, 2016

Introducing Bitnami Development Containers

Folks who have known me for a while, know that I love to make things easy for developers. From my days as a usability engineer on the Visual Studio team, to my pet projects, to my tutorials and samples, making programming easy and fun has been a theme of my work since 1998.

Now at Bitnami, I am happy to be working with a team who is as excited about this as I am. We have started a project that takes advantage of Docker to make developing with whatever framework you choose easy and fun. We call this project “Bitnami Development Containers.” This project is an extension of the development process that we have created for our own internal development. It only made sense to share our experience with developers everywhere.

We are in the beginning phase of the public part this project, and we are practicing the “release early and often” strategy, so let’s see what people think.

The basic idea behind the project is that if you have Docker enabled on your development machine, trying a framework should be as simple as what I affectionately call, “curling up”. That means that all you need to do is curl (download) a docker-compose file, and then run it with the docker-compose up command. After those two steps, and only those two steps, you can see your app running and start coding. It is that easy.

To accomplish this, we had to do a couple of things:
  1. First, we created custom containers that are meant specifically for developing with the frameworks of interest. These containers have an entry point that is designed to get developers going with zero configuration. We take care of all the configuration and any code generation necessary to get started.
  2. We include any necessary infrastructure and orchestrate them together using a simple docker-compose file. That means that if your framework of choice requires a database, maybe a specific database configured in a specific way, you don’t have to worry. We took care of all the work to set it up that way. You can just start coding.
So, for any framework that we support, with a development container, for example, if I wanted to write some good old Ruby on Rails code, I would just do this:

$ mkdir myrailsapp
$ cd myrailsapp
$ curl -L "https://raw.githubusercontent.com/bitnami/bitnami-docker-rails/master/docker-compose.yml" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Rails welcome page. 

The exact same process works for Express:

$ mkdir express
$ cd express
$ curl -L "https://raw.githubusercontent.com/bitnami/bitnami-docker-express/master/docker-compose.yml" > docker-compose.yml
$ docker-compose up

Then open my browser, go to my docker-machine’s ip address at port 3000. And there’s the Express welcome page. It’s always the same simple steps.

One important thing to note is that the containers are designed to work as immutable infrastructure. By that, I mean, none of the code that is generated or that you write is on the container. Rather, it is also mounted in a volume. That is important because it means that the containers support easy reproducibility. So, if you change some code, you can check in that code, and someone else can check it out, and docker-compose up just works with the existing code.

Ok, let’s just try it. I heard about Laravel. My team says it's pretty cool, but I never really knew what it was. So, I am going to using Bitnami’s Development Container to quickly get started with it.

First thing, I will create a directory for the application that I will write. Then I will download the docker-compose file into that dir. Again, the same simple steps, “curl up.”

$ mkdir laravel
$ cd laravel
$ curl -L "https://raw.githubusercontent.com/bitnami/bitnami-docker-laravel/master/docker-compose.yml" > docker-compose.yml

Screen Shot 2016-06-19 at 11.19.40 AM.png

That went fast, so let’s take a look:

$ cat docker-compose.yml

Screen Shot 2016-06-19 at 11.20.18 AM.png

Ok, that is a nice and simple file. I can see that I am going to get a copy of MariaDB along with it. That’s handy, since as far as I can tell, Laravel and MariaDB go together like peanut butter and jelly. Note also that the port is already mapped for me.

Finally, note that it mounts a volume called “./app”. This is very important and interesting. What this means is that the application code that is generated and that I will modify is NOT in the container, but rather right on my desktop. This is how we achieve the immutability I mentioned above. This way, besides being easy to manage with source control, it is also trivially easy to edit with my desktop editor.

So, I curled, now I up. Of course, make sure that Docker is running before you do this:

$ docker-compose up

Screen Shot 2016-06-19 at 11.22.34 AM.png

The first time I run this, Docker will download the images first. Then it will start the containers.

Screen Shot 2016-06-19 at 11.23.24 AM.png



Looks like the container is started. Let’s check out the app.

First, I’ll check the ip address of my Docker VM:

$ docker-machine ip

Screen Shot 2016-06-19 at 11.24.09 AM.png

Now that I have that, I can navigate to port 3000. Port 3000 is a typical port for development web servers to run on. I could also tell I needed to port 3000 from the docker-compose file.

Screen Shot 2016-06-19 at 11.25.08 AM.png


It works! Let’s pause for a moment and consider how cool this is. In a matter of minutes I went from having an empty Docker environment to having a running Laravel 5 app. And I’ve never used Laravel before.

Of course, the first thing I want to do is to change the default to prove to myself that I have some control over the content.

Because this is my first experience with Laravel and I know almost nothing about it, I will have to poke around a bit. I’ll just guess that the string displayed in the default web page will help me out, so I will start with a recursive grep.

$ grep "Laravel 5" -R ./

Screen Shot 2016-06-19 at 11.28.11 AM.png



That “welcome.blade.php” file looks like a promising start for making my first change. Keep in mind, I have never even written PHP code, much less Lavarel code. But, I love to learn by doing, so I am just going to dive in with my editor and see if I can make a change.


Screen Shot 2016-06-19 at 11.30.40 AM.png

And …

Screen Shot 2016-06-19 at 11.31.57 AM.png


Yup! It’s that easy. Within minutes, I have made a change!

Let’s take another look at my Mac’s directory:


Screen Shot 2016-06-19 at 11.33.18 AM.png



As I mentioned before, you can see that the application code is on my development machine, NOT in the container. Furthermore, the docker-compose.yml file that sets up the development environment is in the same directory. That means I can easily commit this directory and share it. Anyone could check it out from source control, and run $ docker-compose up, and end up with the exact same environment. So, a team of developers could easily use the Bitnami Development Containers to collaborate on projects, and easily stay in sync with both the development environment and the code.

Today we have 3 development frameworks ready. Rails, Express, and Laravel, with more on the way. Please try them out and give us feedback. And please let us know what other frameworks you think we should do next! You can reach us at containers@bitnami.com.

- Rick Spencer, Bitnami VP of Engineering

Thursday, June 16, 2016

Security Release: Drupal 7 and 8

The Drupal project released a new update that fixes several security vulnerabilities. We strongly recommend upgrading your existing Drupal 7 and 8 sites.

Information regarding the additional changes is available in the official security advisory. In response to the new Drupal version, we have released the following: Bitnami Drupal 7 and 8 installers, virtual machines, and cloud images.


Two notable issues include:
  1. A vulnerability exists in the User module, where if some specific contributed or custom code triggers a rebuild of the user profile form, a registered user can be granted all user roles on the site. This would typically result in the user gaining administrative access.
  2. An access bypass vulnerabilty exists in the Views module, where users without the "View content count" permission can see the number of hits collected by the Statistic module for results in the view.
Our new releases fix the known security issues. There are no new features or non-security related bug fixes in these releases.

If you have questions about Bitnami Drupal or these security issues, please post to our community forum and we will be happy to help you.

Automated Container Delivery Using Stacksmith with GitHub

When developing with Docker containers, updates to an application’s stack or environment are rolled out by stopping outdated containers and replacing them with an updated container image. Docker is a popular toolchain for developing applications in containers that makes it incredibly easy to conduct these container image updates. However, the process of deploying updated container images is still a repetitive series of manual steps that can be mechanized. Bitnami built Stacksmith to automate this process.

Stacksmith automates the deployment of container images by maintaining a base Dockerfile, and by keeping each stack up-to-date against version updates and security vulnerabilities. Conveniently, Stacksmith integrates with GitHub so that when there’s an update to an application’s stack, a developer simply has to merge an automatically generated pull request from Stacksmith that contains the updated container image.

This post walks through how you can use Stacksmith with your application on GitHub to provide continuous delivery of your application container images.

Before you get started

This tutorial assumes you have Git, Docker (1.10+) and Docker Compose (1.6+) installed, and that you have some familiarity with these tools.

For this tutorial, we we will run Scotch’s Node Todo App on containers. The Node Todo App is a small, multi-tier and open source application that consists of an ExpressJS application server which connects to a MongoDB server for persistence. This architecture is referred to as a MEAN stack.

Once you confirm that you have the correct tools (Git/Docker/Docker Compose) installed, you are ready to get started by forking the Node Todo App repo on GitHub.

Create Your first Stacksmith Node.js stack

Stacksmith uses stacks to define the environments that make up your Dockerfiles. A stack is comprised of one or two components, most typically a runtime, as well as the base operating system. To run our Node Todo App on containers, we will create a stack that contains the Node.js runtime on top of Stacksmith’s Debian base:

On the Stacksmith homepage, select Node in the dropdown and click on ‘Create Stack’ to start configuring your stack.


Next, follow the instructions to connect your GitHub account to Stacksmith, and select your forked repository, the Node Todo App, in the dropdown list. By connecting your GitHub account with your Bitnami account, Stacksmith will be able to automatically add a Dockerfile to your repository that is configured based on your stack specifications. When there is an update to your stack, Stacksmith will automatically submit a pull request to your GitHub repository keep your application’s container image up-to-date.

Now select Node.js in the components dropdown. This will be the main component in our stack. We suggest that you select ‘6.x’ in the version dropdown, to ensure you only automatically update to security and patch fixes.

Once your components are entered, Stacksmith will prompt you to specify the kind of Dockerfile you need. In this case, the Node Todo App is an ExpressJS application, so you will select ExpressJS in the dropdown to get a Dockerfile that is most suited to running your application.




To complete the stack creation process, leave the base operating system as Debian, and click the ‘Create stack’ button to go ahead and create your stack. The new stack that you created will show up in the ‘Your Stacks’ page with the same name as your GitHub repository.

Merging in your new Dockerfile

To merge your Dockerfile into your forked repository, visit your repository on GitHub by clicking the link at the bottom of your “Stack Info” screen. You will see that Stacksmith automatically opened a pull request to add your new Dockerfile to the repository. Accept the change which adds the Dockerfile to your repository by clicking on the green “Merge pull request” button.

Building and running your application container

Cloning the GitHub repository

Now that your application code has a Dockerfile checked in, you should try it out by running the application. First, clone the repository from GitHub into a directory on your local machine.

> git clone git@github.com:<GITHUB-USERNAME>/node-todo.git
> cd node-todo/

Remember to replace the clone URL with your GitHub repository’s remote URL.

Setting up your Docker Compose file

Docker Compose is a tool that makes it easier to run multi-tiered applications in containers. Using Compose, a developer is able to define each service needed to run their application in a container by creating YAML configuration file. A developer is then able to use Compose to manage the group of containers, specifically by bringing them up and tearing them down as necessary.

Your repository already has a Dockerfile that can be used to run the ExpressJS server, so you can configure Compose to build the image using this Dockerfile with the following directive:

express:
 build: .
 ports:
- 3000:8080
We suggest configuring a port mapping to access the web server from outside the container.

For MongoDB, you will need to reference the Bitnami MongoDB Docker image that can be pulled directly from Docker Hub. This container image will come with everything you need to run a MongoDB server out of the box.

mongodb:
 image: bitnami/mongodb
The full docker-compose.yml file should look like this:
version: “2”
services:
 express:
   build: .
   ports:
 - 3000:8080
restart: always
depends_on:
     - mongodb
 mongodb:
   image: bitnami/mongodb

Building and running your application using Docker Compose

Now that we’ve setup our Compose file, we can go ahead and run the application. To start all the services, run:
> docker-compose up
Oops, it failed! Check the logs to see what went wrong. The issue seems to be that your ExpressJS container is expecting to run the application using the npm start command, however, the Node Todo App hasn’t been configured to specify the correct start script to run in the package.json. To fix the issue, you can modify your package.json file to run the server.js script when using npm start, or you can more easily change the container startup command in the Stacksmith generated Dockerfile.

We suggest the latter option in order to demonstrate how you can go about customizing the Dockerfile generated by Stacksmith. In your Dockerfile, change the CMD line from:


CMD [“npm”, “start”]


to:


CMD [“node”, “server.js”]


If you rebuild and run the application again, you will see that the Node Todo App crashes because it is unable to connect to MongoDB. By default, the Node Todo App is configured to connect to MongoDB on localhost. The host needs to be changed to use the Service Discovery on the Docker Network that Compose sets up for us. To do this, change config/database.js to:


module.exports = {
   remoteUrl : 'mongodb://node:nodeuser@mongo.onmodulus.net:27017/uwO3mypu',
   localUrl: 'mongodb://mongodb/meanstacktutorials'
};


Now run docker-compose up --build and you will see that both containers start successfully, and you should try to access the Node Todo App in your browser at DOCKER_IP:3000, replacing DOCKER_IP with the IP address of your Docker Machine (if running in a VM), or localhost if running locally.


To find out the IP address of your Docker Machine instance, you can run the following command:


> docker-machine ip $(docker-machine active)

Committing and pushing your changes to GitHub

Now that you have made changes to the Dockerfile to run your container, you should commit and push your changes to GitHub.


After pushing the changes to GitHub, visit Stacksmith to see that your changes have been tracked correctly. This will ensure that when there is an update for your stack, your changes will be kept when you regenerate the Dockerfile.

Automating your container builds using Docker Hub Automated Build

To have your container continuously built when you update your application code, or when there is an update in your stack, you can setup an Automated Build repository in Docker Hub. For documentation on setting this up with your repository, visit the Docker Docs: https://docs.docker.com/docker-hub/builds/

Receiving a stack update from Stacksmith

At this point you should have the following setup:
  1. Stack in Stacksmith that defines your application’s runtime requirements.
  2. Dockerfile generated by Stacksmith for building your application container.
  3. Connection to Docker Hub automated builds that automatically build and push your container to the Docker Hub Registry when you make changes in your repository.

What happens when a new version of Node.js is released? Or what happens when there is a security patch available for either Node.js or one of the packages in the Debian base image? In the container world the existing procedure for dealing with this scenario is to rebuild the whole application container on top of the new, updated and secure stack. Stacksmith introduces a new and easier way to deal with updates to your stack.


For example, it may turn out for you that within days or weeks of creating your stack, an update to Node.js may become available. When an update is released, Stacksmith will notify you via email, Slack, or a custom webhook.


For me, several days after I created my Node Todo App stack I received an email notification that I can update to Node.js 6.2.1. Below are the steps I followed to regenerate my Dockerfile:


Going back to Stacksmith to view my stack, I can see that I am currently using 6.2.0 and I can regenerate my Dockerfile to update to 6.2.1.
I click the “Regenerate” button to instruct Stacksmith to create a new stack with the updated version.
Next, I head over to my forked repository on GitHub where I can see that Stacksmith also created a new pull request with an update to the Dockerfile. The Stacksmith Bot leaves my Dockerfile modifications unchanged, and simply updates the referenced version of Node.js and the metadata about the new stack.


After I merge the pull request from Stacksmith, my Docker Hub integration kicks off an automated build using the new Dockerfile. Then after a few moments, I have a new Docker image for running my Node Todo App on top of the latest Node.js version. I can then reference the new Docker image in the Compose file, or a Kubernetes manifest and re-deploy my application.


If I want a more complete workflow for a production use-case, I can automate the deployment with an existing CI/CD pipeline that will kick-off after the merge of the Stacksmith pull request.


That’s all! If you are using Stacksmith to run your applications in development or production, please let us know! We’re eager to hear how we can improve Stacksmith for you.

Watch a demo of our Stacksmith and GitHub integration:

Wednesday, May 18, 2016

Security Release: Magento 2.0.6


The Magento project has released a new update that fixes several security vulnerabilities. A few of the notable fixes include:
  • APPSEC1420: Magento no longer permits an unauthenticated user to remotely execute code on the server through APIs.
  • APPSEC1421: The Magento installation code is no longer accessible once the installation process has completed.
  • APPSEC1422: Magento no longer allows authenticated customers to change other customers' account information using either SOAP or REST calls.

We highly recommend upgrading your existing Magento Community Edition 2.0 sites. For more information about the security issues fixed with this recently released update, please check out Magento's Security Center.

We have released Bitnami Magento 2.0.6 installersvirtual machines and cloud images that fix the security issues.

If you already have a running version of Bitnami Magento, you can upgrade the application by following the detailed steps on our wiki page:

https://wiki.bitnami.com/Applications/BitNami_Magento#How_to_upgrade_Magento.3f

Do you have additional questions about Bitnami Magento? Post to our community forum, and we will be happy to help you.