Sam Fowler

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.

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.

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.

The issue affects Red Hat OpenShift due to a missing patch for a specific fix in the haproxy package.

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.

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.

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.

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.

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.

A cross-site scripting (XSS) issue was discovered. This allows users with object creation capabilities to attack other privileged users.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.