Docker has suffered yet another security setback with news that the open-source software requires an update to fix exploits that were introduced via a security fix in November. The security update has come with less fanfare than the November patch, but  users of Docker 1.3.2 - an urgent security upgrade itself - have been urged to upgrade yet again to 1.3.3, which was released on Dec. 11

The open-source software packages applications into “lightweight” containers for virtualization. Version 1.3.2 patched two security vulnerabilities that could allow remote attackers escalated privileges on a system running Docker – privileges that would allow an attacker to execute malicious code. The previously patched flaws (CVE-2014 6047 and 6048) referred to ”Docker's handling of images and archives, and allow remote execution because versions of Docker up to 1.3.1 will obey instructions included without carrying out sufficient checks”, as previously reported by DatacenterDynamics.

New flaw introduced
The security advisory has credited independent security researcher Tõnis Tiigi for discovering two of the latest Docker bugs (CVE-2014-9356 and 9357), with Docker’s Eric Windisch given credit for a third (CVE-2014-9358). The Register has described the vulnerability:

“It seems that although the 1.3.2 patch introduced "chroot" sandboxing when uncompressing Docker images to close the earlier vuln, it brought with it yet another bug that could be exploited by including malicious .xz binaries in image files. The result is that an attacker can potentially execute arbitrary code with root-user privileges on affected systems.”

In addition to version 1.3.3 fixing three vulnerabilities, Docker also released version 1.4.0, which included the security patches. Version 1.4.0 also includes is an emphasis on bug fixes and platform stability, with 180 commitments for bug fixes merged into one release, according to a blog post from Marianna Tessel, Docker’s senior VP of engineering. Tessel added that version 1.4.0 will include the Overlay Filesystem as a new and experimental storage driver.

The bulk of Tessel’s blog focused on Docker’s commitment to security and what the open-source project is doing to address these issues. “Security is of paramount importance to Docker”, she noted, adding that the “Docker Engine takes advantage of the security mechanisms and isolation provided by the OS.” Some of the other security initiatives Tessel highlighted:

1. On systems where supported, Docker has incorporated SELinux and AppArmor integration. Red Hat, Canonical, and other companies have been active members of the Docker community to help us drive security forward.

2. We have added signed Docker images in our Docker Hub Official Repos starting in release 1.3. This is the first step towards a more robust chain of trust that allows users to have confidence in the origin of their images. However, do note that untrustworthy sources may still create signed images and it will be up to users to trust, or not trust, the developers of those images.

3. We perform our own security testing as well as engaging a private security firm to audit and perform penetration testing. Issues are also received by our active user and developer community. All issues found or reported are promptly triaged, with critical issues initiating an immediate response. Our goal is to have security fixes for the current stable release in the hands of our users absolutely as quickly as possible.

4. We practice responsible disclosure. Without compromising users, we disclose and provide updates on security issues in a timely manner by issuing security releases and associated security advisories. We further plan to enhance our security page where we will be providing a historical accounting of published advisories and will provide a hall of fame for researchers.