Cyberfront: Sabotagem Começa a Atingir o Software Open Source

O site Ars Technica reporta que um desenvolvedor foi pego adicionando código malicioso a um popular pacote de código aberto que apagou arquivos em computadores localizados na Rússia e na Bielorrússia como parte de um protesto que enfureceu muitos usuários e levantou preocupações sobre a segurança do software livre e de código aberto.

Imagem: Pexels

O aplicativo, node-ipc, adiciona a um sistema recursos de comunicação e redes neurais a outras bibliotecas de código aberto. Por ser uma dependência de outro programa, o node-ipc é baixado automaticamente e incorporado a outras bibliotecas, incluindo algumas como Vue.js CLI, que possui mais de 1 milhão de downloads semanais.

A atualização espúria do node-ipc é apenas um exemplo do que alguns pesquisadores estão chamando de protestware. Especialistas começaram a rastrear outros projetos de código aberto que também estão lançando atualizações chamando a atenção para a brutalidade da guerra da Rússia. Esta planilha lista 21 pacotes diferentes que são afetados.

Um desses pacotes é o es5-ext, que fornece código para a especificação da linguagem de script ECMAScript 6. Uma nova dependência chamada postinstall.js, que o desenvolvedor adicionou em 7 de março, verifica se o computador do usuário tem um endereço IP russo. Em caso positivo o código transmite uma “mensagem de paz”.

“Mensagem de paz”, que o sabotador codificou no aplicativo comprometido – Imagem da Internet

As pessoas que não trabalham no ramo talvez se surpreendam com a grande quantidade de software crítico que depende dos caprichos de programadores anônimos que mantêm bibliotecas de software de forma inconsistente, como hobby ou projeto secundário. Repetidas ocorrências estão transformando isso em uma vulnerabilidade séria. A Casa Branca anunciou no ano passado uma iniciativa para começar a resolver esse problema, declarando que vai passar a exigir uma “lista de materiais de software” para todo software encomendado pelo governo:

…o termo “Lista de Materiais de Software” ou “LMDS” significa um registro formal contendo os detalhes e relacionamentos da cadeia de suprimentos de vários componentes usados na construção de software. Desenvolvedores e fornecedores de software geralmente criam produtos montando e mesclando componentes de software comercial e de código aberto dos repositórios existentes. A LMDS enumera esses componentes em um determinado produto. É análogo a uma lista de ingredientes em embalagens de alimentos. Uma LMDS é útil para quem desenvolve ou fabrica software, para quem seleciona ou compra software e para quem opera software. Os desenvolvedores geralmente usam componentes de software de código aberto e de terceiros disponíveis para criar um produto; uma LMDS permite que o desenvolvedor certifique-se de que os componentes de terceiros usados em seus projetos estejam atualizados e responda rapidamente a novas vulnerabilidades. Por exemplo, os compradores podem usar uma LMDS para realizar análise de vulnerabilidade ou licença. Aqueles que operam software podem usar LMDSs para determinar facilmente se estão em risco potencial de uma vulnerabilidade recém-descoberta. Um formato LMDS universal, legível por máquina, que seja amplamente utilizado, permite maiores benefícios por meio da automação e integração de ferramentas. Os LMDSs ganham maior valor quando armazenados coletivamente em um repositório que pode ser facilmente consultado por outros aplicativos e sistemas. Compreender a cadeia de suprimentos de software, obter um LMDS e usá-lo para analisar vulnerabilidades conhecidas são cruciais no gerenciamento de riscos.

Fornecedores governamentais

Vários empreiteiros de defesa em todo o mundo usam recursos de código aberto em todos os tipos de aplicativos implantados em sistemas militares, desde comunicações, navegação, controle de voo, controle de fogo e aplicativos de missão crítica.

Grande parte do código que é modificado ou adicionado nos repositórios de código aberto está dentro do contexto de aplicativos seguros. A questão, porém, é qual o nível de exposição dos sistemas de missão crítica e outros sistemas vulneráveis a esse problema? Qual o componente de risco/recompensa mais aparente nessa escalada interminável de guerra de códigos? Talvez estejamos diante da necessidade de um acordo de não proliferação de armas cibernéticas entre estados-nações.

