A CISA analisou projetos C/C++ e encontrou muitos códigos C/C++. Quer refazer alguma coisa em Rust?

A Agência de Segurança Cibernética e de Infraestrutura (CISA) do governo dos EUA analisou 172 projetos críticos de código aberto e descobriu que mais da metade contém código escrito em linguagens como C e C++ que não são naturalmente seguras para a memória.

Além disso, projetos escritos em linguagens de memória segura ainda podem estar expostos a vulnerabilidades de memória por meio de dependências inseguras. A descoberta da agência é detalhada em um relatório intitulado “Explorando a segurança da memória em projetos críticos de código aberto”.

Emitido esta semana pela CISA, 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, o relatório apóia uma iniciativa de Cinco Olhos nações para que organizações do setor público e privado reduzir o número de vulnerabilidades de software decorrentes de bugs de segurança de memória.

“Linguagens inseguras de memória exigem que os desenvolvedores gerenciem adequadamente o uso e a alocação de memória”, o relatório descobre. “Erros, que inevitavelmente ocorrem, podem resultar em vulnerabilidades de segurança de memória, como estouros de buffer e uso após liberação. A exploração bem-sucedida desses tipos de vulnerabilidades pode permitir que adversários assumam o controle de software, sistemas e dados.”

Linguagens seguras para memória, como C#, Go, Java, Python, Rust e Swift, cuidam do gerenciamento de memória para o desenvolvedor, reduzindo a oportunidade de cometer erros de memória.

Em dezembro de 2023, a CISA, com a ajuda da NSA, do FBI e das autoridades de segurança cibernética da Austrália, Canadá, Reino Unido e Nova Zelândia, publicou um papel intitulado “O caso dos roteiros de segurança da memória”. O relatório do projeto de código aberto da CISA segue esse roteiro e se alinha com a Estratégia Nacional de Segurança Cibernética da América para 2023.

Erros de segurança de memóriacomo estouros de buffer, uso de memória não inicializada, confusão de tipos e falhas de uso após liberação, têm sido motivo de preocupação na comunidade técnica há anos. Eles são comumente o resultado de erros de programação em código C/C++ e são responsáveis ​​pela maioria das vulnerabilidades em grandes bases de código.

O lançamento estável de 2015 do Rust, uma linguagem com fortes garantias de segurança de memória, deu às empresas de tecnologia uma linguagem de sistemas não alinhada que elas poderiam usar para evitar problemas com código inseguro de memória. As implicações competitivas da adoção de linguagens com fortes associações corporativas, como C# (Microsoft), Go (Google), Swift (Apple) ou Java (Oracle) podem ter ajudado a tornar o Rust mais atraente. Mas levou alguns anos para o Rust amadurecer e pegar.

A Microsoft tem sido contemplando as virtudes da Rust desde pelo menos 2019. Mas a linguagem de programação realmente decolou em 2021, com a formação da Rust Foundation, apoiada pelos membros fundadores AWS, Huawei, Google, Microsoft e Mozilla.

A comunidade C++, em resposta à confusão sobre linguagens com segurança de memória como Rust, está tentando permitir que os desenvolvedores escrevam códigos mais seguros por meio de Perfis C++que fornecem garantias de segurança em tempo de compilação. Nem todos concorda que C++ está à altura do desafio.

Seja qual for o caso, o Google e a Microsoft fizeram questão de avançar em direção a linguagens seguras para a memória, inicialmente para novos projetos e ultimamente para reescritas de aplicativos. O Google, por exemplo, no início deste ano disse que suas equipes de desenvolvimento Rust estão duas vezes mais produtivo como suas equipes C++.

Ao mesmo tempo, os desenvolvedores que trabalham com o projeto Prossimo têm reescrito bibliotecas críticas de código aberto em Rust para reduzir o risco de falhas de memória no código legado. Ainda esta semana, vamos criptografar disse ele foi implantado ntpd-rs, Reescrita Rust de Prossimo do daemon Network Time Protocol (NTP). Mas, como mostra o relatório da CISA, ainda há muito trabalho a fazer.

O relatório da CISA analisou 172 estudos de caso em uma lista de projetos críticos compilada pela Open Source Security Foundation. Foi encontrada:

• 52% dos projetos contêm código escrito em uma linguagem que não é segura para a memória.
• 55% do total de linhas de código (LoC) de todos os projetos foram escritas em uma linguagem que não é segura para a memória.
• Os maiores projetos são desproporcionalmente escritos em linguagens que não são seguras para a memória. Dos dez maiores projetos em total de linhas de código, cada um tem uma proporção de LoC inseguro de memória acima de 26%. A proporção média de uso de linguagens não seguras para memória nos dez projetos é de 62,5% e quatro das dez proporções de projetos excedem 94%.
  
• A análise de dependência de três projetos escritos em linguagens com memória segura demonstrou que cada um deles dependia de outros componentes escritos em linguagens com memória insegura.

Os projetos avaliados incluem: Chromium, Gecko, KVM, Linux, LLVM, GCC, JDK, Node e muitos outros.

O kernel Linux, entre os maiores projetos, “predominantemente usa linguagens inseguras para memória”, diz o relatório. “Alguns outros grandes projetos (frameworks de navegador web Chromium e Gecko) usam linguagens inseguras para memória para aproximadamente metade de seu código.”

Linux começou a incorporar código Rust em dezembro de 2022.

E embora a CISA tenha admitido no seu relatório que mesmo projectos em linguagens seguras de memória podem ser vulneráveis ​​a bugs de segurança de memória, principalmente através de dependências, concluiu instando as pessoas a considerarem reescrever o seu código crítico não seguro:

Gunnar Braun, gerente técnico do Synopsys Software Integrity Group, disse O registro que é importante aumentar a conscientização sobre a segurança da memória como um meio de tornar o software mais seguro.

“A segurança da memória deve ser uma das principais considerações ao decidir sobre uma linguagem de programação”, disse Braun. “O relatório e seu precedente ‘Case for Memory Safe Roadmaps’ trazem isso para executivos de nível C – onde ele pertence. A segurança e a proteção do software não são mais uma preocupação puramente técnica.”

Braun disse que o relatório observa que muitos desses programas de código aberto são executados em sistemas embarcados com restrições estritas de recursos. Se não for possível mudar as linguagens de programação, disse ele, então isso torna ainda mais importante empregar análise estática de código e ferramentas de difusão para mitigar os riscos de segurança da memória.

“Algumas linguagens seguras para memória, como Rust ou Go, já estão entrando em sistemas embarcados, então estou otimista de que C/C++ será amplamente substituído um dia – mas não hoje, e não amanhã”, disse ele. “Até chegarmos lá, a análise estática de código e as ferramentas de difusão serão tão importantes como sempre foram, se não mais.” ®