Mais da metade dos projetos de código aberto contém código escrito em uma linguagem insegura para a memória, uma relatório da Agência de Segurança Cibernética e de Infraestrutura dos EUA encontrou. Memória insegura significa que o código permite operações que podem corromper a memória, levando a vulnerabilidades como estouros de buffer, uso após liberação e vazamentos de memória.
Os resultados do relatório, publicados em conjunto com o FBI, o Centro Australiano de Segurança Cibernética da Australian Signals Directorate e o Centro Canadense de Segurança Cibernética, são baseados na análise de 172 projetos críticos definidos pelo grupo de trabalho Securing Critical Projects do OpenSSF.
Do total de linhas de código para esses projetos, 55% foram escritas em uma linguagem insegura para memória, com os projetos maiores contendo mais. Linhas inseguras para memória compõem mais de um quarto de todos os 10 maiores projetos no conjunto de dados, enquanto a proporção mediana entre eles é de 62,5%. Quatro deles são compostos de mais de 94% de código inseguro para memória.
O que são linguagens que não são seguras para a memória?
Linguagens inseguras de memória, como C e C++, exigem que os desenvolvedores implementem manualmente práticas rigorosas de gerenciamento de memória, incluindo alocação e desalocação cuidadosas de memória. Naturalmente, erros serão cometidos, e estes resultam em vulnerabilidades que podem permitir que adversários assumam o controle de software, sistemas e dados.
Por outro lado, linguagens com segurança de memória, como Python, Java, C# e Rust, lidam automaticamente com o gerenciamento de memória por meio de recursos integrados e transferem a responsabilidade para o interpretador ou compilador.
VER: Os 10 melhores cursos de Python que vale a pena fazer em 2024
Os autores do relatório escreveram: “Vulnerabilidades de segurança de memória estão entre as classes mais prevalentes de vulnerabilidade de software e geram custos substanciais para fabricantes e consumidores de software relacionados a patches, resposta a incidentes e outros esforços”.
Eles também analisaram as dependências de software em três projetos escritos em linguagens com memória segura e descobriram que cada um deles dependia de outros componentes escritos em linguagens com memória insegura.
“Portanto, determinamos que a maioria dos projetos críticos de código aberto analisados, mesmo aqueles escritos em linguagens de segurança de memória, potencialmente contêm vulnerabilidades de segurança de memória”, escreveram os autores.
Chris Hughes, o consultor chefe de segurança da empresa de segurança de código aberto Endor Labs e pesquisador de inovação cibernética da CISA, disse à TechRepublic: “As descobertas certamente representam um risco tanto para organizações comerciais quanto para agências governamentais devido à exploração prevalente dessa classe de vulnerabilidades quando olhamos para a exploração anual entre classes de vulnerabilidades. Elas geralmente estão entre as classe de vulnerabilidades mais comumente explorada ano após ano.”
Por que o código que não protege a memória é tão prevalente?
Código inseguro para memória é prevalente porque dá aos desenvolvedores a capacidade de manipular diretamente o hardware e a memória. Isso é útil em casos em que as restrições de desempenho e recursos são fatores críticos, como em kernels e drivers de sistemas operacionais, criptografia e rede para aplicativos embarcados. Os autores do relatório observaram isso e esperam que continue.
Os desenvolvedores podem usar linguagens inseguras para a memória diretamente porque não estão cientes ou não se incomodam com os riscos. Eles também podem desabilitar intencionalmente os recursos seguros para a memória de uma linguagem segura para a memória.
No entanto, aqueles cientes dos riscos e que não desejam incorporar código inseguro para memória podem fazê-lo involuntariamente por meio de uma dependência em um projeto externo. Executar uma análise de dependência abrangente é desafiador por uma série de razões, tornando fácil para dependências inseguras para memória passarem despercebidas.
Por um lado, as linguagens frequentemente têm múltiplos mecanismos para especificar ou criar dependências, complicando o processo de identificação. Além disso, fazer isso é computacionalmente caro, pois algoritmos sofisticados são necessários para rastrear todas as interações e efeitos colaterais potenciais.
“Em algum lugar abaixo de cada pilha de linguagem de programação e gráfico de dependência, código inseguro para memória é escrito e executado”, escreveram os autores.
VER: Estudo da Aqua Security descobre aumento de 1.400% em ataques de memória
Hughes disse à TechRepublic: “Frequentemente, essas linguagens (inseguras para memória) foram amplamente adotadas e usadas por anos antes de muitas das atividades recentes para tentar encorajar a transição para linguagens seguras para memória. Além disso, há uma necessidade de que a comunidade de desenvolvimento mais ampla faça a transição para linguagens seguras para memória mais modernas.
“Seria difícil mudar muitos desses projetos para linguagens seguras de memória porque exigiria recursos e esforços dos mantenedores, para refatorar/reescrever para linguagens seguras de memória. Os mantenedores podem não ter experiência na linguagem segura de memória e, mesmo que tenham, podem não ser incentivados a fazê-lo, dado que são, em grande parte, voluntários não remunerados que não são compensados pelos projetos que criaram e mantiveram.”
Ele acrescentou que as organizações devem oferecer incentivos monetários e outros recursos para encorajar os desenvolvedores de código aberto a fazer a transição de seu código, mas também precisam monitorar todos os esforços para garantir que práticas de codificação seguras sejam implementadas.
Recomendações para reduzir riscos de código inseguro para a memória
O relatório refere-se a O caso da CISA para roteiros de segurança de memória documento e do Conselho Consultivo Técnico relatório sobre segurança de memória para recomendações sobre como reduzir a prevalência de línguas inseguras para a memória. Essas recomendações incluem:
- Transitar projetos existentes para linguagens com memória segura, pois avanços recentes significam que agora eles têm desempenho paralelo ao de linguagens com memória insegura.
- Escreva novos projetos em linguagens seguras para a memória.
- Crie roteiros de segurança de memória que incluam planos claros para integrar programação de segurança de memória em sistemas e abordar a segurança de memória em dependências externas.
- Gerencie dependências externas garantindo que bibliotecas e componentes de terceiros também sejam seguros em termos de memória ou tenham medidas de mitigação implementadas.
- Treine desenvolvedores em linguagens com memória segura.
- Priorizar a segurança no design de software desde o início do ciclo de vida do software, por exemplo, aderindo a Princípios de segurança por design.
Esforços de autoridades para reduzir a prevalência de códigos que não protegem a memória
Autoridades federais e pesquisadores nos EUA têm trabalhado para reduzir a quantidade de softwares com risco de memória em circulação nos últimos anos.
Um Relatório de outubro de 2022 do Consumer Reports observou que “aproximadamente 60 a 70 por cento das vulnerabilidades do navegador e do kernel — e bugs de segurança encontrados em bases de código C/C++ — são devidos à insegurança da memória”. Então, a Agência de Segurança Nacional divulgou orientações para como os desenvolvedores de software podem se proteger contra problemas de segurança de memória.
Em 2023, a diretora da CISA, Jen Easterly, apelou às universidades para educar os alunos sobre a segurança da memória e práticas de codificação seguras. Estratégia Nacional de Cibersegurança 2023 e seu plano de implementação foram então publicados, onde foram discutidos investir em linguagens seguras para a memória e colaborando com a comunidade de código aberto para defendê-los ainda mais. Em dezembro daquele ano, a CISA publicou O caso dos roteiros de segurança da memória e do Conselho Consultivo Técnico relatório sobre segurança de memória.
Em fevereiro deste ano, o A Casa Branca publicou um relatório promovendo o uso de linguagens seguras para a memória e o desenvolvimento de padrões de segurança de software, apoiados por grandes empresas de tecnologia, incluindo SAP e Hewlett Packard Enterprise.
Os esforços do governo dos EUA estão sendo apoiados por uma série de grupos terceirizados que compartilham seu objetivo de reduzir a prevalência de código inseguro para a memória. O OpenSSF Best Practices Working Group tem um dedicado Interesse especial em segurança de memória subgrupo, enquanto o Grupo de Pesquisa em Segurança da Internet Projeto Prossimo quer “mover a infraestrutura de software sensível à segurança da Internet para um código de memória segura”. O Google desenvolveu o OSS Fuzz serviço que testa continuamente software de código aberto em busca de vulnerabilidades de segurança de memória e outros bugs usando técnicas de fuzzing automatizadas.
