{"id":20461,"date":"2022-12-15T15:31:16","date_gmt":"2022-12-15T18:31:16","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=20461"},"modified":"2022-12-15T15:31:16","modified_gmt":"2022-12-15T18:31:16","slug":"the-long-road-to-memory-safety","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/the-long-road-to-memory-safety\/20461\/","title":{"rendered":"A longa jornada da manipula\u00e7\u00e3o segura de RAM"},"content":{"rendered":"

Em novembro de 2022, a Ag\u00eancia de Seguran\u00e7a Nacional dos EUA (NSA, na sigla em ingl\u00eas) emitiu um boletim<\/a> sobre a seguran\u00e7a do manuseio de RAM. Se voc\u00ea observar outros<\/a> boletins da NSA sobre o assunto, notar\u00e1 que eles se concentram principalmente na criptografia de dados ou na prote\u00e7\u00e3o do loop de produ\u00e7\u00e3o e em outras quest\u00f5es organizacionais. Abordar os desenvolvedores de software diretamente \u00e9 um movimento bastante incomum para a ag\u00eancia. Mas, considerando que foi feito, \u00e9 porque claramente trata-se de um tema particularmente importante. De forma geral, a NSA est\u00e1 sugerindo fortemente aos desenvolvedores de software que mudem para linguagens de programa\u00e7\u00e3o cuja arquitetura implique maior seguran\u00e7a ao trabalhar com mem\u00f3ria. E, de fato, parem de usar C e C++. Caso contr\u00e1rio, \u00e9 recomend\u00e1vel que um conjunto de medidas seja implementado para testar os softwares quanto a vulnerabilidades e evitar sua explora\u00e7\u00e3o.<\/p>\n

Para os programadores, essas s\u00e3o coisas bastante \u00f3bvias, e o alerta da NSA n\u00e3o \u00e9 dirigido a eles, mas sim \u00e0s ger\u00eancias ou aos representantes comerciais. Foi elaborado em linguagem did\u00e1tica para as empresas. Vamos tentar analisar os argumentos apresentados sem ser muito t\u00e9cnicos.<\/p>\n

Seguran\u00e7a da mem\u00f3ria<\/h2>\n

Vamos abrir nosso \u00faltimo relat\u00f3rio<\/a> sobre a evolu\u00e7\u00e3o das amea\u00e7as para o terceiro trimestre de 2022 e dar uma olhada nas vulnerabilidades mais usadas em ciberataques. Na primeira linha ainda est\u00e1 a vulnerabilidade CVE-2018-0802<\/a> no componente Equation Editor do Microsoft Office, descoberta em 2018. \u00c9 causada pelo processamento incorreto de dados na RAM, como resultado da abertura de um documento malicioso do Microsoft Word levar ao lan\u00e7amento de c\u00f3digo arbitr\u00e1rio. Outra vulnerabilidade popular entre os criminosos \u00e9 a CVE-2022-2294<\/a> no componente WebRTC do navegador Google Chrome. Isso leva \u00e0 execu\u00e7\u00e3o de c\u00f3digo arbitr\u00e1rio como resultado de um erro de estouro de buffer<\/a>. Outra vulnerabilidade \u2013 CVE-2022-2624<\/a> \u2013 contida na ferramenta de visualiza\u00e7\u00e3o de PDF do Chrome, tamb\u00e9m pode levar ao estouro do buffer.<\/p>\n

Obviamente, nem todas as vulnerabilidades de software s\u00e3o causadas pelo uso inseguro da RAM, mas muitas delas s\u00e3o. O NSA Bulletin cita as estat\u00edsticas da Microsoft de que os erros de manipula\u00e7\u00e3o de mem\u00f3ria causam 70% das vulnerabilidades descobertas.<\/p>\n

De acordo com as estat\u00edsticas da Microsoft, dois ter\u00e7os das vulnerabilidades ocorrem em decorr\u00eancia de bugs na mem\u00f3ria. <a href=\"https:\/\/github.com\/Microsoft\/MSRC-Security-Research\/blob\/master\/presentations\/2019_02_BlueHatIL\/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf\" target=\"_blank\">Fonte<\/a>.

De acordo com as estat\u00edsticas da Microsoft, dois ter\u00e7os das vulnerabilidades ocorrem em decorr\u00eancia de bugs na mem\u00f3ria. Fonte<\/a>.<\/p><\/div>\n

Por que isso acontece? Se a quest\u00e3o dos vazamentos de mem\u00f3ria \u00e9 t\u00e3o s\u00e9ria, por que n\u00e3o podemos de alguma forma \u201cparar\u201d de escrever c\u00f3digo vulner\u00e1vel? A raiz do problema \u00e9 o uso das linguagens de programa\u00e7\u00e3o C e C++. Sua arquitetura d\u00e1 aos desenvolvedores muita liberdade para trabalhar com RAM. Mas junto com a liberdade vem a responsabilidade. Os programadores de C\/C++ precisam implementar mecanismos para a escrita e leitura segura de dados. Ao mesmo tempo, linguagens de programa\u00e7\u00e3o de alto n\u00edvel como C#, Rust, Go e outras j\u00e1 cuidam disso. O ponto \u00e9 que, ao compilar o c\u00f3digo-fonte do programa, os meios de manipula\u00e7\u00e3o segura da mem\u00f3ria s\u00e3o introduzidos automaticamente e os desenvolvedores n\u00e3o precisam perder tempo com isso. Rust usa ainda mais meios para melhorar a seguran\u00e7a, at\u00e9 restringir a compila\u00e7\u00e3o de c\u00f3digos potencialmente perigosos, enquanto exibe um erro para o programador.<\/p>\n

\u00c9 claro que simplesmente desistir de usar C\/C++ n\u00e3o \u00e9 vi\u00e1vel enquanto essas linguagens permanecerem indispens\u00e1veis \u200b\u200bpara certas tarefas, como quando o c\u00f3digo \u00e9 necess\u00e1rio para MCUs ou outros dispositivos com s\u00e9rias limita\u00e7\u00f5es de poder de computa\u00e7\u00e3o e tamanho de mem\u00f3ria. Outras coisas sendo iguais, linguagens de programa\u00e7\u00e3o de alto n\u00edvel podem levar \u00e0 cria\u00e7\u00e3o de programas com uso intensivo de recursos. Mas as estat\u00edsticas de amea\u00e7as comuns nos mostram que os ataques visam com mais frequ\u00eancia software de usu\u00e1rio comum (como navegadores e editores de texto), que s\u00e3o executados em computadores muito poderosos (em compara\u00e7\u00e3o com MCUs, \u00e9 claro).<\/p>\n

Voc\u00ea n\u00e3o pode simplesmente mudar a linguagem de programa\u00e7\u00e3o<\/h2>\n

A NSA est\u00e1 bem ciente disso. Um enorme banco de dados de software escrito em linguagens de programa\u00e7\u00e3o \u201cinseguras\u201d n\u00e3o pode ser transferido para outra linguagem da noite para o dia. Mesmo se estivermos falando sobre escrever um produto de software do zero, pode haver uma equipe estabelecida, infraestrutura e m\u00e9todos de desenvolvimento em torno de uma linguagem de programa\u00e7\u00e3o espec\u00edfica.<\/p>\n

Se voc\u00ea quiser uma analogia, imagine ser convidado a sair de sua casa s\u00f3 porque ela foi constru\u00edda h\u00e1 muito tempo. Voc\u00ea sabe que a estrutura est\u00e1 perfeitamente s\u00f3lida, e que s\u00f3 iria desabar com um grande terremoto e, al\u00e9m disso, voc\u00ea est\u00e1 acostumado a morar l\u00e1. A equipe de desenvolvedores do Google Chrome tem uma postagem<\/a> que afirma explicitamente que eles n\u00e3o podem agora mudar para outra linguagem de programa\u00e7\u00e3o (neste caso, Rust) na qual a seguran\u00e7a est\u00e1 incorporada \u00e0 arquitetura. Pode ser poss\u00edvel no futuro. Mas, por agora, eles precisam de outras solu\u00e7\u00f5es.<\/p>\n

A mesma publica\u00e7\u00e3o dos desenvolvedores do Google Chrome tamb\u00e9m explica os motivos pelos quais voc\u00ea n\u00e3o pode alterar fundamentalmente a seguran\u00e7a do c\u00f3digo C\/C++. Essas linguagens de programa\u00e7\u00e3o simplesmente n\u00e3o foram projetadas para resolver todos os problemas de compila\u00e7\u00e3o de uma s\u00f3 vez. \u00c9 por isso que o boletim da NSA menciona dois conjuntos de medidas como alternativa:<\/p>\n