Sam Fowler

**Name of the Vulnerable Software and Affected Versions** OpenShift versions 4.11 through 4.12 **Description** A flaw was found in the apiserver-library-go package that can allow low-privileged users to set the seccomp profile for pods they control to "unconfined." The seccomp profile used in the restricted-v2 Security Context Constraint (SCC) is "runtime/default" by default, which allows users to disable seccomp for pods they can create and modify. **Recommendations** For OpenShift versions 4.11 and 4.12, consider restricting the ability of low-privileged users to set the seccomp profile for pods they control to prevent potential exploitation. As a temporary workaround, consider disabling the use of the "unconfined" seccomp profile for pods until a patch is available. Restrict access to the restricted-v2 Security Context Constraint (SCC) to minimize the risk of exploitation.

It was found that the original fix for log4j CVE-2021-44228 and CVE-2021-45046 in the OpenShift metering hive containers was incomplete, as not all JndiLookup.class files were removed. This CVE only applies to the OpenShift Metering hive container images, shipped in OpenShift 4.8, 4.7 and 4.6.

**Name of the Vulnerable Software and Affected Versions** ovn-kubernetes (affected versions not specified) **Description** A flaw in ovn-kubernetes allows a system administrator or privileged attacker to create an egress network policy that bypasses existing ingress policies of other pods in a cluster. This results in information disclosure and other attacks on pods that should not be reachable. The issue is related to insufficient input validation. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Red Hat OpenShift version 4.9 **Description** The issue affects Red Hat OpenShift due to a missing patch for a specific fix in the haproxy package. **Recommendations** For Red Hat OpenShift version 4.9, ensure the haproxy package is updated to include the missing patch.

**Name of the Vulnerable Software and Affected Versions** OpenShift Container Platform 4 (affected versions not specified) **Description** It was found that ignition config, served by the Machine Config Server, can be accessed externally from clusters without authentication. The MCS endpoint (port 22623) provides ignition configuration used for bootstrapping Nodes and can include some sensitive data, e.g. registry pull secrets. There are two scenarios where this data can be accessed. The first is on Baremetal, OpenStack, Ovirt, Vsphere and KubeVirt deployments which do not have a separate internal API endpoint and allow access from outside the cluster to port 22623 from the standard OpenShift API Virtual IP address. The second is on cloud deployments when using unsupported network plugins, which do not create iptables rules that prevent access to port 22623. In this scenario, the ignition config is exposed to all pods within the cluster and cannot be accessed externally. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** github.com/openshift/builder versions v0.0.0-20210125201112-7901cb396121 and before **Description** A privilege escalation flaw was found in OpenShift builder, where credentials outside the build context are automatically mounted into the container image under construction during build time. This allows an OpenShift user who can execute code during build time inside the container to re-use the credentials and overwrite arbitrary container images in internal registries and/or escalate their privileges. The highest threat from this issue is to data confidentiality and integrity as well as system availability. **Recommendations** For versions v0.0.0-20210125201112-7901cb396121 and before, consider restricting access to the build process to minimize the risk of exploitation until a patch is available. As a temporary workaround, limit the privileges of users who can execute code during build time to prevent potential escalation.

Name of the Vulnerable Software and Affected Versions: OpenShift Installer versions prior to v0.9.0-master.0.20210125200451-95101da940b0 Description: A flaw was found in the OpenShift Installer. During installation of OpenShift Container Platform 4 clusters, bootstrap nodes are provisioned with anonymous authentication enabled on kubelet port 10250. A remote attacker able to reach this port during installation can make unauthenticated `/exec` requests to execute arbitrary commands within running containers. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. Recommendations: For OpenShift Installer versions prior to v0.9.0-master.0.20210125200451-95101da940b0, update to version v0.9.0-master.0.20210125200451-95101da940b0 or later to resolve the issue. As a temporary workaround, consider disabling anonymous authentication on kubelet port 10250 during installation to minimize the risk of exploitation. Restrict access to the `/exec` endpoint to prevent unauthenticated requests.

