Anthony Tam

**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** 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** 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.