Bom começo

Uma LMDS é apenas uma boa prática. Os projetos de desenvolvimento bem executados sempre devem ter uma lista de requerimentos de sistema para gerenciar dependências e atualizações. Algumas licenças, a GPL e a LGPL em particular, exigem implicitamente uma licença parcial na medida em que exigem a identificação dos componentes GPL para o destinatário. Estabelecer uma lista de requerimentos que possa ser compartilhada não é um um problema complicado e é um bom começo.

...mas não suficiente

A dimensão do problema está muito além de uma Lista de Materiais. Um grande número de desenvolvedores executa muitos pacotes de software que são atualizados em massa, ou muitas vezes atualizados automaticamente a partir de uma ampla variedade de “fornecedores” em vários países.

No mundo do código aberto, instalamos chaves para os gerenciadores de repositórios (como o Ubuntu) que, em teoria, assinam os pacotes destinados ao download pelos usuários após verificá-los, mas na verdade não os verificam. Portanto, quando o desenvolvedor oficial autorizado de um pacote deseja inserir malware em seu pacote, pouco ou nada pode detê-lo. É uma violação de confiança que pode resultar em punição – uma punição que virá após o fato.

O desenvolvedor do qual falamos aqui atacou indiscriminadamente tanto civis como alvos legítimos em sua sanha de justiça – talvez tenha até cometido um crime de guerra. O que aconteceria se ele tivesse codificado seu programa para atingir alvos militares sensíveis no contexto geral das relações Leste-Oeste? E se fosse o próprio computador de Putin?

Nenhuma regra vai parar isso. Se o seu país estiver em uma guerra (uma que ele começou ou para a qual foi arrastado), você deve considerar que qualquer atualização de software em seu sistema vem de um adversário – ou de uma fonte que pode ser comprometida pelo seu adversário. Essa é a realidade da guerra.

Twitter versus Software Livre

Há muitos debates complicados acontecendo agora sobre o Twitter e seu papel no discurso público. Essas discussões são importantes, mas também não devemos esquecer um princípio muito básico e claro: quaisquer que sejam suas políticas sobre quem pode e não pode postar ou como postar, é de fundamental importância que o Twitter não exija que os usuários executem software não-livre para usar o site.

Infelizmente, no dia 15 de dezembro, 2020, o Twitter removeu sua interface web “legada”. Ao contrário de seu app cliente padrão muito maior e mais complexo, a interface legada não usava javascript proprietário (ou qualquer javascript).

Até o ano passado, a Fundação Software Livre (FSF) podia tolerar o uso do Twitter por causa dessa interface legada. Enquanto a interface estava ativa nós encaminhávamos os usuários do software gratuito para ela ou a outros aplicativos gratuitos de terceiros. O fato de o Twitter estar removendo o acesso a essa interface significa que os usuários são agora forçados a usar o JavaScript não gráfico do site (se eles não tiverem um desktop ou cliente móvel dedicado), impedindo os navegadores que respeitam a liberdade como o GNU ICECAT de postar para o serviço.

Mas por que usar o Twitter em primeiro lugar, se sabemos que ele tem esses problemas? Como qualquer instituição de caridade pode atestar, engajar os usuários em mídias sociais é uma das maneiras principais de espalhar sua mensagem.

O mesmo é verdade para a liberdade de software. Precisamos estar falando de software livre nos lugares onde os usuários não estão comprometidos com o software livre – não seremos bem sucedidos se formos apenas à nossa própria câmara de eco, ou continuar pregando aos convertidos. É importante que os ativistas estejam atingindo as pessoas nessas redes sociais, mesmo que tenhamos reservas sobre como usá-las. O Twitter tem sua participação em questões sociais; precisamos incluí-lo em nossa estratégia de mensagens. Somos, no entanto, cuidadosos para garantir que você não seja obrigado a seguir o FSF no Twitter, a fim de receber notícias ou atualizações. Tudo o que publicamos também é publicado em plataformas baseadas em princípios de software livre, incluindo Mastodon e GNU Social.

