Segurança na Linguagem C++: Uma Abordagem Intrínseca

A linguagem C++ é amplamente utilizada para o desenvolvimento de software de alto desempenho, sistemas embarcados e aplicações que requerem controle fino sobre os recursos de hardware. No entanto, essa flexibilidade e poder técnico têm um custo: vulnerabilidades de segurança inerentes ao modelo de gerenciamento de memória da linguagem.

Principais Riscos de Segurança em C++

Um dos problemas mais comuns em C++ é o buffer overflow, que ocorre quando um programa escreve mais dados em um buffer do que ele pode armazenar, potencialmente sobrescrevendo áreas da memória e permitindo a execução de código malicioso. Esse tipo de vulnerabilidade tem sido explorado em diversos ataques cibernéticos, incluindo worms e explorações de falhas em software crítico [Aleph One, 1996].

Outras vulnerabilidades incluem:

Uso de ponteiros não inicializados, que pode resultar em comportamento indefinido.

Uso de memória após liberação (use-after-free), permitindo acesso indevido a áreas de memória liberadas.

Fugas de memória, que ocorrem quando a memória alocada dinamicamente não é liberada corretamente.

A Nova Abordagem para a Segurança em C++

Historicamente, a responsabilidade pela segurança do código C++ tem sido atribuída aos desenvolvedores, que precisam gerenciar a memória manualmente. No entanto, grandes empresas tecnológicas têm adotado abordagens que incorporam mecanismos de segurança diretamente na linguagem e nas bibliotecas padrão.

O Google, por exemplo, tem investido significativamente na reescrita de partes críticas do Chrome e do Android para tornar o software mais seguro. Algumas das técnicas utilizadas incluem:

Verificação de limites de buffer: evita acessos indevidos a memória adjacente.

Inicialização obrigatória de variáveis: reduz erros provenientes de valores não inicializados.

Uso de smart pointers (std::unique_ptr e std::shared_ptr): facilita a gestão de memória e reduz riscos de vazamentos.

Essas soluções já demonstraram impacto positivo, tornando os produtos mais resilientes a ataques baseados em vulnerabilidades de memória [Barrett & Turner, 2021].

O Papel do Rust na Segurança do Software

Outra abordagem adotada por diversas empresas é a migração de partes críticas do código para Rust, uma linguagem projetada para evitar falhas de segurança com seu sistema de tipos seguro. Diferente do C++, Rust impede diversas vulnerabilidades ao restringir operações perigosas por padrão:

Ownership e borrowing: garantem segurança de memória sem necessidade de garbage collector.

Impossibilidade de acesso a ponteiros nulos: elimina classes inteiras de erros comuns em C++.

Prevenção de data races: protege contra condições de corrida em programas concorrentes.

A Microsoft e o Google têm experimentado a substituição de componentes escritos em C++ por Rust para aumentar a segurança de seus produtos [Microsoft Security Response Center, 2020].

Conclusão

A segurança em C++ continua sendo um desafio, mas a adoção de novas práticas e ferramentas tem reduzido significativamente os riscos. Desde melhorias na própria linguagem até a substituição por linguagens mais seguras como Rust, a indústria caminha para um futuro com software mais confiável e resiliente a ataques cibernéticos.

Referências Bibliográficas

Aleph One. (1996). Smashing the Stack for Fun and Profit. Phrack Magazine.

Barrett, D., & Turner, P. (2021). "Improving Memory Safety in Google Products." Google Security Blog.

Microsoft Security Response Center. (2020). "Why Rust for Secure Coding?" Microsoft Blog.

Stroustrup, B. (2013). The C++ Programming Language (4th Edition). Addison-Wesley.

Matsakis, N., & Klock, F. (2014). "The Rust Programming Language." ACM SIGPLAN Notices.

maniero ontem

A maioria desses problemas só ocorrem quando a pessoa usa o estilo C de programar que é possível em C++. Quando usa o jeito C++ de programar esses erros deixam de existir ou são minimizados. Tem ferramentas que ajudam não deixar isso acontecer e também ajudam ondicar onde mais tem ou pode ter erro.

Então, apesar de ser um pouco verdade que C++ tem uma tendência maior de permitir que o programador cause um erro no código, a insegurança é do programador, reforçada pelo fato que ele tem como não causar as maioria dos erros, mesmo os cometidos por distração, ou seja, ele não está usando a linguagem da maneira como deveria. Pode-se alegar que dá mais trabalho que outras linguagens, mas isso pode ser até relativo, tem quem diga que brigar com os macadores de tempo de vida de Rust dá muito trabalho.

O que a Google está fazendo agora é usar C++ certo.

De qualquer forma há discussões agora em regime de urgência para que a linguagem tenha mais garantias de segurnaça com padrão. Que bom ter concorrência. Vamos aguardar, mas eles sentiram a água batendo no pescoço.

E é importante diser que muitas vezes as pessoas adotam C++ onde ela não é necessária, isso já é um erro. Por outro lado muitas pessoas vão adotar outra solução, como Rust por exemplo, que não dá extamente o mesmo resultado de eficiência que C++ dá, mas isso, claro, depende de cada caso. Quando a pessoa pode usar Rust, talevz poderia usar outra coisa. O que eu não entendo é a pessoa acha que Rust é uma ótima substituta para Java, C#, Go e outras linguagens do tipo.

Zig é uma linguagem que as pessoas estão adorando agora e apesar de ser muito melhor que C (nenm tanto que C++ que não é a mesma intenção), tem problemas que levam a códigos inseguros e as pessoas não estão reclamando.

Além disso Carbon tem uma filososia bem interessante tentando realmente substituir o C++, por mantém certa compatibilidade com C++ e tem como objetivo secundário ter melhores opções para obter segurança, mas não é a prioridade agora. Isso é futurologia, mas se eles conseguirem fazer o que esão prometendo, e não tem gente ruim trabalhando nela, realmente será uma linguagem fenomenal, e só a proposta do Cpp2 faria o C++ sobreviver, ainda que dê para dizer que é outra linguagem, assim como C++ é outra linguagem em relação à C.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).