Proibição do Linux da Universidade de Minnesota faz perguntas sobre código aberto

Geralmente, existem dois tipos de hackers: aqueles que invadem sistemas de computador para encontrar vulnerabilidades para corrigi-los e criminosos que exploram fraquezas para roubar dados e manter as organizações como reféns.

Depois, há Kangjie Lu, professor assistente da Universidade de Minnesota especializado em segurança de computadores. Ele ganhou notoriedade recentemente por criar propositalmente vulnerabilidades no sistema de software de código aberto mais proeminente do mundo, o kernel Linux. Depois que ele publicou um artigo acadêmico sobre suas façanhas, a equipe do kernel Linux baniu a universidade e reverteu suas correções anteriores.

Vulnerabilidades intencionais do kernel Linux

As revelações levantaram questões sobre segurança de código aberto e o kernel do sistema operacional, um componente fundamental de inúmeros dispositivos e servidores. Lu enterrou vulnerabilidades em algumas pequenas correções que ele e um estudante de pós-graduação submeteram ao vasto repositório de código de software do Linux, subvertendo um método colaborativo que é essencial para manter o programa seguro.

“Eles tiveram um sucesso lamentável”, diz Alexander Sereda, gerente de projeto de Toronto que ingressou na rede Toptal em 2020. “Seu código malicioso passou pela supervisão da comunidade que deveria eliminar esse tipo de envio”.

Enquanto o Windows e o macOS dominam os desktops, os sistemas operacionais baseados em Linux são de longe os mais populares para servidores e supercomputadores, e o Google usa uma versão modificada do kernel para Android. Gigantes da tecnologia como a Red Hat construíram seus negócios de software empresarial em torno do código aberto e até mesmo a Microsoft, que por anos foi vista como uma das principais oponentes do ecossistema de código aberto, apareceu: em 2018, comprou o GitHub, o maior host de sistemas de código aberto. projetos de origem; hoje, as distribuições Linux podem ser encontradas na Microsoft Store.

É difícil exagerar a onipresença do kernel Linux e do software de código aberto, evoluindo do material de amadores e idealistas para uma pedra angular do mercado de software atual. Existem literalmente milhões de projetos de código aberto para os desenvolvedores analisarem e, por serem gratuitos e, em sua maioria, confiáveis, mais de 90% dos aplicativos comerciais contêm esses componentes. Esse número continua crescendo, de acordo com um estudo anual da empresa de design de silício e segurança de software Synopsys.

Ser confiável é tão importante quanto ser gratuito, e a comunidade de código aberto se orgulha de fornecer programas que são iguais, se não melhores que, software proprietário. O movimento surgiu na década de 1990 com um princípio central, cunhado pelo desenvolvedor e autor Eric Raymond, de que “com olhos suficientes, todos os bugs são superficiais”. Esse código aberto até agora sobreviveu relativamente incólume – mesmo enquanto o mundo enfrenta uma epidemia sem precedentes de hackers e ransomware – é apenas mais uma afirmação de que essa colaboração aberta ainda pode ser eficaz.

Mas, como Lu mostrou em sua pesquisa, nenhuma segurança é perfeita, mesmo em algo tão crítico e monitorado de perto quanto o kernel do Linux. Embora escrever código seguro possa ser simples, encontrar vulnerabilidades no código após o fato pode ser incrivelmente difícil – “como remover o leite do seu chá depois de misturado”, diz Sereda. Embora o código aberto tenha em geral um desempenho admirável, além de alguns problemas significativos como o bug Heartbleed que surgiu em 2014, há um crescente corpo de evidências de que os desenvolvedores, por sua vez, estão tomando muitos atalhos ao incorporar software livre em seus produtos.

Riscos de segurança de código aberto

Em seu relatório anual de 2021, a Synopsys revela que todas as empresas do setor de tecnologia de marketing auditadas tinham código aberto em sua base de código e 95% dessas bases de código continham vulnerabilidades. Ele encontrou resultados semelhantes ao analisar o setor de saúde, o setor de serviços financeiros e os setores de varejo e comércio eletrônico. Há uma série de razões para os resultados ruins, mas a principal delas é que o software está ficando cada vez mais complicado e, à medida que isso acontece, fica mais difícil rastrear e monitorar os componentes.

O código aberto tem um histórico de segurança muito melhor do que os produtos proprietários, mas isso não garante que sempre será da melhor qualidade, diz Sam Watkins, desenvolvedor full-stack freelance que ingressou na rede da Toptal em 2021. problema, que é programas excessivamente complicados. É inseguro, embora não por intenção maliciosa.”

O problema então não é necessariamente que o código aberto seja muito aberto. Em vez disso, é a lacuna que persiste porque não há um único fornecedor lançando patches para a comunidade, mesmo que os ciclos de software continuem diminuindo, diz Timothy Mackey, principal estrategista de segurança da Synopsys. Orçamentos apertados forçam os programadores a usar atalhos imperfeitos como sistemas de classificação simplistas para escolher seus componentes – por popularidade, em vez de qualidade. Existem vários serviços que oferecem aos programadores esses atalhos, incluindo Openbase, Stack Builder e o Open Source Index, que destaca os projetos mais populares no GitHub.

