Como encontrar e corrigir a vulnerabilidade zero-day crítica do WebP CVE-2023-4863

No mês passado, duas vulnerabilidades críticas (CVE-2023-4863 e CVE-2023-5129) foram identificadas pela Apple Security Engineering and Architecture (SEA), em colaboração com o The Citizen Lab da Munk School, da Universidade de Toronto. As vulnerabilidades envolviam imagens WebP criadas maliciosamente, capazes de explorar navegadores baseados em Chromium e a biblioteca webmproject/libwebp, fornecida pelo Google. Você pode saber mais sobre a vulnerabilidade e seu histórico recente em nosso post anterior no blog.

Em particular, a vulnerabilidade do libwebp vai além dos navegadores e afeta ecossistemas de desenvolvimento, sistemas operacionais e contêineres. Confira todos os ecossistemas e contêineres que identificamos como afetados pelo libwebp:

A abrangência do impacto dessa vulnerabilidade fica evidente ao observar sua detecção em vários ecossistemas de desenvolvimento, tanto como dependência direta quanto transitiva. Ela aparece principalmente como dependência transitiva em projetos Cocoapods, Swift e Python, o que pode dificultar que os desenvolvedores percebam o impacto. No entanto, tanto o Snyk Container quanto o Snyk Open Source conseguem detectar os pacotes relevantes. Você pode usar o Snyk gratuitamente agora para descobrir quais dos seus projetos os incluem.

Embora tenhamos feito uma análise abrangente do impacto do libwebp, especialistas em segurança ainda estão pesquisando os diferentes usos do libwebp em aplicações, ecossistemas e sistemas operacionais. Como a vulnerabilidade afeta componentes de software que usam codecs de imagem .webp e renderizam seu conteúdo (como navegadores, ferramentas de design etc.), o escopo continuará aumentando. Por isso, é essencial acompanhar as últimas notícias sobre o libwebp.

Este post tem como objetivo explicar melhor o impacto dessa vulnerabilidade nos ecossistemas de software e servir como uma referência rápida para corrigi-la.

Em 3 de outubro de 2023, os CVEs conhecidos por acompanhar ativamente essa vulnerabilidade do libwebp eram:

• CVE-2023-4863: registrado em 11 de setembro de 2023, com pontuação CVSS de 9.6 e pontuação EPSS de 31,86% (percentil 97). Observação: inicialmente, este CVE recebeu a pontuação 8.8 (“Alta”), antes da divulgação de mais detalhes.

• CVE-2023-5129: registrado em 25 de setembro de 2023, com pontuação CVSS de 10 (a máxima possível); mais tarde, em 27 de setembro de 2023, foi rejeitado pelo Google, a autoridade responsável pela atribuição do número CVE, por ser uma duplicata;

Você pode saber mais sobre a vulnerabilidade e seu histórico recente em nosso post anterior no blog. Neste post, vamos explorar estas recomendações de correção:

1. Identifique onde você usa o libwebp

2. Atualize para o libwebp 1.3.2 ou superior

3. Monitore projetos com suporte a PRs automáticas

1. Identifique onde você usa o libwebp

A parte mais desafiadora de lidar com uma vulnerabilidade zero-day é descobrir se você foi afetado e em quais pontos. No caso do libwebp, não é diferente. O libwebp pode ser uma dependência do seu projeto, direta ou indireta, como dependência transitiva. Por isso, identificá-lo é fundamental para corrigir o problema adequadamente: é muito provável que você tenha sido afetado em algum nível sem saber. Alguns possíveis pontos de impacto incluem:

• Qualquer software que você esteja desenvolvendo e que dependa diretamente da biblioteca libwebp ou indiretamente por meio de dependências transitivas é afetado pela vulnerabilidade.

• Qualquer software que você use para codificar e/ou decodificar imagens .webp é afetado pela vulnerabilidade.

• Qualquer sistema operacional ou imagem de contêiner que inclua ferramentas para processar imagens .webp é afetado pela vulnerabilidade.

Um dos fatores que contribuem para a ampla disseminação dessa vulnerabilidade nos ecossistemas de desenvolvimento é o uso da biblioteca libwebp por linguagens de programação de alto nível. Por exemplo, o motor de jogos GoDot, usado para criar jogos 2D e 3D, depende da biblioteca libwebp, e o utilitário FFmpeg, amplamente usado, também utiliza a biblioteca libwebp.

Como detectar a vulnerabilidade do libwebp com o Snyk

Há várias maneiras de detectar a vulnerabilidade do libwebp — gratuitamente — usando o Snyk. Com a Snyk CLI, você pode testar seus projetos localmente:

• Para aplicações, execute snyk test --unmanaged na Snyk CLI para comparar as dependências não gerenciadas do seu repositório e detectar pacotes específicos e suas vulnerabilidades.

