Como se antecipar às vulnerabilidades de segurança com patches de segurança

Tradicionalmente, como parte do fluxo de trabalho de desenvolvimento de software, as equipes costumam lançar novas versões de seus pacotes ou aplicativos para corrigir problemas de segurança assim que eles surgem.

No entanto, em projetos de código aberto, os mantenedores geralmente são voluntários e podem precisar priorizar outros compromissos. Por isso, pode levar algum tempo até que versões dos pacotes com as correções sejam publicadas. Isso pode criar uma lacuna significativa entre a descoberta de uma vulnerabilidade e sua correção e divulgação pública. Infelizmente, sem uma versão oficial do componente de software que inclua a correção, o risco de exploração aumenta.

Para lidar com situações como essa, a Snyk seleciona patches de segurança para projetos JavaScript de código aberto do ecossistema npm. Assim, ajudamos os mantenedores a manter seus pacotes seguros e a se antecipar às ameaças, mesmo quando não podem corrigir os problemas de segurança imediatamente. A Snyk aplica uma correção de segurança diretamente a qualquer pacote npm afetado, em coordenação com o mantenedor. Dessa forma, mesmo que ainda não exista uma versão oficial que resolva o problema (ou que a versão possa quebrar seu build), você fica protegido.

Por que os patches de segurança são importantes?

A demora dos mantenedores de código aberto para lançar uma correção de segurança pode ter consequências graves. Por isso, os patches de segurança são essenciais. Um exemplo disso são as vulnerabilidades de poluição de protótipo descobertas recentemente na popular biblioteca JavaScript lodash.

A equipe de pesquisa de segurança da Snyk descobriu vulnerabilidades de poluição de protótipo no lodash (CVE-2019-10744), que afetavam todas as versões. Desde a descoberta, trabalhamos com John Dalton, mantenedor do lodash, por meio de um processo de divulgação responsável para comunicar os resultados e fornecer correções de segurança para as vulnerabilidades.

Assim que as correções foram disponibilizadas em um Pull Request para resolver o problema de segurança no repositório do lodash, começou a contagem regressiva para o lançamento de uma versão oficial do lodash com essas correções.

As informações sobre a vulnerabilidade foram divulgadas em 2 de julho de 2019, mas o lançamento oficial demorou uma semana e só foi publicado em 9 de julho de 2019.

O patch de segurança fornecido pelo mecanismo da Snyk é gratuito para todos os usuários. Abrimos Pull Requests proativamente para aplicar o patch, corrigir a vulnerabilidade de segurança e proteger seus projetos.

Como a Snyk aplica patches de segurança?

O mecanismo de aplicação de patches da Snyk funciona com a integração ao suporte do npm a scripts no package.json para eventos do ciclo de vida. O processo do npm permite que programas de correção se integrem perfeitamente ao gerenciamento do ciclo de vida do npm em diferentes etapas do build, como durante a instalação do npm, a publicação em um registro e assim por diante.

A página da documentação do npm traz informações detalhadas sobre todos os eventos disponíveis do ciclo de vida do npm e explica como e quando eles são executados.

A Snyk usa o evento do ciclo de vida prepublish em package.json para aplicar patches antes de o pacote ser empacotado e publicado, e também sempre que o npm install é executado localmente sem argumentos adicionais_._Para entender melhor como isso funciona, podemos criar alguns pacotes localmente e usar verdaccio como registro npm local para testar a publicação e a instalação de módulos.

Com um npm init -y e uma atualização do nosso módulo de teste aaa para incluir um script prepublish, o código fica assim:

1
2{
3  "name": "aaa",
4  "version": "1.1.0",
5  "description": "",
6  "scripts": {
7    "test": "echo \"Error: no test specified\" && exit 1",
8    "prepublish": "echo hello little green world"
9  },
10  "main": "index.js",
11  "keywords": [],
12  "author": "",
13  "license": "ISC"
14}

Quando executamos um npm install no prompt de comando, o seguinte é exibido:

Nosso evento do ciclo de vida do npm foi executado, imprimindo esse breve texto no console. Nesse processo, a Snyk também aplica os patches necessários.

A Snyk atualiza a configuração do seu evento pre-publish para que fique assim:

1
2"scripts": {
3  "snyk-protect": "snyk protect",
4  "prepublish": "npm run snyk-protect"
5}

Quando um npm install é executado, a Snyk identifica as vulnerabilidades no seu código, baixa do nosso banco de dados um patch para corrigi-las e o aplica ao módulo vulnerável na pasta node_modules.

Isso significa que, quando você clona um projeto, instala todas as dependências e o executa, a Snyk é acionada durante a instalação dos módulos para corrigir a vulnerabilidade de segurança.

Em projetos Node.js, quando você executa o aplicativo, ele já está protegido. No caso de uma biblioteca JavaScript típica que transpila código com um empacotador de módulos como webpack, babel ou typescript, o resultado do bundle, que geralmente fica em dist/, também inclui a correção da vulnerabilidade de segurança.

Como funciona o npm prepublish?

Talvez você siga fluxos diferentes, em vez de simplesmente executar um npm install no projeto. Isso pode fazer com que o evento prepublish seja ignorado. Nesses casos, os patches da Snyk não são aplicados.

Para entender melhor o evento de script prepublish do npm, vamos ver como ele é acionado:

• npm install

• npm install --dev

• npm ci

• yarn

• yarn install

• yarn install --frozen-lockfile

Quando o evento prepublish do npm não é acionado?

• npm install --prod

• yarn install --prod

Como mencionei antes, ao executar npm install com argumentos adicionais, o evento prepublish não é incluído. Portanto, se o fluxo de trabalho de instalação das dependências de módulos npm incluir a execução de npm install --prod, você pode acionar diretamente o snyk protect da Snyk.

Por exemplo, considere a seguinte configuração do Travis CI:

1
2install:
3  - npm install --prod
4  - snyk protect

Patches de segurança da Snyk para bibliotecas

Em nossos testes com pacotes npm, usamos estas duas bibliotecas:

• aaa — tem vulnerabilidades de segurança nas dependências, e seus mantenedores ainda não lançaram versões mais recentes com uma correção oficial. Os patches da Snyk corrigem essas vulnerabilidades.

• bbb — usa aaa como dependência

No nosso caso, o projeto bbb usa aaa. Quando bbb instala suas dependências, por exemplo, ao executar npm install, o evento do ciclo de vida prepublish de aaa não é executado.

Isso significa que, a menos que aaa tenha sido publicado no registro como um bundle transpilado que inclui todas as dependências — algo comum apenas em bibliotecas de front-end —, ao instalar aaa em bbb, as bibliotecas aninhadas de aaa ainda terão as mesmas vulnerabilidades de segurança conhecidas.

Nesses casos, o mantenedor da biblioteca principal bbb deve corrigir as vulnerabilidades de segurança oferecendo patches que também resolvam as dependências aninhadas de aaa.

Resumo

Em resumo, quando os mantenedores não conseguem lançar novas versões com correções de segurança a tempo — ou, em casos mais graves, deixam de participar dos projetos e não respondem mais —, aumenta ainda mais o período em que as vulnerabilidades de segurança permanecem sem correção. Por isso, patches de segurança direcionados são essenciais para ajudar você a se antecipar às vulnerabilidades ainda não corrigidas.