Gerenciando a vulnerabilidade de código aberto

De acordo com programadores e acadêmicos, embora haja valor nesses sistemas de classificação de código aberto, é preciso haver mais validação e consideração ao pesar as opções, em vez de apenas pegar os componentes que parecem ser a melhor combinação. Cada organização deve estabelecer um conjunto de práticas recomendadas que inclua princípios para a escolha cuidadosa de software que leve em consideração a quantidade de suporte necessária e os riscos enfrentados. As empresas também devem acompanhar e atualizar com frequência todos os seus componentes de código aberto.

Algumas outras práticas recomendadas que nossos especialistas identificaram para consideração incluem:

• Usando automação, verificando processos, documentando tudo e usando Git para rastrear alterações na base de código.
• Criar uma comunidade positiva, incluindo ajudar pessoas novas no código aberto que podem se tornar colaboradores importantes.
• Manter todas as cadeias de suprimentos de código aberto auditáveis.
• Usando contêineres de código aberto que compartilham o kernel do sistema operacional host.
• Identificando os componentes de código aberto mais críticos, rastreando seus problemas de segurança, interagindo com seus desenvolvedores e contribuindo de volta para projetos upstream com patches e financiamento.

Ann Barcomb, professora assistente da Escola de Engenharia Schulich da Universidade de Calgary, acrescenta que, idealmente, as organizações deveriam usar um conjunto de práticas recomendadas para construir bibliotecas de produtos pré-aprovados para que o software nunca seja selecionado arbitrariamente. No entanto, ela reconhece que esse processo é demorado, caro e pouco praticado.

“Você quer mais segurança, mas essa segurança tem um preço alto”, diz Ayush Poddar, desenvolvedor de back-end freelance que ingressou na Toptal em 2021.

Plataformas como Black Duck, Sonatype, Snyk e WhiteSource fornecem automação para ajudar a encontrar componentes de código aberto na pilha de um programa de computador e identificar vulnerabilidades. Ainda assim, essas ferramentas são limitadas e acompanhar os patches de código é outro problema que só está piorando – a Agência de Segurança Cibernética e Infraestrutura dos EUA geralmente relata centenas de novas vulnerabilidades de software por semana.

“Você não pode testar cada combinação de como cada bit de código pode ser executado”, diz Aidan McManus, um executivo de tecnologia aposentado que supervisionou a arquitetura e engenharia de TI na CA Technologies. “Levaria anos.”

Mats Heimdahl, chefe do Departamento de Ciência da Computação e Engenharia da Universidade de Minnesota, observa que Kangjie e seus pesquisadores também encontraram vários patches ruins no kernel que estavam separados dos bugs que enviaram. “A meu ver, é bastante claro que um processo de revisão manual por voluntários sobrecarregados e subestimados (mesmo por mantenedores extremamente qualificados e dedicados) inevitavelmente será imperfeito”, escreveu Heimdahl em um e-mail.

O fato de que as vulnerabilidades estão crescendo levanta questões fundamentais sobre como o código aberto será gerenciado. Embora acelere a inovação, é essencialmente um recurso compartilhado, uma vasta biblioteca de software de uso gratuito que economiza US$ 60 bilhões por ano aos consumidores e também aumenta os lucros das empresas ao reduzir seus custos de desenvolvimento. Pode haver simplesmente muitos free riders, com recursos insuficientes comprometidos com manutenção e segurança.

A proibição do kernel Linux da Universidade de Minnesota: limites aprendidos

Embora não haja nada que indique que a verificação de correções tenha mudado, a Linux Foundation está estabelecendo um conjunto de melhores práticas para pesquisadores que trabalham com o kernel e recomendou que a Universidade de Minnesota nomeasse um revisor para suas submissões. Não há realmente uma alternativa para revisão de código e a comunidade agora está fazendo um trabalho razoável para manter códigos maliciosos fora, diz Barcomb. Dada a autonomia necessária para o trabalho de conhecimento, ela diz, “o melhor que você pode fazer é ter processos para identificar violações de confiança e responder de acordo, na melhor das hipóteses, antes que as mudanças sejam incorporadas”.

Heimdahl observa que sua instituição está organizando um comitê para aconselhar sobre envios de patches enquanto aguarda a suspensão da proibição.

O Linux já foi uma ideia de fora, um contraponto ousado ao pensamento tradicional sobre software proprietário, mas evoluiu para algo que se parece muito mais com um projeto comercial. Huawei, Intel e Red Hat lideram as centenas de empresas que contribuem regularmente com código para o kernel Linux. Embora muitas dessas empresas também doem dinheiro para a Linux Foundation e afiliadas da Open Source Initiative, talvez seja hora de uma abordagem mais sistemática de suporte ao software para ajudar a melhorar a segurança daqui para frente - uma que valorize melhor os benefícios de tais sistemas de código aberto cruciais.

“As pessoas simplesmente assumem que o código aberto funciona”, diz Christopher Tozzi, professor sênior do Rensselaer Polytechnic Institute. “Há toda uma nova geração de pessoas que realmente não pensaram sobre essas questões.”