O Teku 26.10.3 e o Besu 26.10.2 removem quatro raízes de certificados das respetivas imagens Docker após o incidente com a autoridade de certificação eMudhra. A versão do Teku foi publicada a 27 de outubro e a do Besu, a 26. Os operadores com instalações binárias têm de verificar separadamente o respetivo ambiente Java.
Porque é importante
O incidente envolveu chaves privadas recuperáveis de oito autoridades de certificação intermédias emSign G3. A eMudhra afirmou que um erro num script gerou chaves fracas e que os certificados intermédios foram revogados após uma denúncia a 17 de outubro. O aviso do Teku alerta que o Java não verifica a revogação de certificados por predefinição, pelo que a revogação, por si só, pode não proteger os ambientes afetados.
O Teku afirma que os nós da mainnet Ethereum com a configuração predefinida e sem URLs HTTPS não são afetados, e não há registo de exploração da falha. O risco depende da configuração: um atacante teria de intercetar uma ligação HTTPS afetada para se fazer passar pelo respetivo destino. Entre as dependências HTTPS possíveis, o Teku lista assinantes remotos, nós beacon, clientes de execução, construtores, relays e serviços de validadores. A rede ponto a ponto não é afetada, uma vez que o libp2p e o discv5 não utilizam autoridades de certificação.
Impacto no mercado
As correções removem das imagens Docker o emSign ECC Root CA G3, o emSign Root CA G1, o emSign Root CA G2 e o AAA Certificate Services. O Teku identifica as suas imagens Docker até à versão 26.10.2, incluindo as variantes -jdk25 e -jdk26, como contendo uma raiz implicada. Atualizar o Java no sistema anfitrião não atualiza o ambiente incluído nesses contentores.
A alteração do Besu aplica-se às imagens Docker. Os utilizadores das versões tar e zip podem continuar a ter um JDK que confia nas raízes. Do mesmo modo, os utilizadores da versão binária do Teku dependem do ambiente Java instalado pelo operador. Se uma ligação afetada for intercetada, um atacante poderá fazer-se passar por um nó beacon remoto, redirecionar taxas de propostas ou levar a que tarefas de validação não sejam cumpridas. O Teku alerta também que fazer-se passar por um assinante externo exposto poderá permitir obter assinaturas de saída de validadores. A autenticação de clientes por TLS mútuo limita o impacto referido a uma negação de serviço.
Perguntas frequentes
-
Que versões de clientes Ethereum removem as raízes afetadas das imagens Docker?
O Teku 26.10.3 e o Besu 26.10.2 removem quatro raízes de certificados das respetivas imagens Docker.
-
Porque é que as instalações binárias exigem uma verificação separada do Java?
As instalações binárias usam um ambiente Java gerido pelo operador, que pode continuar a confiar nas raízes afetadas. Atualizar o Java no sistema anfitrião não altera o ambiente incluído num contentor.
-
Segundo o Teku, os nós da mainnet Ethereum com a configuração predefinida são afetados?
O Teku afirma que os nós da mainnet com a configuração predefinida e sem URLs HTTPS não são afetados por este problema de certificados. Também não há registo de exploração da falha.
-
O que poderá acontecer se uma ligação HTTPS afetada for intercetada?
Um atacante poderá fazer-se passar por um nó beacon remoto, redirecionar taxas de propostas ou levar a que tarefas de validação não sejam cumpridas.
-
O problema dos certificados afeta a rede ponto a ponto do Teku?
Não. O Teku afirma que a sua rede ponto a ponto libp2p e discv5 não utiliza autoridades de certificação e não é afetada.