Security issues are more crucial today than ever before. Every day, new vulnerabilities in our computer systems are discovered, and our computer systems get more complicated. With the flood of vulnerabilities threatening to overwhelm our security teams, the question “How much does it matter?” arises rapidly.
“Does it matter?” is divided into two parts:
To set the scenario, Red Hat Product Security uses the vocabulary listed below to assist alleviate some of the uncertainty associated with describing software vulnerabilities.
“Affected” is merely a yes or no decision that indicates whether or not the susceptible code is there. It makes no difference if the vulnerable code cannot or will not be run. If it exists, we consider the component to be impacted.
“Severity” – this is a four-point scale used to assess the criticality of a problem (Critical, Important, Moderate, Low). More information may be found on the Red Hat security rating website, however, keep in mind that, while the severity ratings are frequently used to monitor the relevant CVSS score, they are not always related.
As an example, consider CVE-2021-3918, a JSON-schema library vulnerability. The same vulnerability was granted a varied severity rating depending on the product it was in. Red Hat classified it as “Important” as a library on its own. However, we can see on the first page of the impacted packages table on the CVE website that it has been assigned the “Moderate” severity as embedded in Red Hat OpenShift Service Mesh.
This blog focuses on containerized settings in particular. Many of the expectations and assumptions for typical operating system environments are simply false, and these disparities come into play when examining any specific vulnerability. Containerized environments, like the one above, are distinct, and we’ll look at why and how this is true in this section. We demonstrate how different the impact may be in a containerized system, and proper risk assessment may assist answer the question, “How critical is this vulnerability?”
Before we begin investigating vulnerabilities, we must first describe what a container is and why container images are used.
A container image is a unit that contains a ready-to-run set of software that wraps up code and all its dependencies (application). A well-crafted image will be lightweight, including only the components required to execute a single program, such as code, runtime, tools, libraries, and settings. Although containers containing numerous apps can be built, this is uncommon.
Container workloads that are well-designed appear significantly different from typical operating system settings in which several users share various programs on the same host. Please read: the OpenShift overview to have a better understanding of containerized environments such as Red Hat OpenShift and how containers are utilized there.
Consider that in a typical OpenShift system, every Linux package lives in at least four places: on the underlying host system, inside container images in the control plane, within container images in the platform’s worker nodes, and container images in user-provided workloads. It is critical to be able to distinguish which portion we are discussing, as well as to understand that any user-provided workloads are not taken into account when Red Hat analyzes the OpenShift platform itself.
Knowing this, we can begin investigating some of the many sorts of vulnerabilities in containers.
In the three examples below, we look at some fairly common forms of vulnerabilities and investigate how their impact on a containerized environment might be assessed.
The Common Vulnerability Scoring System (CVSS) framework, in part, allows us to capture these details numerically in the “Environmental Score,” though this is typically used by the end-user of the software to capture the nature of the installation environment, rather than by the software vendor to capture alternative environments in which the software may be provided.
Although privilege escalation vulnerabilities are rather frequent, let us try to understand how these sorts of vulnerabilities affect operating containers. We will utilize one of the most recent high-severity vulnerabilities to show the effect assessment: CVE-2021-4034.
RHSB-2022-001 Polkit Privilege Escalation is a thorough Red Hat security bulletin that describes this issue.
The flaw was discovered in pkexec , a component of the polkit package that allows unprivileged processes to connect with privileged processes on a Linux system. Due to faulty processing of the process’s argument vector, an unprivileged local attacker can escalate privileges while bypassing any authentication and rules.
Based on the facts presented here, we may conclude that the terms “local attacker” and “increase privileges” may have distinct meanings within a container. Furthermore, we examine the specific containers in question to see if a different severity analysis should be considered and if it is warranted.
The problem is that when we examine a vulnerability as a whole, we don’t know the specifics of each setting where it may exist, thus we must rely on a variety of generalizations. We may really know a lot about a containerized system, especially if we are investigating a vulnerability in an OpenShift component.
A low-privileged user of a shared system can no longer be deemed a “local attacker” in the vulnerability wording. They are at least a highly privileged user for any containers in question, and in the event of a control plane component, they may be assumed to have cluster-admin access.
Then we may look at the “escalate privileges” section. Such privilege escalation would allow the attacker to compromise the host under a typical operating system. It allows the attacker to compromise the container in a container environment. It’s a little more complicated, but in the context of the container orchestration environment, CVSS’ C: H (confidentiality: high) may be altered to C:L (confidentiality: low), and similar adjustments are made for integrity and availability.
In summary, with a typical operating system installation, this vulnerability allows a low-privileged user to acquire complete system access. This is classified as “Important” by Red Hat. When we look at the containers listed as being given by the platform itself in an OpenShift environment, the vulnerability is confined to allowing highly privileged individuals to obtain access to complete containers (that is, things they already have access to). This is classified as “Low” by Red Hat.
Taking this technique a step further, we can see that a similar exploration process may be used to evaluate a user-provided workload container that contains the vulnerability. We may think about who the local users are and whether there are any unusual conditions, such as containers operating privileged and unconstrained and having access to the underlying host.
It should be emphasized that the potential of a highly privileged container exists (for example something that runs as part of the control plane and leverages the “privileged” SCC to attain high levels of system access). In the event of an active vulnerability in a container like this, we can see that exploitation of the container may be virtually equivalent to the exploitation of the underlying host, and such a reconsideration of the severity would be inappropriate.
As you can see, the same vulnerability that would necessitate an immediate reaction for a standard operating system installation might be significantly less critical in a containerized environment. There is no question about whether the vulnerability should be corrected (it should), but after more investigation, we can conclude that it can be done in a methodical manner rather than as a fire drill.
Another sort of frequent vulnerability is one that causes a system crash. But how can we quantify the danger posed by these types of vulnerabilities to containers? Of course, different vulnerabilities may have different attack routes and impact different settings and systems, so let’s look at one in a container context.
As an example, consider CVE-2021-33910, a recent well-known vulnerability.
This weakness is associated with the systemd package and the vulnerable alloca function, which allows a local attacker who can mount a filesystem on a very long path to crash the systemd service (PID 1) and, as a result, the whole system.
Many Red Hat containers, including the primary Red Hat Universal Base Image, have the systemd package installed (UBI). This indicates that this package is available in a variety of Red Hat containerized solutions, including OpenShift. This appears to be somewhat frightening, however, the key in this scenario is how the vulnerable package is utilized in the system, which in this case is in the container.
PID 1 in containers is not systemd (or initd in prior times) managing processes for the entire host but is the command or entry point that executes the containerized program. The systemd binary may be included in the container image but will not be operating; any success an attacker has in starting it and then causing it to crash will not affect the container. In summary, the vulnerability exists, but there is no feasible way to attack it.
However, this does not imply that our container is “unaffected.” As stated in the introduction, the term “affected” refers to the presence of vulnerable code in the code — in this example, the content of the container image. However, given the vulnerability exists but cannot be exploited, we rate it as minor. In case you’re wondering, Red Hat severity ratings don’t go lower than “Low,” however CVSS rankings feature “None” as an option for faults with a CVSS of zero. This will be reflected in the CVSS base score as “C:N/I:N/A:N” — having a “None” value for each confidentiality, integrity, and availability.
Our investigation of the systemd vulnerability in the context of OpenShift-provided container images comes to a close here. Remember that any user-provided workloads are beyond the scope of the study, and if you’ve constructed “multiservice containers” that use systemd, you should do a thorough assessment of the vulnerability in these containers.
Container escape vulnerabilities are extremely dangerous, and Red Hat Product Security devotes significant resources to prevent them. Their impact is heavily dependent on the host (container environment) settings, therefore let’s look at a recent Linux kernel vulnerability with the classification of “Important”: CVE-2022-0185.
The major effect of this issue on the system is privilege escalation. However, there are publications on the Internet (for example, CVE-2022-0185 in Linux Kernel Can Allow Container Escape in Kubernetes) claiming that this weakness can also be utilized to achieve a container escape in Kubernetes.
Based on the provided proof of concept, it appears that the host’s root filesystem is manipulated by exploiting local privilege escalation (exploit requires sufficient privileges: CAP SYS ADMIN). However, as previously stated, the effectiveness of the attack is dependent on the host configuration, such as container runtime, system settings, and any security methods deployed on the host.
Red Hat Product Security investigates every reported container escape vulnerability in a variety of settings to evaluate the impact on all Red Hat products. For example, with OpenShift, the cluster processes on the node are namespaced, which implies that modifying the namespace in the current OpenShift container would not bring the required complete capabilities, even though they appear to be there. This indicates that the first step in escaping the container, utilizing local privilege escalation, is already prohibited because the essential conditions to exploit this vulnerability are not met. A successful container escape attempt is also prevented at the cluster node level by SELinux. This suggests that the effect of this vulnerability on OpenShift is “Low.”
This example demonstrates the significance of designing a secure workplace. Vulnerabilities may be addressed on several levels with a strong security controls design. Potential attacks in containerized settings can be blocked at the cluster level by implementing strong security practices (such as accurate RBAC and restricted SCC by default) or at the container’s host level (SELinux, namespaces, seccomp). Following the suggested security procedures can considerably limit the vulnerability’s potential effect.
As we’ve seen in the examples above, the impact of a vulnerability in containerized systems might differ from that of traditional operating system environments. To assess the severity of a given vulnerability in your containerized system, you must first understand how and why the vulnerable item was included in the container image. You can rebuild the final container and delete the impacted package during the build process for bespoke deployments when, for example, the UBI image is used as the base image. This step should be taken if you are unable to wait for the official patch or patched base image and are certain that the impacted package is not required for your service.
In this post, we utilized a handful of well-known vulnerabilities to demonstrate how the possible attack effect varies depending on the environment. A fault that would be labeled “Critical” in a typical physical or virtual operating system installation may have a “Low” impact in containers. It is critical to realize that external conditions can considerably lessen the impact in many circumstances and that Red Hat-provided container images may differ from your own.
Any security or operations team must have methods and procedures in place to respond to vulnerabilities of varying severity. These, together with a correct evaluation of each particular vulnerability, allow us to address high-severity vulnerabilities with the urgency they merit for immediate care while treating low-severity vulnerabilities helps us to know.
Red Hat makes every effort to share accurate and timely information about our evaluation of all vulnerabilities found in our products. We hope this article helps to explain why our severity ratings for containerized environments frequently differ, and that it also provides you with some tools and techniques you can use to examine your own containerized workloads to better assess the impact of any vulnerabilities found in the packages or components that they contain.
Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.
For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com