Independentemente de qualquer classificação, no âmbito do software livre a regra é clara: você não pode ser obrigado a usar software não-livre (como JavaScript, PDF, etc) para usar redes sociais.

Como a interface “Legada” (a que não depende do javascript não dirigido pelo Twitter) foi removida, aqueles que se importam fortemente com sua liberdade devem agora dar passos adicionais para usar a plataforma e manter sua autonomia ao mesmo tempo. Na FSF, usamos uma versão ajustada da ferramenta Rainbowstream para GNU / Linux, personalizada por nosso administrador de sistemas sênior Ian Kelling. O script que Ian escreveu nos permite chamar programaticamente a Rainbowstream, bem como o utilitário de toot para mastodon, o cliente Diaspy para DiSpora, e um script de enrolamento que usamos para postar na nossa instância social GNU, https://status.fsf.org.

Graças a alguma colagem “bash” de Ian, somos capazes de fazer posts para esses serviços de uma só vez (o que é chamado de ‘bridging’), e também anexar imagens aos nossos posts. Esta configuração funcionou bem para nós por quase um ano. (*)Se você precisar de um app cliente gratuito para o Twitter, recomendamos o Rainbowstream ou os clientes móveis disponíveis no repositório Android do F-Droid da liberdade, como Twidere.

Embora tenhamos trabalhado de uma maneira a que a equipe de campanhas possa postar no Twitter sem comprometer nossa liberdade, isso não significa que a FSF não seja afetada pela “deprecação” da antiga interface. Como não aconselhamos usar software incompleto em qualquer contexto, tivemos que fazer algumas alterações na nossa página “Compartilhar” e remover o link para nosso perfil do Twitter dos e-mails que enviamos.

Queremos que os usuários espalhem a mensagem de software livre e aprendam sobre nós na mídia social, mas como clicar em um link para o Twitter agora envolve a execução de Javascript não grátis, não queremos apontar as pessoas para qualquer coisa que sabemos eticamente condenável

Problemas “user-hostis” como estes são a razão de o FSF apoiar serviços de rede descentralizados onde quer que possamos. Fizemos isso antes, como em 2008, quando fomos a uma série de uma cúpulas sobre serviços de rede que culminou na publicação da declaração de Franklin Street. O foco da declaração na promoção de serviços descentralizados e na liberdade frente a vigilância corporativa e governamental a granel permanecem parte da nossa estratégia de campanhas. O Twitter pode hoje ter a maioria dos usuários de qualquer rede de microblogging de seu tipo, mas a longo prazo, plataformas descentralizadas, como Mastrodon ou Peertube, prevalecerão. Até mesmo Jack Dorsey do Twitter reconheceu o apelo dessas redes, que são baseadas na participação descentralizada. Continuamos esperançosos de que o Twitter apoiará a descentralização e, ao mesmo tempo, priorizará a liberdade de software.

Sendo uma rede de mídia social tão popular, há uma variedade de questões em torno do Twitter e o que ele significa para a web. Não devemos deixar essa complexidade obscurecer o que não é complexo: o Twitter não deve exigir que ninguém use software não livre para participar do site. Permitir que seus usuários acessem o serviço e mantenham sua liberdade ao mesmo tempo é a linha-base da aceitabilidade, mas a partir daí, existem ainda outras etapas em que o Twitter pode assumir a direção certa, como, por exemplo, estimular um futuro promissor para as iniciativas de descentralização.

Desmontar seu próprio silo e se tornar um entre muitos “nós” da rede descentralizada pode ser sem precedentes a partir de um ponto de vista comercial ou de desenvolvimento, mas também seria sem precedentes em termos do respeito pela liberdade do usuário que isso demonstraria.

Copyright © 2004-2021 Free Software Foundation, Inc.

This work is licensed under a Creative Commons Attribution-No Derivative Works 3.0 license (or later version)Why this license?

NOTAS:

1) Bravo Marques apóia a Fundação Software Livre

2) Estamos também envolvidos em um projeto de Mensagens Instantâneas decentralizadas usando o protocolo XMPP. Estamos adquirindo domínios e capacidade em servidores para a empreitada. O serviço é desenvolvido com o nome provisório “Verbat”. Em breve teremos notícias.