**Name of the Vulnerable Software and Affected Versions** OpenShift versions 4.2 **Description** The issue arises during the installation of an OpenShift 4 cluster, where the `openshift-install` command line tool creates an `auth` directory. This directory contains `kubeconfig` and `kubeadmin-password` files, which hold credentials for authenticating to the OpenShift API server. However, these files are incorrectly assigned word-readable permissions, potentially exposing the credentials. **Recommendations** For OpenShift version 4.2, ensure the `kubeconfig` and `kubeadmin-password` files have appropriate permissions to prevent unauthorized access. Consider restricting access to these files until a proper fix is applied. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: OpenShift Container Platform versions 4.1 and 4.2 Description: The issue allows a low-privileged user to read pod logs and discover secret material if the log level in an operator has been set to Debug or higher by a privileged user. This occurs because secret data written to pod logs is not sanitized. Recommendations: For OpenShift Container Platform versions 4.1 and 4.2, consider restricting access to pod logs to prevent unauthorized users from reading sensitive information. As a temporary workaround, avoid setting the log level to Debug or higher in operators unless necessary, and ensure that only trusted users have the privilege to modify log levels.

**Name of the Vulnerable Software and Affected Versions** JBoss Management Console versions prior to 7.1.6.CR1 JBoss Management Console versions prior to 7.1.6.GA **Description** A cross-site scripting (XSS) issue was discovered. This allows users with object creation capabilities to attack other privileged users. **Recommendations** For versions prior to 7.1.6.CR1, update to version 7.1.6.CR1 or later. For versions prior to 7.1.6.GA, update to version 7.1.6.GA or later.

**Name of the Vulnerable Software and Affected Versions** openstack-octavia versions prior to 2.0.2-5 openstack-octavia versions prior to 3.0.1-0.20181009115732 **Description** The issue allows for information exposure due to log files being readable by all users. Sensitive information, such as private keys, can appear in these log files. **Recommendations** For versions prior to 2.0.2-5, update to version 2.0.2-5 or later to resolve the issue. For versions prior to 3.0.1-0.20181009115732, update to version 3.0.1-0.20181009115732 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** Ceph versions up to v13.2.4 **Description** The issue is related to the improper sanitization of encryption keys in debug logging for v4 auth, resulting in the leaking of encryption key information in log files via plaintext. **Recommendations** For versions up to v13.2.4, update to a version later than v13.2.4 to resolve the issue. As a temporary workaround, consider disabling debug logging for v4 auth to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** GnuTLS versions prior to 3.6.5 **Description** The issue is related to an error in verifying decrypted RSA data, allowing an attacker to potentially access protected information through a side-channel cache attack. Specifically, a Bleichenbacher type side-channel based padding oracle attack was found in the way GnuTLS handles verification of RSA decrypted PKCS#1 v1.5 data. An attacker who can run a process on the same physical core as the victim process could exploit this to extract plaintext or, in some cases, downgrade any TLS connections to a vulnerable server. **Recommendations** For GnuTLS versions prior to 3.6.5, update to version 3.6.5 or later to resolve the issue. As a temporary workaround, consider restricting access to sensitive data and minimizing the use of TLS connections to vulnerable servers until the update can be applied.

