- Published on
- Exercise 1
Vulnerability analysis with RHACS
- Authors
- Name
In this first exercise we'll identify vulnerabilities in an OpenShift application. Container applications can contain vulnerabilities in both the container base image (Red Hat Universal Base Image, Debian base images, Ubuntu, etc), or the application code packaged inside the container image. Red Hat Advanced Cluster Security for Kubernetes (RHACS) supports identifying vulnerabilities in both, and you can see the supported base images and programming languages for RHACS vulnerability analysis in the tables below.
Supported base images
| Distribution | Version |
|---|---|
| Alpine Linux | alpine:3.2,alpine:3.3, alpine:3.4, alpine:3.5, alpine:3.6, alpine:3.7, alpine:3.8, alpine:3.9, alpine:3.10, alpine:3.11, alpine:3.12, alpine:3.13, alpine:3.14, alpine:3.15, alpine:3.16, alpine:3.17, alpine:3.18, alpine:3.19, alpine:edge |
| Amazon Linux | amzn:2018.03, amzn:2, amzn:2023 |
| CentOS | centos:6, centos:7, centos:8 |
| Debian | ebian:10, debian:11, debian:12, debian:unstable, distroless |
| Oracle Linux | versions 5-9 |
| Photon OS | 1.0, 2.0, 3.0 |
| Red Hat Enterprise Linux (RHEL) | rhel:6, rhel:7, rhel:8, rhel:9 |
| SUSE | SLES 11, 12, 15; openSUSE Leap 42.3, 15.0, 15.1; SUSE Linux |
| Ubuntu | ubuntu:14.04, ubuntu:16.04, ubuntu:18.04, ubuntu:20.04, ubuntu:21.04, ubuntu:21.10, ubuntu:22.04, ubuntu:22.10, ubuntu:23.04, ubuntu:23.10. The following vulnerability sources are not updated by the vendor: ubuntu:12.04, ubuntu:12.10, ubuntu:13.04, ubuntu:14.10, ubuntu:15.04, ubuntu::15.10, ubuntu::16.10, ubuntu:17.04, ubuntu:17.10, ubuntu:18.10, ubuntu:19.04, ubuntu:19.10, ubuntu:20.1 |
Supported programming languages
| Language | Artifact |
|---|---|
| Go | Binaries: The standard library version used to build the binary is analyzed. If the binaries are built with module support (go.mod), then the dependencies are also analyzed. |
| Java | JAR / WAR / EAR |
| JavaScript | Node.js / npm package.json |
| Python | egg and wheel formats |
| Ruby | gem |
Identifying critical vulnerabilities
Let's explore vulnerabilities inside container images. Navigate to Red Hat Advanced Cluster Security for Kubernetes (RHACS) (the URL is in the etherpad) and login with your OpenShift username and credentials, making sure you select workshop_users when prompted.
Once you've logged in you'll be prompted to authorize access for RHACS. Simply select 'Allow selected permissions'
You'll be shown the Red Hat Advanced Cluster Security for Kubernetes (RHACS) dashboard once you've logged in.
Navigate to Vulnerability Management (1.0), and select 'images' in the top-right menu.
Why is there Vulnerability Management 1.0 and 2.0?
Red Hat Advanced Cluster Security for Kubernetes (RHACS) introduces several improvements to vulnerability reporting and management, which are contained in the '2.0' menu
Vulnerability Management 2.0 includes a new reporting capability, including the ability to customize email templates that are used when reports are sent.
Vulnerability Management 2.0 also includes the watched menu. Watched images are still scanned for vulnerabilities even when not in use by an active deployment.
We're not looking to generate reports or manage watched images in this exercise, so we will use the Vulnerability Management 1.0 component.
When RHACS is first-connected to an OpenShift cluster it will automatically perform a CVE scan of all images deployed to the cluster. You can see these shown in this screen - the 'Image Status -> Active' indicates that the image is associated with an active deployment.
Select the quay.io/the-worst-containers/pwnkit:v0.6 image. If you can't see it on the first page, you can search for the image in the 'Filter images' bar.
Once you select the image you'll be shown a screen showing a summary of the image.
There's a few things we can see here:
- The top CVSS of any vulnerabilities present in this container image is 10.0
- The container image was created 30/05/2024, and was last scanned very recently.
- The container image was scanned using the built-in Red Hat Advanced Cluster Security for Kubernetes (RHACS) CVE scanner, based on the open source Clair project.
- The image base OS is Debian 9. Debian 9 no longer produces new CVE data, and RHACS shows a message that the CVE data is now stale.
- The top riskiest components and the number of CVEs identified are also shown.
What does 'stale CVE data' mean?
Red Hat Advanced Cluster Security for Kubernetes (RHACS) uses CVE data from various sources. The latest Scanner v4 uses OSV.dev as a comprehensive source of CVE feeds and data.
The image used here is built on Debian 9. Debian publishes security advisories at https://www.debian.org/security/#DSAS, which are then made available via NIST NVD, OSV.dev and other sources. While there is historical CVE data available for Debian 9, there are no new security advisories being created. Hence RHACS shows a 'stale' CVE data message.
This also highlights the importance of selecting a base image with security errata available. If you don't have security errata and CVE information available for the base image, then it can be difficult to track CVEs through the application lifecycle.
If you scroll down the page you'll be shown the list of all CVEs present in this container image. Let's filter this list for a specific CVE - CVE-2021-4034.
Digging into PwnKit
CVE-2021-4034 refers to a privilege escalation vulnerability in the Polkit package.
Polkit’s pkexec program is a command-line program that allows local users on a Linux system to execute commands as another user identity (UID) based on policy definitions. In order to be able to change that UID, the pkexec program is installed with the Set User ID (SUID) bit set and the file owned by the superuser, or root. This program contained a memory safety error in the parsing of the command line. Because it runs with root privileges (required to change UID), it carried the risk that exploitable flaws in the program could allow running arbitrary code with elevated privileges and/ or bypassing the policy restrictions.
The execve system call in the Linux kernel accepts the path name of the file to be loaded into memory and executed as an additional argument passed to the program via the command line. Tradition and standard practice dictate that the first command-line argument (argv[0] in the C API) to be the name of the program being executed. However, this is not a requirement of the kernel and is thus not enforced. Pkexec’s command-line parsing code expected the command-line array (argv) to be well- formed; however, if pkexec was run with a NULL pointer value for argv, an out-of-bounds memory read occurred. While this memory read primitive alone would not usually be enough to take control of a program, the same memory location where the out-of-bound read occurs is later used to write data. As the stack memory following “argv” is almost always “env” (the program environment variables passed to execve), this allowed the parsing code to be abused in a way that allowed the rewriting of environment variables. The ability to rewrite environment variables allows unsafe values (such as LD_PRELOAD) that would normally not be permitted for a program running with SUID privileges. This would allow for arbitrary code execution with root privileges.
Statistics
- Affected major product versions: 4 (Red Hat Enterprise Linux 6, 7 and 8, Red Hat Virtualization 4)
- Severity rating: Important Estimated associate time: 520 hours (approximately 13 associates involved)
- Embargo time: 62 days
- Time from public to first fix release: 0 days
- Time from public to all fixes released: 20 days
- Exploit code published: Yes, 1 day after disclosure
- Exploitation in the wild: Yes, added to the CISA Known Exploited Vulnerabilities (KEV) catalog after 6 months
- Estimated fix deployment: Very High
Qualys discovered this issue through excellent research and branded it “PwnKit.” Qualys gave Red Hat a significant lead time on the issue, thus putting us in an excellent position to prepare our public response prior to public disclosure. While the exploitation primitives described and used in the research are somewhat novel, once they are understood, reliable exploitation is reasonably trivial. While the threat posed by the flaw is somewhat mitigated by requiring local access, polkit is a heavily deployed and used package. Exploitation in the wild would likely occur, as would at least a fair amount of media attention. In the end, media attention was limited. However, publicly available exploit code was quickly circulating with the flaw, eventually making the CISA KEV catalog. The 6-month delay from the flaw going public to inclusion on the CISA list is likely more of a reflection on process speed, alongside detection and monitoring capabilities than any real reflection on the interest in the flaw to malicious actors.
Click CVE-2021-4034 and you'll be shown a summary of the CVE.
The summary contains some other important data about this CVE:
- The CVSS score is 7.8
- The CVE has a patch available (
Fixable) - The CVE was first published 29/01/2022, and was first discovered in this environment very recently
You can also see a link the image component on the right-hand side of the screen.
Clicking this link will show the vulnerable component inside the container image. In this case, it's the policykit-1 package installed into the container image. This screen also shows the package that fixes the CVE.
You can also dig further into this component and see any other CVEs that it is exposed to.
Summary
This was a quick introduction to Red Hat Advanced Cluster Security for Kubernetes (RHACS). We looked at how to use RHACS to identify vulnerable container images, and dug into vulnerable components inside a container image.
In the next exercise, we'll look at creating a campaign for a specific CVE and extracting data from RHACS.
Stretch goals
Can you find a Log4Shell-vulnerable image running on the cluster? Which namespace is this running in?
Solution
Log4Shell is associated with a number of CVE identifiers, notably CVE-2021-44228. If you search this CVE identifier in the Vulnerability Management (1.0) page you will see a single image. Note that this is listed as 'Active', indicating that is currently deployed on the cluster.
Select the image and then the 1 Deployment button on the right, to show the matching deployments.
This view indicates that there is a Log4Shell-vulnerable workload running in the app-deploy namespace.
