On May 8, 2019, a vulnerability impacting the popular Alpine docker image was announced. The vulnerability is in the default configuration of the /etc/shadow file and the root user account. In versions of Alpine greater than 3.2, the root user is configured with a null password, however the impact of this vulnerability can be mitigated through a configuration change.

Configuration errors of this type aren’t common, and the Alpine project has worked hard to insure they are shipping a minimalist and secure base image. You can quickly evaluate whether you are impacted by inspecting the /etc/shadow file in a container or image using Alpine as the base image and look for:


A properly configured root user will look like this:


Note: In the top example the encrypted password field for the root user is empty, or null, whereas in the bottom example there is an exclamation mark (!) in encrypted password field. More information is available in the Cisco Talus write up and the Alpine Linux team has issued a formal summary of the vulnerability and details on their website.

There are a large number of popular applications that use Alpine as a base image, and it can be difficult to determine which of your images are vulnerable or downstream configuration has mitigated the vulnerability in the shipped configuration for the application.

While Twistlock itself uses Alpine, our image is not vulnerable. Twistlock doesn’t include ssh or any other process that uses the shadow file to authenticate users. Further, starting with 19.03 releases, the password is also not set to a null value.

For other software you may have deployed, or made available to your development teams to build on, Twistlock includes capabilities that allow you to evaluate the impacts of this vulnerability across your environment and prevent containers from launching that are vulnerable to this configuration error.

How Twistlock can help: Custom compliance checks

Twistlock includes the ability to build custom compliance checks against your images and, if you choose, prevent containers from starting up if they violate these checks. This capability is on top of the over 350 checks Twistlock ships out of the box that include the CIS benchmarks for Docker, Kubernetes, Linux, and AWS.

To evaluate whether your images are vulnerable in Twistlock you can simply add a custom compliance check in the Twistlock Console GUI, or via the API.

Adding the custom check

For the purposes of this post we’ll talk about how to add the check through the GUI. On your Twistlock Console navigate to Defender > Compliance > Custom and select Add Check.

Add the following script to the editor that pops up and save the check. You can also specify the severity of the check at this time.

if [ $(cat /etc/shadow | grep  'root:::0:::::') ]; then exit 1; fi

Implementing the custom check

After the check is built you can choose which assets, or combination of assets you’d like to apply this check to, by navigating to Defend > Compliance > Containers and images and selecting Add rule. Then, as you can see in the following screenshot, you can choose to Alert on the detection of this configuration or Block containers that violate the newly built compliance rule from starting up.

Compliance rule apply

You can see the results of this check across your running infrastructure as well as your images at rest. In the example below the check we’ve built is id 9001, and you can see the results of our custom as well as the other checks I have applied to this container image.

You can also evaluate these checks in your CI system giving you a perspective on the security and configuration of your images across the lifecycle, choosing to fail builds in the CI system based on configuration errors such as the one described here before these images make it out of your CI system and get pushed to your registry.

← Back to All Posts Next Post →