Protestware está em alta no open source: 4 tipos diferentes e seus impactos

Há alguns dias, a Snyk divulgou um novo tipo de vetor de ameaça na comunidade open source: o protestware. O <em>advisory</em> tratava de uma vulnerabilidade transitiva — peacenotwar — no node-ipc, que afetou a cadeia de suprimentos de muitos desenvolvedores. A Snyk usa várias fontes de inteligência sobre ameaças e algoritmos para monitorar conversas sobre possíveis ameaças ao open source, e acreditamos que isso pode ser apenas a ponta do iceberg do protestware.

Desde a publicação do advisory sobre o node-ipc, vimos um grande aumento nos alertas específicos sobre ameaças relacionadas ao conflito e, consequentemente, no número de diferentes tipos de protestware em potencial ligados à invasão da Ucrânia.

A tendência atual do protestware se manifesta de várias formas. Algumas parecem ser formas aceitáveis de liberdade de expressão, enquanto outras, como o node-ipc, são mais destrutivas e prejudiciais. Na Snyk, queremos ajudar a comunidade a chegar a um consenso sobre como lidar com os vários tipos de protestware que estão surgindo e diferenciar cada um deles.

O que é protestware?

Protestware é um termo abrangente usado para descrever pacotes alterados de alguma forma para protestar contra um determinado evento. Diferentemente dos pacotes maliciosos, essas alterações não são feitas por “hackers” ou outros agentes mal-intencionados, mas muitas vezes por membros conhecidos e respeitados da comunidade open source, que atuam como mantenedores ou colaboradores de grandes projetos open source.

Antes de prosseguir, a Snyk está ao lado da Ucrânia. Nossa posição ficou clara quando decidimos doar ajuda à Ucrânia, dar visibilidade ao incrível open source que vem da Ucrânia e romper relações comerciais com entidades russas e bielorrussas. Dito isso, ainda é nosso dever informar sobre quaisquer ameaças que descobrirmos na comunidade open source e fazer a nossa parte para mantê-la segura.

Neste blog, vamos apresentar os quatro tipos gerais de atividade de protestware que encontramos até agora, além da nossa política para cada um deles. Esperamos que isso sirva de ponto de partida para novas conversas sobre o tema na comunidade.

Tipos de protestware

1. Banners no repositório

Nesse tipo de pacote, os mantenedores adicionam mensagens políticas em “banners” no próprio repositório. Isso pode incluir arquivos README alterados para expressar apoio à Ucrânia, mudanças na descrição do pacote em apoio à causa ou até mesmo issues abertas com uma mensagem explícita. Do ponto de vista da Snyk, esse tipo de protesto se enquadra claramente na liberdade de expressão não destrutiva, e todo mantenedor e colaborador tem o direito de expressar sua opinião sobre qualquer assunto que considerar adequado.

Nesses casos, entendemos claramente que não é necessário tomar nenhuma medida.

2. Mensagens de protesto nos logs da CLI

A segunda forma de protesto vai um passo além e exibe mensagens diretamente nas máquinas dos usuários, nos logs da CLI durante e após a instalação do pacote. O es5-ext é um bom exemplo disso em um pacote open source bastante popular, e o vetor usado nesse caso é bastante representativo desse tipo de protestware:

1. A máquina local verifica o fuso horário para determinar sua localização.

2. Com base na localização, um script pós-instalação registra uma mensagem de apoio à Ucrânia e informações sobre a guerra nos logs da CLI, além de instruções para baixar o Tor e contornar a censura do governo russo a sites com notícias sobre a guerra.

Ao analisar essas duas partes do vetor, concluímos que, embora esse comportamento seja incomum, ele tem precedentes no ecossistema de software. Quanto à verificação do fuso horário, consultas locais ao sistema às vezes fazem parte do comportamento normal de instalação — por exemplo, para determinar a melhor forma de instalar um pacote. Já os logs da CLI durante a instalação costumam ser bastante detalhados e nem todas as mensagens estão diretamente relacionadas à instalação do pacote (créditos, emojis e outras informações “leves” às vezes são registrados).

Desde que as mensagens permaneçam no ambiente de instalação (a CLI), acreditamos que não é necessário sinalizar esses pacotes especificamente.

3. Mensagens de protesto fora do ambiente de instalação

Essa distinção nos leva ao terceiro grupo de protestware: pacotes que protestam executando código fora do ambiente de instalação. Exemplos disso são os pacotes event-source-pollyfill e peacenotwar. Embora ambos usem o “vetor de geolocalização pelo fuso horário” descrito acima, eles vão além de registrar protestos nos logs e executam código ativamente na máquina para protestar.

Acreditamos que esse tipo de protestware, embora não seja destrutivo, gera um comportamento que não esperaríamos nem desejaríamos em um pacote open source. Os mantenedores podem optar por disseminar informações exibindo janelas de alerta, abrindo e redirecionando navegadores para sites com informações ou até criando novos arquivos na área de trabalho do sistema com grandes volumes de conteúdo.

Para pacotes desse tipo, vamos adicionar um advisory com o título “Comportamento indesejado”. Nossos vetores CVSS serão elaborados para demonstrar exatamente qual é o comportamento indesejado e como ele afeta a integridade da máquina em que é executado.

4. Protestos destrutivos

Por fim, temos o tipo de pacote que exibe claramente um comportamento destrutivo e ameaça diretamente as máquinas em que é executado. O node-ipc é atualmente o pacote mais conhecido e de maior impacto desse tipo e, como divulgamos anteriormente, tenta apagar os discos rígidos do sistema.

Pacotes que causam danos de fato, como excluir arquivos, vazar informações privadas ou qualquer outra ação prejudicial, serão classificados como “Pacote malicioso”, com gravidade alta ou crítica (dependendo do impacto específico do pacote).

Fique atento ao protestware

Em resumo, a situação atual é volátil, e esperamos continuar enfrentando novos vetores de ameaça relacionados ao protestware. Vemos nosso papel nesse cenário de duas formas:

1. Continuar alertando a comunidade sobre novos padrões de ameaça assim que surgirem, com a maior rapidez e diligência possível.

2. Ajudar a orientar a conversa sobre como nossa comunidade deve responder ao protestware em todas as suas formas e, esperamos, construir um consenso mais amplo sobre o assunto.

Se você encontrar outros casos de protestware em pacotes open source, fique à vontade para entrar em contato conosco pelo nosso programa de divulgação de vulnerabilidades open source. Agradecemos por ajudar a manter o open source seguro para todos.