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.

Uma falha no ovn-kubernetes permite que um administrador de sistema ou um invasor com privilégios crie uma política de rede de saída que contorna as políticas de entrada existentes de outros pods em um cluster. Isso resulta na divulgação de informações e em outros ataques a pods que não deveriam ser acessíveis. O problema está relacionado à validação insuficiente de entradas.

O problema afeta o Red Hat OpenShift devido à falta de um patch para uma correção específica no pacote haproxy.

Verificou-se que a configuração do Ignition, fornecida pelo Machine Config Server, pode ser acessada externamente a partir de clusters sem autenticação. O endpoint do MCS (porta 22623) fornece a configuração do Ignition usada para inicializar nós e pode incluir alguns dados confidenciais, como segredos de pull do registro. Existem dois cenários em que esses dados podem ser acessados. O primeiro é em implantações Baremetal, OpenStack, Ovirt, Vsphere e KubeVirt que não possuem um endpoint de API interno separado e permitem o acesso de fora do cluster à porta 22623 a partir do endereço IP virtual padrão da API do OpenShift. O segundo ocorre em implantações em nuvem ao usar plug-ins de rede não suportados, que não criam regras de iptables para impedir o acesso à porta 22623. Nesse cenário, a configuração do Ignition fica exposta a todos os pods dentro do cluster e não pode ser acessada externamente.

Foi encontrada uma falha de escalonamento de privilégios no OpenShift Builder, na qual credenciais fora do contexto de compilação são automaticamente montadas na imagem do contêiner em construção durante o tempo de compilação. Isso permite que um usuário do OpenShift capaz de executar código durante o tempo de compilação dentro do contêiner reutilize as credenciais e sobrescreva imagens de contêineres arbitrárias em registros internos e/ou escalone seus privilégios. A maior ameaça decorrente dessa vulnerabilidade é à confidencialidade e integridade dos dados, bem como à disponibilidade do sistema.

**Nome do software vulnerável e versões afetadas: Versões do OpenShift Installer anteriores à v0.9.0-master.0.20210125200451-95101da940b0 Descrição: Foi encontrada uma falha no OpenShift Installer. Durante a instalação de clusters do OpenShift Container Platform 4, os nós bootstrap são provisionados com a autenticação anônima habilitada na porta 10250 do kubelet. Um invasor remoto capaz de acessar essa porta durante a instalação pode fazer solicitações `/exec` não autenticadas para executar comandos arbitrários dentro de contêineres em execução. A maior ameaça dessa vulnerabilidade é à confidencialidade e integridade dos dados, bem como à disponibilidade do sistema. Recomendações: Para versões do OpenShift Installer anteriores à v0.9.0-master.0.20210125200451-95101da940b0, atualize para a versão v0.9.0-master.0.20210125200451-95101da940b0 ou posterior para resolver o problema. Como solução alternativa temporária, considere desativar a autenticação anônima na porta 10250 do kubelet durante a instalação para minimizar o risco de exploração. Restrinja o acesso ao endpoint `/exec` para impedir solicitações não autenticadas.

O problema ocorre durante a instalação de um cluster do OpenShift 4, quando a ferramenta de linha de comando `openshift-install` cria um diretório `auth`. Esse diretório contém os arquivos `kubeconfig` e `kubeadmin-password`, que armazenam as credenciais para autenticação no servidor da API do OpenShift. No entanto, esses arquivos recebem permissões incorretas de leitura, o que pode expor as credenciais.

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.