A piada sobre alguém em Nebraska: Um problema de infraestrutura digital que muitos ainda ignoram

Isso é uma piada ou um alerta? — Ambos

Esta piada faz parte do xkcd, uma webcomic criada pelo cartunista, engenheiro e escritor americano Randall Munroe. O que o autor está tentando mostrar aqui é a dependência entre elementos em um sistema ou arquitetura digital geral representada como uma torre de blocos — como um Jenga — que simboliza componentes de software. Assim, à medida que subimos da base da torre, os componentes dos níveis superiores dependem de mais e mais componentes dos níveis inferiores.

Curiosamente, no terceiro nível da torre, de baixo para cima, encontramos um componente fino que, poderíamos supor facilmente, se quebrado ou removido, significaria a desestabilização e a queda de todo o sistema, ou pelo menos do que está lá em cima (ou seja, "toda a infraestrutura digital moderna"). O que é mais peculiar e engraçado, mas ao mesmo tempo preocupante, é que, além de ser um componente fino, Randall se refere a ele como um projeto mantido por uma pessoa aleatória em um lugar específico desde uma data específica. Mas o que isso significa?

Na verdade, não é que nossos sistemas dependam do que um indivíduo específico em Nebraska está fazendo. O que esta piada — ao mesmo tempo um alerta — parece estar apontando é dar um exemplo de uma realidade geral que temos experimentado por muitos anos: vários programas ou componentes de software, alguns deles pequenos, mantidos principalmente por razões pessoais por uma ou algumas pessoas desconhecidas ou não reconhecidas, em qualquer lugar do mundo, sustentam grande parte da nossa atual infraestrutura digital.

Enquanto a caricatura de Randall retrata a realidade mencionada, quando revisamos sua legenda, podemos ler algo como o seguinte: Um dia, o ImageMagick finalmente quebrará para sempre e teremos um longo período de confusão enquanto tentamos reassemblar a civilização dos escombros. Este é um exemplo específico, talvez exagerado, mas ilustrativo. ImageMagick é um software livre e de código aberto para processar, criar, exibir, editar e converter imagens raster, criado em 1987 por John Cristy, que tem sido e é amplamente utilizado em várias aplicações, especialmente aquelas destinadas a serviços web, e às quais comunidades de engenheiros e desenvolvedores contribuíram ao longo do tempo.

Embora muitas outras bibliotecas e APIs possam realizar tarefas do ImageMagick, esta parece ter se tornado o pacote padrão. O problema com esta biblioteca é que, em 2016, cinco vulnerabilidades foram descobertas nela (que acabaram levando o nome "ImageTragick"), uma das quais, se explorada, permitiria a execução remota de código (RCE). Essa descoberta acionou alarmes entre engenheiros e desenvolvedores, significando um alto risco potencial, já que se o ImageMagick fosse desativado, uma multidão de programas que dependiam dele falharia, pelo menos temporariamente, mostrando um desequilíbrio e colapso na "torre".

Aprofundando no problema

Hoje em dia, muitos de nós sabemos, embora muitos mais provavelmente não estejam cientes disso, que as menores e maiores empresas e organizações ao redor do mundo estão usando componentes de software de código aberto de terceiros. Quase todo o software existente depende de tais produtos desenvolvidos e mantidos por indivíduos e comunidades de desenvolvedores. Mas por quê?

Uma das principais razões é o provérbio agora típico, "Não reinvente a roda." Ou seja, se essa obra humana já se mostrou suficientemente funcional, não perca tempo e dedique-se a construir algo novo. No universo do software, muitas pessoas criam e compartilham código publicamente e gratuitamente, que cumpre funções específicas, algumas das quais são muito básicas. Assim, outros não precisam construir suas aplicações do zero; não precisam desenvolver todos os componentes de seus produtos. Eles simplesmente recorrem ao que já foi criado e compartilhado pela comunidade, o que permite um desenvolvimento tecnológico mais barato, simples e eficiente.

"Reinvent the Wheel." Tira cómica #2140 no xkcd.

Em outras palavras, aqui estamos falando de reutilização e modularidade, princípios que têm sido usados há muito tempo, mas que são fundamentais hoje na engenharia de software. Portanto, quando um grupo de desenvolvedores se propõe a criar uma aplicação, o que termina construindo é uma cadeia ou árvore de dependência com vários componentes de software de código aberto previamente desenvolvidos separadamente por outros engenheiros, alguns deles de poucas linhas de código que cumprem funções específicas.

O problema, como ilustrado por Randall, é que muitos desses projetos de componentes de software de código aberto que são fundamentais para projetos em larga escala são mantidos muitas vezes por muito poucas pessoas. Ao contrário de grandes empresas como Linux, por exemplo, muitos outros projetos não recebem atenção suficiente. Aqueles que os preservam geralmente são especialistas neles que muitas vezes trabalham demais e por pouco ou nenhum dinheiro, principalmente como um hobby, e sobre quem toda a responsabilidade recai. No entanto, por razões como o cansaço ou a busca por melhores oportunidades, alguns desses projetos podem ser abandonados. Este inconveniente, juntamente com as vulnerabilidades de segurança que podem estar presentes, muitas vezes significa um risco considerável para a integridade e segurança de "todo o sistema".