**Name of the Vulnerable Software and Affected Versions** Nettle (affected versions not specified) **Description** The issue is related to a Bleichenbacher type side-channel based padding oracle attack in the way Nettle handles endian conversion of RSA decrypted PKCS#1 v1.5 data. This could allow an attacker who is able to run a process on the same physical core as the victim process to extract plaintext or in some cases downgrade any TLS connections to a vulnerable server. The attack exploits an error in the reverse conversion of decrypted RSA data. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** etcd versions 3.2.x through 3.2.25 etcd versions 3.3.x through 3.3.10 **Description** The issue concerns an improper authentication problem when role-based access control (RBAC) is used and client-cert-auth is enabled. If an etcd client server TLS certificate contains a Common Name (CN) that matches a valid RBAC username, a remote attacker may authenticate as that user with any valid client certificate in a REST API request to the gRPC-gateway. This could potentially allow unauthorized access to protected information. **Recommendations** For etcd versions 3.2.x through 3.2.25, update to version 3.2.26 or later to resolve the issue. For etcd versions 3.3.x through 3.3.10, update to version 3.3.11 or later to resolve the issue. As a temporary workaround, consider disabling the client-cert-auth feature until a patch is available. Restrict access to the gRPC-gateway to minimize the risk of exploitation. Avoid using client certificates that contain a Common Name (CN) which matches a valid RBAC username in the affected REST API requests until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** nginx versions prior to 1.15.6 nginx versions prior to 1.14.1 **Description** The issue is related to the implementation of the HTTP/2 protocol in the nginx server, which can lead to uncontrolled resource consumption. This can allow a remote attacker to cause a denial of service. The problem affects nginx servers compiled with the ngx http v2 module, when the 'http2' option of the 'listen' directive is used in a configuration file. **Recommendations** For versions prior to 1.15.6, update to version 1.15.6 or later. For versions prior to 1.14.1, update to version 1.14.1 or later. As a temporary workaround, consider disabling the `ngx http v2 module` module or removing the 'http2' option from the 'listen' directive in the configuration file until a patch is available.

**Name of the Vulnerable Software and Affected Versions** nginx versions 1.15.6 and earlier, 1.14.1 and earlier **Description** The issue is related to the ngx http mp4 module in nginx, which might allow an attacker to cause an infinite loop in a worker process, cause a worker process crash, or result in worker process memory disclosure by using a specially crafted mp4 file. The attack is only possible if an attacker is able to trigger processing of a specially crafted mp4 file with the ngx http mp4 module and if the module is built and the .mp4 directive is used in the configuration file. **Recommendations** For versions prior to 1.15.6 and 1.14.1, update to version 1.21.0 or later to resolve the issue. As a temporary workaround, consider disabling the ngx http mp4 module until a patch is available. Restrict access to the .mp4 directive in the configuration file to minimize the risk of exploitation. Avoid using the ngx http mp4 module to process mp4 files until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** RichFaces Framework versions 3.X through 3.3.4 **Description** The RichFaces Framework is susceptible to Expression Language (EL) injection through the UserResource resource. A remote, unauthenticated attacker can potentially execute arbitrary code by exploiting a chain of Java serialized objects via `org.ajax4jsf.resource.UserResource$UriData`. This issue is currently being exploited in attacks, as indicated by CISA advisories. **Recommendations** Versions prior to 3.4 are affected.

**Name of the Vulnerable Software and Affected Versions** glusterfs versions 3.1.2 through 4.1.4 **Description** A flaw in the glusterfs server allows repeated usage of the `GF META LOCK KEY` xattr, enabling a remote, authenticated attacker to create multiple locks for a single inode by using `setxattr` repetitively. This results in memory exhaustion of the glusterfs server node. The issue is related to an uncontrolled consumption of resources, which can be exploited by a remote attacker to cause a denial of service. **Recommendations** For versions 3.1.2 through 4.1.4, consider restricting the use of the `setxattr` function to prevent repetitive usage of the `GF META LOCK KEY` xattr until a patch is available. As a temporary workaround, limiting the number of locks that can be created for a single inode may help minimize the risk of memory exhaustion.

**Name of the Vulnerable Software and Affected Versions** Gluster file system versions 3.1.2 through 4.1.4 **Description** The issue allows a remote, authenticated attacker to perform a denial of service attack by utilizing the `GF XATTR IOSTATS DUMP KEY` xattr. This can be exploited by mounting a Gluster volume and repeatedly calling `setxattr(2)` to trigger a state dump, resulting in the creation of an arbitrary number of files in the server's runtime directory. **Recommendations** For versions 3.1.2 through 4.1.4, consider restricting access to the `GF XATTR IOSTATS DUMP KEY` xattr to prevent exploitation. As a temporary workaround, consider disabling the `setxattr(2)` function until a patch is available. Restrict access to the Gluster volume to minimize the risk of exploitation.