A Casa Branca exige linguagens de programação seguras para memória, mas o grupo ISO C++ diz que é apenas parte da solução
O ONCD (Escritório do Diretor Nacional Cibernético) dos EUA está se juntando ao coro de pessoas que exigem que os desenvolvedores usem linguagens de programação seguras para memória para “proteger a segurança de nossa nação” – embora alguns especialistas em linguagem C++ considerem que a segurança da memória é apenas uma pequena peça do quebra-cabeça da segurança.
A ONCD também teve como alvo os fornecedores de software que “não são suficientemente incentivados a dedicar recursos apropriados para práticas de desenvolvimento seguras” e os seus clientes que “não exigem software de maior qualidade porque não sabem como medi-lo”.
A estratégia está condensada num
novo relatório sobre o tema “um caminho para um software seguro e mensurável”. O relatório inclui um forte foco na segurança da memória e, em particular, uma declaração de que “o uso de linguagens seguras para a memória pode eliminar a maioria dos erros de segurança da memória”.
O relatório reconhece que “em algumas situações distintas, usar uma linguagem segura para a memória pode não ser viável”, usando como exemplo sistemas espaciais, onde linguagens com garbage collector não são suficientemente determinísticas. Rust tem as propriedades necessárias, diz o relatório, mas “ainda não foi comprovada em sistemas espaciais”.
O ONCD também aponta proteções de hardware, como
Memory Tagging in Arm chips, ou CHERI (Capability Hardware Enhanced RISC Instructions), um
projeto de pesquisa da SRI International e da Universidade de Cambridge, como possíveis soluções.
E quanto à mensurabilidade? O relatório tem mais perguntas do que respostas. “A mensurabilidade do software é um dos problemas de pesquisa abertos mais difíceis de resolver”, afirma. Os desafios incluem que a maioria dos softwares não possui uma estrutura uniforme, tornando a avaliação da qualidade subjetiva e dependente do contexto. Além disso, o comportamento do software nem sempre é determinístico; e a sua constante evolução faz com que as avaliações fiquem rapidamente desatualizadas. A conclusão é que a mensurabilidade do software é uma “prioridade de pesquisa”.
A ONCD solicitou comentários enquanto preparava o seu apoio, e estes estão
publicados aqui. A Rust Foundation, por exemplo, pede “requisitos de boas práticas para organizações com financiamento público e seus contratantes para usarem como padrão linguagens de programação seguras para memória, como Rust”. A Microsoft coloca o foco nas cadeias de fornecimento de software e na falta de investimento suficiente em código aberto. A IBM diz que reescrever software pode ser muito caro e promove formas de “proteger o software existente contra vulnerabilidades de segurança de memória”. O Google afirma que concorda com o governo que defende “a transição para linguagens e estruturas seguras de memória”. A AWS adota uma resposta diferenciada que “apoia totalmente a prática de escrever novos projetos em linguagens seguras para memória”, mas também que isso é “apenas um pequeno fator nos esforços gerais para melhorar a segurança do software de código aberto”, destacando que os desenvolvedores podem desabilitar os recursos que tornam o Rust seguro, por exemplo, e que erros lógicos podem acabar sendo “problemas de segurança maiores do que aqueles relacionados à segurança da memória”.
Uma resposta notável veio de um grupo que se descreve como “alguns membros seniores de C++ com décadas de experiência em ISO C++ (ISO/IEC SC22/WG21) atuando como o Grupo de Direções ISO C++”. O artigo deles diz que “a segurança da memória é uma parte muito pequena da segurança” e que “C++ se beneficia de ter uma especificação formal, um modelo de memória totalmente especificado e uma comunidade ativa de usuários e implementadores. Em contraste, algumas linguagens consideradas seguras carecem de uma especificação formal”, este último ponto talvez com Rust em mente. C++ é alvo injusto, eles consideram. “Muitas das críticas ao C++ baseiam-se em códigos escritos em estilos mais antigos, ou mesmo em C, que não utilizam as facilidades modernas destinadas a aumentar a segurança de tipos e recursos.”
Existem muitas outras maneiras de cometer erros de programação, dizem no artigo, incluindo erros lógicos, vazamentos de recursos, erros de simultaneidade, erros de tipo, erros de temporização, erros de terminação e muito mais. Eles favorecem uma melhor educação dos programadores C++ que “abordam as questões de segurança desde o início”.
The USA ONCD (Office of the National Cyber Director) is joining the chorus of people demanding that developers […]
devclass.com
www.tabnews.com.br
github.com
