Analistas dão as boas-vindas ao conselho da NSA para que desenvolvedores adotem linguagens com segurança de memória

Analistas de segurança receberam uma recomendação da Agência de Segurança Nacional dos EUA (NSA) na semana passada para desenvolvedores de software considerarem a adoção de linguagens como C#, Go, Java, Ruby, Rust e Swift para reduzir as vulnerabilidades relacionadas à memória no código.

A NSA as descreveu como linguagens de “memória segura” que gerenciam a memória automaticamente como parte da linguagem do computador. Eles não dependem do programador para implementar a segurança de memória e, em vez disso, usam uma combinação de tempo de compilação e verificações de tempo de execução para proteger contra erros de memória, disse a NSA.

O caso de linguagens com segurança de memória

O comunicado um tanto incomum da NSA de 10 de novembro apontou para linguagens amplamente usadas, como C e C++, como confiando demais em programadores não cometer erros relacionados à memória, que observou, continua a ser a principal causa de vulnerabilidades de segurança em software. Estudos anteriores - um por Microsoft em 2019 e outro de Google em 2020 relacionados ao seu navegador Chrome - por exemplo, ambos descobriram que 70% das vulnerabilidades eram problemas de segurança de memória, disse a NSA.

“Linguagens comumente usadas, como C e C++, fornecem muita liberdade e flexibilidade no gerenciamento de memória, ao mesmo tempo em que dependem fortemente do programador para realizar as verificações necessárias nas referências de memória”, disse a NSA. Isso geralmente resulta em vulnerabilidades exploráveis ​​vinculadas a erros simples, como erros de estouro de buffer, problemas de alocação de memória e condições de corrida.

C#, Go, Java, Ruby, Rust, Swift e outras linguagens seguras de memória não eliminam completamente o risco desses problemas, disse a NSA em seu comunicado. A maioria deles, por exemplo, inclui pelo menos algumas classes ou funções que não são seguras para a memória e permitem que o programador execute uma função de gerenciamento de memória potencialmente insegura. Às vezes, as linguagens seguras para memória também podem incluir bibliotecas escritas em linguagens que contêm funções de memória potencialmente inseguras.

Mas mesmo com essas ressalvas, linguagens seguras para memória pode ajudar a reduzir vulnerabilidades em software resultante de um gerenciamento de memória ruim e descuidado, disse a NSA.

Tim Mackey, principal estrategista de segurança do Synopsys Cybersecurity Research Center, acolhe a recomendação da NSA. O uso de linguagens com segurança de memória deveria, de fato, ser o padrão para a maioria dos aplicativos, diz ele. “Para fins práticos, confiar que os desenvolvedores se concentrem em questões de gerenciamento de memória em vez de programar novos recursos interessantes representa um imposto sobre a inovação”, diz ele. Com linguagens de programação seguras para memória e estruturas associadas, são os autores da linguagem que garantem o gerenciamento adequado da memória e não os desenvolvedores de aplicativos, diz Mackey.

Mudança pode ser desafiadora

Mudar um ambiente de desenvolvimento de software maduro de um idioma para outro pode ser difícil, reconheceu a NSA. Os programadores precisarão aprender o novo idioma e provavelmente haverá erros de novatos e acertos de eficiência durante o processo. A extensão da segurança de memória disponível também pode variar significativamente de acordo com o idioma. Alguns podem oferecer apenas segurança mínima de memória, enquanto outros oferecem proteções consideráveis ​​em relação ao acesso, alocação e gerenciamento de memória.

Além disso, as organizações precisarão considerar o quanto de compensação estão dispostas a fazer entre segurança e desempenho. “A segurança da memória pode custar caro em termos de desempenho e flexibilidade”, alertou a NSA. “Para idiomas com um nível extremo de proteção inerente, pode ser necessário um trabalho considerável para simplesmente compilar o programa devido às verificações e proteções.”

Existem inúmeras variáveis ​​em jogo ao tentar portar um aplicativo de um idioma para outro, diz Mike Parkin, engenheiro técnico sênior da Vulcan Cyber. “Na melhor das hipóteses, a mudança é simples e uma organização pode realizá-la de forma relativamente indolor”, diz Parkin. “Em outros, o aplicativo depende de recursos que são triviais no idioma original, mas exigem um desenvolvimento extenso e caro para serem recriados no novo.”

O uso de linguagens com segurança de memória também não substitui a necessidade de testes de software adequados, adverte Mackey. Só porque uma linguagem de programação é segura para a memória, não significa que a linguagem ou os aplicativos desenvolvidos nela estejam livres de bugs.

Mudar de uma linguagem de programação para outra é uma proposta arriscada, a menos que você tenha uma equipe que já entenda tanto a linguagem antiga quanto a nova, diz Mackey. “Essa migração é melhor realizada quando o aplicativo está passando por uma atualização de versão principal; caso contrário, existe a possibilidade de que bugs inadvertidos sejam introduzidos como parte do esforço de migração”, observa ele.

Mackey sugere que as organizações considerem o uso de microsserviços quando se trata de mudar de idioma. “Com uma arquitetura de microsserviços, o aplicativo é decomposto em um conjunto de serviços em contêineres”, diz Mackey. “Do ponto de vista de uma linguagem de programação, não há nada que exija inerentemente que cada microsserviço seja programado na mesma linguagem de programação que outros serviços dentro do mesmo aplicativo.”

Fazendo o movimento

Dados recentes da Statista mostram que muitos desenvolvedores já estão usando linguagens que são consideradas seguras para a memória. Quase dois terços (65.6%), por exemplo, usam JavaScript, quase metade (48.06%) usa Python, um terço usa Java e quase 28% usa C#. Ao mesmo tempo, uma proporção substancial ainda usa linguagens não seguras, como C++ (22.5%) e C (19.25%).

“Acho que muitas organizações já estão abandonando o C/C++ não apenas pelo problema de segurança da memória, mas também pela facilidade geral de desenvolvimento e manutenção”, diz Johannes Ullrich, reitor de pesquisa do SANS Technology Institute. “Mas ainda haverá bases de código herdadas que terão que ser mantidas por muitos anos.”

O comunicado da NSA ofereceu poucos insights sobre o que poderia ter motivado sua recomendação neste momento. Mas John Bambenek, principal caçador de ameaças da Netenrich, aconselha que as organizações não o ignorem. “Vulnerabilidades e ataques de memória têm sido difundidos desde a década de 1990, então, em geral, este é um bom conselho”, diz ele. “Dito isso, como vem da NSA, acredito que esse conselho deva ser mais urgente e está sendo conduzido pelo conhecimento que eles têm e nós não”.