What is tar and why does OpenShift Container Application Platform use it?

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Tar is a Posix standard archiving utility originally meant for making tape archives; one of tar's most enduring uses has been for system backups. Tar can take everything that is stored on a filesystem and store it in a structured file, including special files such as links and devices. This capability has made tar a popular storage format for more than 38 years.

Red Hat's OpenShift Container Application Platform is a PaaS (Platform as a Service) that integrates many Red Hat software components and technologies (storage, middleware, etc.). Besides being an excellent platform for running applications, OpenShift has many integrated options to help you build and maintain those applications. One such option is the Source-to-Image (S2I) tool:

Source-to-Image (S2I) is a tool for building reproducible Docker images. It produces ready-to-run images by injecting application source into a Docker image and assembling a new Docker image. The new image incorporates the base image (the builder) and built source and is ready to use with the docker run command. S2I supports incremental builds, which re-use previously downloaded dependencies, previously built artifacts, etc.

S2I is not limited to stateless builds that start fresh from original configuration and data files each time. Through a feature called "incremental builds", S2I can re-use previously built or imported artifacts. Re-using third-party imports prevents having to wait for a full install each build. Re-using sub-builds means that a front-end change can potentially proceed without needing to wait for a full backend build. S2I accomplishes this by utilizing previous versions of the built image:

During the build process, S2I must place sources and scripts inside the builder image. To do so, S2I creates a tar file that contains the sources and scripts, then streams that file into the builder image. Before executing the assemble script, S2I untars that file and places its contents into the location specified with the --destination flag or the io.openshift.s2i.destination label from the builder image, with the default location being the /tmp directory.

What is CVE-2018-1102?

CVE-2018-1102 is an issue created by the interaction of tar's relative path features and S2I's high level of privilege. By carefully crafting tar content, an attacker can overwrite host filesystem content and can potentially compromise the node hosting the build.

tar is a storage format used to archive many varieties of filesystem content including: backups, source code, and binary packages. To make these archives portable, the tar format supports relative paths. This allows a tar archive to install files not just further down into the filesystem from where it is unpacked but further up as well. For example, the relative path "../../../file" would install "file" three levels up from the directory where the tar was being unpacked. This feature is not necessarily always needed, but it is faithfully reproduced in the Go tar library that is used by OpenShift.

S2I must manage containers, container filesystems, and collaborate with OpenShift orchestration (e.g. for on-demand builds). As a result, it runs with a high level of privilege including the ability to write to the host filesystem. When unpacked by the S2I service, a particularly constructed relative path in a tar archive can escape the intended buildroot and install content on the host filesystem. This level of access can easily be leveraged into full control of the host.

Previously, S2I did not check for potential escapes. Red Hat has made changes that prevent the use of relative paths to escape the buildroot directory and block other potentially dangerous features.

How is Red Hat affected?

OpenShift Container Application Platform 3.x is affected, from 3.0 through 3.9. Additionally the OpenShift Online service was affected, however this has been patched to address the issue. Disabling S2I builds completely mitigates this issue. Updates have been made available for OpenShift 3.4 and up. Hotfixes are pending for versions 3.1 through 3.3.

What do you need to do

You should install the security updates for CVE-2018-1102. If you cannot do this, or need time to evaluate the patches, you can also disable S2I builds. For more information on this issue please read the vulnerability article explaining CVE-2018-1102.