Corhere

Nome do software vulnerável e versões afetadas: Versões do Docker Engine anteriores à v27.1.1 Versões do Docker Engine 19.03 e posteriores, excluindo a v19.03.x Versões do Docker CE anteriores à v27.1.1 Descrição: Foi detectada uma vulnerabilidade de segurança em determinadas versões do Docker Engine, que poderia permitir que um invasor contornasse os plug-ins de autorização (AuthZ) em circunstâncias específicas. A probabilidade básica de que isso seja explorado é baixa. Usando uma solicitação de API especialmente criada, um cliente da API do Engine poderia fazer com que o daemon encaminhasse a solicitação ou resposta a um plug-in de autorização sem o corpo. Em determinadas circunstâncias, o plug-in de autorização pode permitir uma solicitação que, de outra forma, teria sido negada se o corpo tivesse sido encaminhado a ele. Um problema de segurança foi descoberto em 2018, no qual um invasor poderia contornar os plug-ins AuthZ usando uma solicitação de API especialmente criada. Isso poderia levar a ações não autorizadas, incluindo escalonamento de privilégios. Embora essa falha tenha sido corrigida no Docker Engine v18.09.1 em janeiro de 2019, a correção não foi incorporada às versões principais posteriores, resultando em uma regressão. Recomendações: Para versões do Docker Engine anteriores à v27.1.1, atualize para a versão v27.1.1 ou posterior para corrigir a vulnerabilidade. Para versões do Docker Engine 19.03 e posteriores, excluindo a v19.03.x, atualize para uma versão que inclua os patches incorporados, como os ramos de lançamento master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0 ou 26.1. Se não for possível atualizar imediatamente, evite usar plug-ins AuthZ e/ou rest

**Name of the Vulnerable Software and Affected Versions** Moby versions prior to 23.0.3 Moby versions prior to 20.10.24 Mirantis Container Runtime versions prior to 20.10.16 **Description** The issue is related to the encrypted overlay network feature in Moby's Swarm Mode. Encrypted overlay networks function by encapsulating VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. However, on affected platforms, these networks silently transmit unencrypted data, which may appear to be functional but lacks the expected confidentiality and data integrity guarantees. An attacker in a trusted position on the network can read all application traffic moving across the overlay network, resulting in unexpected secrets or user data disclosure. Many database protocols and internal APIs are not protected by a second layer of encryption, so users may rely on Swarm encrypted overlay networks for confidentiality, which is no longer guaranteed due to this vulnerability. **Recommendations** Update to Moby release 23.0.3 or later. Update to Moby release 20.10.24 or later. Update to Mirantis Container Runtime version 20.10.16 or later. As a temporary workaround, close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary to prevent unintentionally leaking unencrypted traffic over the Internet. Ensure that the `xt u32` kernel module is available on all nodes of the Swarm cluster.

**Name of the Vulnerable Software and Affected Versions** Moby versions prior to 23.0.3 Moby versions prior to 20.10.24 Mirantis Container Runtime versions prior to 20.10.16 **Description** The issue is related to the use of an unsecured alternative channel in the Swarm Mode of the Moby daemon component. This allows a remote attacker to impact the integrity of protected information by sending unencrypted packets. Encrypted overlay networks in Moby's Swarm Mode silently accept cleartext VXLAN datagrams, making it possible to inject arbitrary Ethernet frames into the encrypted overlay network. This can have severe implications. The `overlay` network driver, a core feature of Swarm Mode, provides isolated virtual LANs and supports an optional encrypted mode. However, the lack of proper encryption allows for the injection of malicious data. **Recommendations** For Moby versions prior to 23.0.3, update to version 23.0.3 or later. For Moby versions prior to 20.10.24, update to version 20.10.24 or later. For Mirantis Container Runtime versions prior to 20.10.16, update to version 20.10.16 or later. As a temporary workaround, in multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network on every node. For a single-node cluster, do not use overlay networks of any sort; instead, use bridge networks for connectivity. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.

**Nome do software vulnerável e versões afetadas** Versões do Moby anteriores à 23.0.3 Versões do Moby anteriores à 20.10.24 Versões do Mirantis Container Runtime anteriores à 20.10.16 **Descrição** O problema está relacionado ao uso de um canal alternativo não seguro no Modo Swarm do componente daemon do Moby. Isso pode possibilitar um ataque de Negação de Serviço e, potencialmente, permitir que um invasor sofisticado estabeleça uma conexão UDP ou TCP por meio do gateway de saída do contêiner, que, de outra forma, seria bloqueada por um firewall stateful. A vulnerabilidade se deve à injeção de quadros Ethernet arbitrários, que podem ser usados para contrabandear pacotes para a rede overlay. As redes overlay criptografadas funcionam encapsulando os datagramas VXLAN por meio do protocolo IPsec Encapsulating Security Payload no modo Transport. No entanto, as regras definidas pelo Moby para descartar datagramas VXLAN não criptografados podem ser substituídas por regras definidas pelo administrador, potencialmente admitindo datagramas não criptografados que deveriam ter sido descartados. **Recomendações** Atualize para a versão 23.0.3 do Moby ou posterior. Atualize para a versão 20.10.24 do Moby ou posterior. Atualize para a versão 20.10.16 ou posterior do Mirantis Container Runtime. Como solução alternativa temporária, considere fechar a porta VXLAN (por padrão, porta UDP 4789) para o tráfego de entrada na borda da Internet, a fim de impedir toda a injeção de pacotes VXLAN. Certifique-se de que o módulo do kernel `xt u32` esteja disponível em todos os nós do cluster Swarm.