Executive Summary
The unstable release, as its name implies, is an OS distro release where active development takes place. Unsurprisingly, it is also the most volatile release version. It often happens that images contain unstable package versions; those packages expose the image to vulnerabilities and may expose its users to risk. In this blog post, I will discuss a case of a vulnerable unstable OS package in the Redis image that was caught by the Prisma Cloud.
Debian Backports and Releases
Debian is a Linux distribution composed of free and open-source software.
Debian has three main releases: "stable", "testing" and "unstable”.
- Stable: Up-to-date and recent Debian version.
- Testing: Packages from unstable releases that have been tested will move to the Testing release.
- Unstable: Release where active development takes place. This kind of release is most prone to vulnerabilities.
As of the time of writing this post, the most recent version of Debian is Debian version 11, codenamed "Bullseye".
Once a package reaches the testing release, it’s possible to build and include a backport of that package to stable release. Backports track testing release and only package versions included in testing are allowed in it.
The backport goal is to add features that are only offered in a new version, not a replacement for getting fixes into stable release.
The naming convention is: "~bpo${release}+${build}" to the version number, e.g., "4.5-6" becomes "4.5-6~bpo11+1" (or use dch --bpo).
Redis Image
Redis is an open-source key-value store that functions as a data structure server.
The latest Redis image has been recently upgraded to use Debian 11 bullseye as a base-image, and contains several packages vulnerable to known vulnerabilities, such as: glibc, krb5, pam, perl etc.
Prisma Cloud scanned Redis image and found that it contains the pam package in version 1.4.0-9, which according to the Debian CVE tracker, is vulnerable to CVE-2020-36394.
We tested multiple open-source vulnerability scanning tools, but only Prisma identified pam packages as vulnerable. Prisma Cloud found that pam source package is used in 4 other packages.
As you can see in the screenshot below, the vulnerable package version is 1.4.0-9+deb11u1.
From further look at the CVE notes we find that the vulnerable code was introduced and fixed in v1.4.0.
Unique Vulnerability Identification or False-Positive
In the Prisma Cloud research team, we regularly analyze vulnerabilities to determine the validity of their description and information, as well as to determine the correct ranges and packages so they are properly applied to Prisma Cloud users.
For this CVE, Debian mentioned that the vulnerable code was introduced and fixed in v1.4.0.
An attacker can set a quota on an arbitrary filesystem, in certain situations where the attacker's home directory is a FUSE filesystem mounted under /home.
And was part of the “new module to set or modify disk quotas on session start” commit.
According to NVD, the vulnerable package depends on the package build date:
“...pam_setquota.c in the pam_setquota module before 2020-05-29 for Linux-PAM allows local attackers to set their quota on an arbitrary filesystem, in certain situations where the attacker's home directory is a FUSE filesystem mounted under /home…”
At Debian bug tracker there is no reference for this issue because from linux-pam side, the vulnerable code was introduced and fixed in the same version.
Pam 1.4.0-9 is a testing package and is vulnerable to CVE-2020-36394.
The official fix was introduced only at the stable version of Debian pam version: 1.4.0-9+deb11u1.
The Prisma Cloud engine successfully identifies pam 1.4.0-9 as a vulnerable package, and it is the only tool we tested that discovered this vulnerability.
Unstable releases are complex and hard to analyze, however, Prisma Cloud managed to uniquely discover this vulnerability compared to other scanners.
Remediating the Vulnerability
Next, we will determine if Prisma Cloud detects that image was updated when the vulnerability was patched.
- Pulling the relevant Redis image tag: redis@sha:0c0484b1d1ff36faace984fe9d8e0fe58892ecc34a4859b97171045b9cd343e1
2. Verifying libpam version.
3. Prisma Cloud identified the pam package as vulnerable.
4. Upgrade pam package
5. If we will verify the libpam version again, we can notice it’s upgraded to the fixed version.
6. Checking again the Prisma Cloud Console, the vulnerability is gone.
Conclusion
Accurate vulnerability identification is a critical part in supply chain security. It is the first necessary step to cloud security, keeping your code safe from known and unknown vulnerabilities. Proper vulnerability management is another part of the chain. The more synergy there is between the two, the safer your deployments will be.
Even more when it comes to Linux distribution. There are so many differences in how every distribution maintains and manages packages. Those differences can include the way they disclosed, solved, and patched security vulnerabilities. Packages can be backported on some distros and can be available only for specific releases, or even from an external repository, it all joins the way every distro handles security issues for its own components.
The cost of incorrect identification (false positives) is very high for security teams. Tools that bombard security teams with inapplicable vulnerabilities are time consuming and, in some cases, they can cause unnecessary down time, incorrectly alerting on high severity vulnerabilities. On the other hand, the cost of lack of identification (false negatives) is even higher, as leaving applications exposed to unpatched vulnerabilities presents the highest security risk in the supply chain.
Prisma Cloud researchers track and scan packages in each distribution and keep you protected even in very complex scenarios... For more information about Prisma Cloud open source vulnerability management and how it keeps your cloud safer, read more on vulnerability management with Prisma Cloud..