Announcing findings from security audit

The CNB project is proud to have recently completed a security review, working with Quarkslab and the Open Source Technology Improvement Fund (OSTIF). Today, we are publishing releases of pack (0.35.0) and the lifecycle (0.20.0) that contain fixes for vulnerabilities identified in the review. Please upgrade as soon as possible to get the benefit of these fixes.

This post discusses the high severity vulnerabilities identified in the review and provides links to the full list of vulnerabilities and their remediations. Findings and recommendations from the review are also discussed on Quarkslab’s blog and OSTIF’s blog.

Spotlight: high severity issues

Many of the vulnerabilities, especially the high severity ones, relate to the use of pack and the lifecycle in CI/CD systems, such as multi-tenant build environments using a shared Docker host.

(High 1) Host compromise by overwriting trusted container images — this can occur when a shared Docker host is used as both a source and a sink for build input and output images. A malicious pack user could build an application image with the same image name as a build input (such as builder, lifecycle, or run images), causing future builds by other users of the build system to pull in the malicious input. We address this problem by:

• Forbidding application names that match trusted build inputs (pack issue)
• Warning pack users to pull build inputs from a registry when we detect that pack is running in a container (a common scenario for a shared Docker host) (pack issue)

A registry is a safer source for build inputs as user permissions prevent unauthorized writes

• Informing our end users that using ​​a shared Docker host as a source for build inputs is insecure

(High 2) Cache poisoning by accessing other applications’ caches — this can occur when volumes managed by a shared Docker host are used as build and launch caches. We address this problem by:

• Introducing the concept of a pack “volume key” that will make volume names difficult to determine without the key (pack issue)
• Informing our end users that cache images (stored in a registry) are safer repositories for build caches (see above re: user permissions)

In total

The full list of vulnerabilities identified and their remediations are shown below:

(High 1) Host compromise by overwriting trusted container images

• See work to validate application names and warn if NOT — pull-policy=always in container, released in pack 0.35.0

(High 2) Cache poisoning by accessing other applications’ caches

• See work to ensure ownership of build and launch caches, released in pack 0.35.0

(Med 1) Docker in-container privilege escalation

• See work to set security-opt field to no-new-privileges:true, released in pack 0.35.0

(Med 2) Docker permissive inter-container connectivity

• See work to launch build containers in a separate ephemeral Docker bridge network, released in pack 0.35.0

(Low 1) Denial-of-Service (DoS) provoked by race condition

• Partially mitigated by work to recover corrupt caches, released in lifecycle 0.20.0; see also a strategy considered to prevent simultaneous builds of applications having the same name that we chose not to implement at this time

(Low 2) Denial-of-Service (DoS) provoked by removing build cache tarballs or altering the OCI image manifest

• Partially resolved (for volume caches) by work to recover corrupt caches, released in lifecycle 0.20.0

(Low 3) Denial-of-Service (DoS) provoked by an unbound execution time

• We chose not to address this one at this time, leaving management up to the platform or end user; see issue to bound buildpack execution time

(Low 4) Data leak by accessing other applications’ caches

• See work to ensure ownership of build and launch caches, released in pack 0.35.0

(Info 1) Specification violation using Docker and user namespaces

• See work to run build containers with userns=host, released in pack 0.35.0

(Info 2) Excessive Docker container capabilities

• We are leaving this one open for further investigation, see issue to investigate which container capabilities are truly needed for build

Feedback welcome

The CNB project is constantly striving to make our software the most secure and reliable for platforms and developers everywhere.

Found a security issue? We appreciate your help! Follow the instructions in our security policy to report it responsibly.

Got feedback or want to join the conversation? Head over to our community page. We’d love to hear from you!