Contents

Aplicativos seguros em risco? Diga adeus ao C e ao C++!

/images/linguaggi-C-C-plusplus-sicurezza-memoria.jpg -Negócios -Vulnerabilidade

Linguagens de programação como C e C\+\+ , cuja introdução remonta aos anos 70 e 80, ainda são amplamente utilizadas porque são poderosas e flexíveis. Hoje, mais do que nunca, porém, os programas escritos em C/C\+\+ são frequentemente vulneráveis ​​devido a problemas no gerenciamento de memória.

A segurança da memória em aplicativos de software refere-se a uma série de ameaças e fraquezas potenciais que podem permitir que partes não autorizadas comprometam a operação adequada de tais programas, abrangendo cenários em que códigos prejudiciais são executados ou dados confidenciais são roubados.

Porque o uso de C e C\+\+ pode levar à criação de aplicativos inseguros

C e C++ oferecem controle direto sobre a alocação de memória, permitindo que os desenvolvedores gerenciem manualmente a alocação e desalocação de dados. Conforme discutido anteriormente neste artigo, uma série de cenários potencialmente perigosos podem surgir do manuseio inadequado de recursos de memória.

De qualquer forma, quaisquer erros buffer overflow podem ser explorados por invasores para sobrescrever partes críticas da memória; a manipulação de ponteiros para acesso direto à memória pode ser explorada para acessar áreas não alocadas da memória sem autorização ou interferir no conteúdo de outras áreas.

Embora muitas linguagens modernas forneçam verificações automáticas de memória, como a garbage collection , C e C\+\+ não fornecem nada semelhante, deixando a responsabilidade de gerenciar a memória para o usuário.

Sem falar que C e C\+\+ fornecem poucas ferramentas integradas de segurança: a verificação de código Depende principalmente dos esforços dos desenvolvedores e do uso de ferramentas de análise apropriadas.

Basta pensar que em 2019 a Microsoft ele disse que 70% das vulnerabilidades de software derivam justamente de problemas relacionados ao gerenciamento de memória. Em 2020, o Google chegou às mesmas conclusões ao revelar que 70% dos problemas de segurança no Chromium (e consequentemente em todos os navegadores derivados dele) têm a ver com memória.

EUA: deixe de lado o uso das linguagens C e C\+\+. Quais opções são preferíveis?

O Governo dos EUA, através do escritório responsável pela segurança cibernética nacional (ONCD, Office of the National Cyber ​​​​Director), publicou um documento aprofundado com o qual chama a atenção dos desenvolvedores de software. O relatório sugere orientar-se no uso de linguagens de programação que promovem o gerenciamento seguro de memória.

A responsabilidade da segurança de TI não deve estar apenas nas mãos de pequenas empresas e usuários individuais. Segundo a ONCD, porém, a responsabilidade recai precisamente sobre as maiores organizações, sobre as empresas tecnológicas e, em última análise, sobre o Governo.

Indicando linguagens como C e C\+\+ como intrinsecamente “inseguras”, a ONCD pediu às empresas e engenheiros de software que adotassem as melhores práticas possíveis a fim de reduzir a superfície de ataque possivelmente exposta aos invasores.

Criar código seguro para memória é possível orientando-se nas linguagens certas: Rust, Go, C# , Java, Swift, JavaScript e Ruby são os principais exemplos. Não é à toa que em primeiro lugar está Rust, uma linguagem que desenvolvedores Linux, engenheiros de software da Microsoft, programadores de navegadores como o Chromium/Chrome estão usando cada vez mais para reescrever o kernel dos sistemas operacionais e melhorar a segurança de partes críticas dos aplicativos. usado por milhões de usuários.

Anteriormente, investigamos várias fontes para explorar as implicações da utilização do Rust no projeto Chromium, bem como os benefícios potenciais associados à sua integração ao kernel do sistema operacional Windows 11. Além disso, examinaremos agora a trajetória dos esforços contínuos de desenvolvimento do kernel Linux.

Crédito da imagem de abertura: iStock.com – Manfort Okolie

barra lateral inferior relacionada 300

*️⃣ Link da fonte:

documento detalhado, Manfort Okolie,