• Para contêineres, execute snyk container test para detectar pacotes de sistema operacional que dependam de versões vulneráveis do libwebp.

Você também pode fazer uma varredura de todos os seus projetos nos repositórios Git e obter um relatório de todas as dependências diretas e transitivas que está usando. Nesse relatório, você verá se depende do libwebp e em quantos caminhos do seu grafo de dependências ele é usado. Também é possível pesquisar rapidamente por “CVE-2023-4863” em todos os projetos.

2a. Atualize para o libwebp 1.3.2 ou superior (código aberto)

• Correção automática: Conecte o Snyk aos seus repositórios Git para que ele possa abrir pull requests e atualizar seu grafo de dependências sempre que possível. Em seguida, recrie sua aplicação.

• Correção manual: Se você usa o libwebp como dependência direta na sua aplicação, atualize o arquivo de dependências diretamente para a versão 1.3.2 ou superior. Em seguida, recrie sua aplicação.

• Correção manual: Se você usa o libwebp como dependência transitiva na sua aplicação, identifique uma versão da sua dependência direta que inclua a dependência transitiva libwebp na versão 1.3.2 ou superior. Em seguida, recrie sua aplicação.

2b. Atualize para o libwebp 1.3.2 ou superior (contêiner)

• Correção automática: Conecte o Snyk aos seus repositórios Git para que ele possa abrir pull requests e atualizar a imagem base do seu Dockerfile sempre que possível. Confira se a atualização sugerida da imagem base ainda apresenta a vulnerabilidade em https://snyk.io/test/docker/<image_name> e, depois de identificar uma opção de atualização adequada, recrie seu contêiner.

• Correção manual: Se sua imagem inclui uma versão vulnerável do libwebp e você não tem uma atualização da imagem base disponível ou não quer usá-la, atualize a biblioteca manualmente seguindo as recomendações de correção do Snyk Container. Exemplo: em uma imagem baseada em Debian, se a CLI do Snyk Container informar o seguinte:

✗ High severity vulnerability found in libwebp/libwebpdemux2
  Description: Out-of-bounds Write
  Info: https://security.snyk.io/vuln/SNYK-DEBIAN12-LIBWEBP-5918869
  Introduced through: imagemagick@8:6.9.11.60+dfsg-1.6, imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6, libwebp/libwebp-dev@1.2.4-0.2, libwebp/libwebp7@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick/libmagickcore-dev@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-dev@8:6.9.11.60+dfsg-1.6 > librsvg/librsvg2-dev@2.54.7+dfsg-1~deb12u1 > gdk-pixbuf/libgdk-pixbuf-2.0-dev@2.42.10+dfsg-1+b1 > tiff/libtiff-dev@4.5.0-6 > libwebp/libwebp-dev@1.2.4-0.2 > libwebp/libwebpdemux2@1.2.4-0.2
  From: imagemagick@8:6.9.11.60+dfsg-1.6 > imagemagick/imagemagick-6.q16@8:6.9.11.60+dfsg-1.6 > imagemagick/libmagickcore-6.q16-6@8:6.9.11.60+dfsg-1.6 > libwebp/libwebpmux3@1.2.4-0.2
  and 4 more...
  Fixed in: 1.2.4-0.2+deb12u1

Você pode adicionar algo como isto para atualizar a biblioteca manualmente:

…
RUN apt-get update && \
    apt-get install -y libwebp-dev=1.2.4-0.2+deb12u1 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*
…

3. Monitore projetos com suporte a PRs automáticas

Como se trata de uma vulnerabilidade zero-day, novos impactos são descobertos diariamente. Por isso, é importante monitorar seus projetos regularmente para acompanhar novas recomendações de correção. Se você usa o Snyk, mantenha o monitoramento dos seus projetos ativado (ele já vem ativado por padrão quando você importa um repositório para o app do Snyk). Assim, o Snyk testa seus projetos automaticamente todos os dias, além de executar outros testes quando você faz atualizações.

Esses testes diários identificam automaticamente oportunidades para melhorar a segurança, inclusive quando novas correções ficam disponíveis. Por exemplo, se você usa o libwebp como dependência transitiva do package A, precisa que o package A lance uma versão que use o libwebp na versão 1.3.2 ou superior. Essa versão pode não estar disponível hoje, mas ser lançada amanhã ou na próxima semana. Com o snyk monitor, os testes são executados diariamente e você recebe uma PR quando a nova atualização fica disponível, atualizando a versão do libwebp para corrigir a vulnerabilidade.

Também é importante observar que o Snyk vai alertar você, por meio de PRs ou outros mecanismos, se novas correções forem disponibilizadas para essa vulnerabilidade ou se forem descobertos vetores de ataque que revelem novas vulnerabilidades. Assim, você fica sabendo primeiro o que precisa fazer caso surjam outros problemas.