Anthony Tam

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** A Política de Camada de Aplicação, que utiliza o Dikastes para aplicar regras HTTP, não realiza a normalização do caminho da URL. Isso permite que requisições HTTP contendo barras repetidas, barras codificadas ou segmentos de traversal de caminho ignorem as regras de caminho de prefixo. Enquanto o Dikastes autoriza a requisição com base no prefixo permitido, um proxy frontal ou a carga de trabalho downstream normaliza o caminho, permitindo que um invasor com acesso à rede alcance endpoints HTTP restritos. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** O apiserver não invoca a sobreposição Delete para solicitações `DeleteCollection` em `NetworkPolicy`, `GlobalNetworkPolicy` e suas variantes encenadas. Isso ocorre porque esses recursos são envolvidos para serem executados através de `AuthorizeTierOperation()`, mas a sobreposição específica é ignorada durante a exclusão em massa. Consequentemente, um usuário com o verbo `deletecollection` ou permissões de curinga pode excluir políticas em massa em camadas para as quais não possui autorização, violando a fronteira de autorização de camadas. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** Quando o servidor de depuração compartilhado está habilitado, os componentes Calico kube-controllers e Goldmane vinculam seu ouvinte de depuração Go pprof ao endereço 0.0.0.0 sem autenticação. Isso permite que qualquer pod com alcance de rede ao ouvinte recupere o heap do processo, pilhas de goroutine (incluindo argumentos de função) e argumentos de linha de comando. O heap do processo pode conter material sensível, dependendo do estado da memória. O ouvinte de depuração é um recurso opcional que carece de autenticação e de uma opção de vinculação segura apenas para localhost. **Recomendações** Mantenha o servidor de depuração compartilhado desabilitado. Como medida de mitigação temporária, restrinja o acesso de rede ao ouvinte de depuração para evitar que pods não autorizados alcancem o serviço.

**Nome do Software Vulnerável e Versões Afetadas** calicoctl (versões afetadas não especificadas) **Descrição** Quando o cliente é invocado com `--log-level=info` ou `--log-level=debug`, ele imprime o conteúdo completo de sua estrutura de configuração de conexão carregada no stderr em uma única linha de log. Esta estrutura contém credenciais sensíveis usadas para se comunicar com o cluster, incluindo o kubeconfig inline (com token de portador), o token de portador da API do Kubernetes, a senha do etcd e o certificado e chave do cliente etcd codificados em PEM inline. Isso permite que qualquer leitor do fluxo stderr, como logs de jobs de CI ou arquivos de gravação de sessão, extraia essas credenciais sem a necessidade de privilégios do Kubernetes. Este problema ocorre apenas quando o log detalhado é explicitamente habilitado, pois o nível de log padrão é panic. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** O contêiner de inicialização `install-cni` registra a configuração CNI renderizada na saída padrão. Em implantações Canal ou Flannel-Calico onde o modelo de configuração usa o marcador ` SERVICEACCOUNT TOKEN `, o instalador substitui o token de portador do ServiceAccount do Kubernetes ativo antes do registro. Isso expõe o token a qualquer usuário autenticado com permissões de `pods/log` no namespace que contém o `calico-node`. O token exposto possui privilégios de patch em `pods/status`, o que pode ser usado para realizar ataques baseados em anotações contra cargas de trabalho do cluster. O caminho de autenticação padrão baseado em kubeconfig não é afetado. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Calico (versões afetadas não especificadas) **Descrição** Quando configurado com o plugin Azure IPAM, o binário Calico CNI modifica a configuração CNI recebida para incluir informações de sub-rede antes de delegá-la ao plugin IPAM. O auxiliar Azure IPAM então registra todo o mapa de configuração descompactado (`stdinData`) no nível INFO em `/var/log/calico/cni/cni.log` a cada invocação CNI ADD e DEL — ocorrendo sempre que um pod é agendado ou encerrado no nó. Quando o cluster é implantado usando autenticação do Kubernetes baseada em token, essa entrada de log contém o token de ServiceAccount, a chave do cliente e a autoridade de certificação em texto simples. Qualquer principal com acesso de leitura ao arquivo de log no nó pode extrair essas credenciais, que concedem privilégios de administrador de rede do Calico em todo o cluster. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do software vulnerável e versões afetadas** Versões 3.27.2 e anteriores do Calico Versões 3.19.0-1, 3.18.1, 3.17.3 e anteriores do Calico Enterprise Versões 19.2.0 e anteriores do Calico Cloud github.com/projectcalico/calico/v3 antes da v3.26.5, da v3.27.0 até a v3.27.3 **Descrição** O problema decorre de uma configuração incorreta do bit SUID (Set User ID) no binário de instalação do Calico CNI, combinada com a capacidade de controlar o binário de entrada, permitindo que um invasor execute um binário arbitrário com privilégios elevados. Um invasor com acesso local ao nó do Kubernetes pode escalar seus privilégios explorando essa vulnerabilidade. **Recomendações** Para as versões 3.27.2 e anteriores do Calico, considere desativar o binário de instalação do Calico CNI até que um patch esteja disponível. Para as versões 3.19.0-1, 3.18.1, 3.17.3 e anteriores do Calico Enterprise, restrinja o acesso ao binário de instalação do Calico CNI para minimizar o risco de exploração. Para as versões 19.2.0 e anteriores do Calico Cloud, evite usar o binário de instalação do Calico CNI até que o problema seja resolvido. Para github.com/projectcalico/calico/v3 antes da v3.26.5 e da v3.27.0 até a v3.27.3, atualize para uma versão que inclua a correção para este problema.

**Name of the Vulnerable Software and Affected Versions** Calico Typha versions 3.26.2 and below Calico Typha version 3.25.1 Calico Enterprise Typha versions 3.17.1 and below Calico Enterprise Typha version 3.16.3 Calico Enterprise Typha version 3.15.3 **Description** The issue arises when a client TLS handshake can block the Calico Typha server indefinitely, resulting in denial of service. This occurs because the TLS Handshake() call is performed inside the main server handle for loop without any timeout, allowing an unclean TLS handshake to block the main loop indefinitely while other connections will be idle waiting for that handshake to finish. **Recommendations** For Calico Typha versions 3.26.2 and below, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Typha version 3.25.1, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha versions 3.17.1 and below, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha version 3.16.3, consider implementing a timeout for the TLS handshake to prevent indefinite blocking. For Calico Enterprise Typha version 3.15.3, consider implementing a timeout for the TLS handshake to prevent indefinite blocking.