Heartbleed e left-pad

Além do caso do ImageMagick, outros casos ilustrativos deste preocupante problema foram, por exemplo, os de Heartbleed e left-pad. Heartbleed é um bug descoberto em 2014 no OpenSSL, uma biblioteca que permite comunicações criptografadas pela Internet, por exemplo, para e-commerce. Este, ao contrário de outros, é um componente de software relativamente grande, uma vez que, naquela época, tinha cerca de 500 mil linhas de código. Como reportado em um website simples dedicado a essa vulnerabilidade, Heartbleed permitia roubar informações protegidas, sob condições normais, pela criptografia SSL/TLS usada para proteger a Internet.

Aparentemente, este caso qualificou-se como irresponsabilidade por parte da equipe do OpenSSL porque eles já conheciam um problema latente a que não prestaram atenção suficiente. Levou cerca de dois anos para detectar o Heartbleed. O pior é que, aparentemente, a manutenção do componente afetado dependia apenas de dois caras, ambos voluntários e sobrecarregados. Dizem que, apesar do que aconteceu, as doações para este projeto cresceram muito pouco, passando de cerca de 2.000 para 9.000 dólares por ano. (Esse subfinanciamento é algo prevalente na história do desenvolvimento de software de código aberto e algo que enfatizamos em outro post no blog.)

"Heartbleed." Tira cómica #1353 no xkcd.

Para um caso mais recente e semelhante, veja o do Log4j, uma biblioteca de código aberto da Apache na qual foi descoberta uma vulnerabilidade que permitia que atacantes remotos executassem código arbitrário em sistemas expostos.

No que diz respeito ao left-pad, resulta que um jovem chamado Azer Koçulu estava desenvolvendo código para npm, um conhecido e amplamente utilizado serviço de desenvolvimento web para encontrar e instalar pacotes de software de código aberto escritos em JavaScript. Quando o npm, em um imbróglio que não vale a pena mencionar aqui, aparentemente agiu contra os princípios básicos da cultura de código aberto em relação a um pacote no qual Koçulu estava trabalhando, ele escolheu abandoná-lo, especificamente deletá-lo, em 2016, o que levou a um colapso entre muitos projetos e sites dependentes dele.

Assim, engenheiros e outros indivíduos começaram a receber mensagens de erro ao tentar executar suas aplicações e serviços. Estes requeriam um pacote chamado left-pad que o npm não tinha mais em seu portfólio e que algumas pessoas nem sequer tinham ouvido falar antes. Era muito estranho que um pacote tivesse desaparecido. O mais curioso é que ele tinha apenas 11 linhas de código simples para cumprir uma única função. A ausência desta pequena biblioteca afetou muitos outros pacotes que dependiam dela, direta ou indiretamente; entre os últimos, React, um grande componente amplamente utilizado em diferentes países ao redor do mundo, até mesmo no site do Facebook. Diante desse caos, o npm foi forçado a restaurar prontamente aquelas 11 linhas de código.

Como deveríamos lidar com este problema?

Que cada um trabalhe em todos os componentes de seus próprios produtos de software? Isso não é viável. O que parece mais viável no momento é manter a cultura de código aberto intacta, mas contribuir para sua manutenção e segurança em maior grau. Como muitos já disseram, por que as grandes empresas do sistema capitalista que dependem desses projetos públicos e gratuitos não contribuem para seu financiamento ou de alguma outra forma? Onde está o apoio institucional e governamental? Tudo isso ainda é insuficiente.

Além de conscientizar sobre esta situação, tentando minimizar a ignorância a respeito e buscando financiamento para projetos dos quais todos dependemos, muitas empresas de diferentes setores industriais também podem contribuir para a segurança de nossa infraestrutura digital. Atenção! O fato de não precisarmos reinventar a roda não significa que devamos ignorá-la. Não podemos acaso aprender sobre ela? Embora não precisemos desenvolver os componentes de software de terceiros que utilizamos em nossos produtos, devemos conhecê-los, revisá-los, atualizá-los, melhorá-los.

É aqui que entra a tão falada lista de materiais de software (SBOM). Utilize-a como um inventário organizado de todos os componentes de terceiros usados pela sua aplicação. A partir daí, descarte os pacotes que são desnecessários, solicite uma avaliação de vulnerabilidade de segurança no restante e, se possível, contribua com revisão, código ou fundos, especialmente para aqueles componentes de software que desempenhem um papel crítico para manter viva sua companhia.

A situação atual de nossa infraestrutura digital é uma das questões menos compreendidas de nosso tempo. É crítico que a entendamos.

Nadia Eghbal

Se você deseja aprender como a Fluid Attacks pode ajudá-lo com SBOM, análise de composição de software (SCA) e mais testes de segurança, sinta-se à vontade para entrar em contato conosco.