Como o código C++ de código aberto pode introduzir riscos de segurança

Bibliotecas e frameworks de código aberto são uma ótima maneira de dar início a projetos de desenvolvimento. O código aberto permite que desenvolvedores façam coisas incríveis sem reinventar a roda nem desenvolver soluções para problemas que já foram resolvidos.

No entanto, adicionar qualquer código a um projeto traz o risco inerente de introduzir vulnerabilidades potenciais que podem ter chegado até ele por erro ou má intenção.

Este artigo explora como o código aberto introduz vulnerabilidades na cadeia de suprimentos de software. Também mostra como identificar vulnerabilidades de segurança em código C++ de código aberto usando scanners automatizados de vulnerabilidades.

Como o código aberto introduz riscos de segurança

O ecossistema de software de código aberto é profundamente interconectado. Quando você instala um componente de código aberto no seu código, ele vem com dependências. É difícil acompanhar continuamente os problemas de segurança que cada dependência pode conter, e nem sempre dá para contar com os mantenedores dos pacotes para corrigir essas vulnerabilidades a tempo. Isso significa que pode haver vulnerabilidades não corrigidas nos pacotes de código aberto presentes na sua base de código.

Dados de uma pesquisa recente da Snyk e da Linux Foundation mostram que o tempo necessário para corrigir vulnerabilidades em projetos de código aberto aumentou de forma constante, passando de 49 dias em 2018 para 110 dias em 2021. Corrigir vulnerabilidades em projetos de código aberto leva quase 20% mais tempo (18,75%) do que em projetos proprietários. Devido a essas complexidades, aplicações de código aberto com vulnerabilidades conhecidas são alvos atraentes para hackers.

Vulnerabilidades de estouro de buffer são comuns em linguagens de programação de baixo nível, como C e C++, porque cabe aos desenvolvedores alocar a memória. C e C++ não protegem a aplicação contra clientes que acessam ou gravam dados além dos limites definidos de um buffer, o que deixa projetos de código aberto em C++ vulneráveis. Em aplicações sem gerenciamento adequado de memória, invasores podem explorar essa vulnerabilidade e inserir código executável no programa.

Por exemplo, considere o bug do Glibc encontrado na biblioteca libresolv da GNU C Library. O bug expunha o Glibc a ataques de estouro de buffer quando a função de biblioteca getaddrinfo era usada.

Um invasor pode explorar essa vulnerabilidade induzindo um cliente a procurar um domínio malicioso. Em seguida, pode retornar um payload que aciona o bug. Se o cliente tiver privilégios de root, isso pode comprometer o sistema e levar a um ataque man-in-the-middle. O Glibc é usado em milhões de sistemas que utilizam o kernel Linux, portanto, qualquer sistema que execute uma versão do Glibc com essa vulnerabilidade pode ser afetado.

O que é uma cadeia de suprimentos de software?

Tradicionalmente, o termo “cadeia de suprimentos” é usado na indústria de manufatura. Por exemplo, uma fabricante de carros pode usar algumas peças produzidas internamente e comprar outras de empresas diferentes. Isso significa que, antes de um carro chegar ao seu proprietário, muitas pessoas, usando ferramentas distintas, terão trabalhado nele.

No software, a cadeia de suprimentos funciona de forma semelhante. A cadeia de suprimentos de software inclui tudo o que entra no seu código ou interage com ele, do desenvolvimento à implantação. Isso inclui o código e os binários, os desenvolvedores que trabalharam no projeto e os repositórios nos quais ele é implantado. Também abrange ferramentas de compilação, scripts de empacotamento e infraestrutura da aplicação. A segurança da cadeia de suprimentos é fundamental.

Como a cadeia de suprimentos de software é composta por muitos elementos, ela pode se tornar bastante complexa. Hackers gostam de tirar proveito dessa complexidade.

Vulnerabilidades na cadeia de suprimentos de software

Em um ataque à cadeia de suprimentos de software, agentes maliciosos usam componentes upstream conectados ao alvo do ataque para obter acesso. Eles também podem atacar os serviços que distribuem ou executam o software. Nesse caso, esses componentes upstream não são necessariamente o alvo do ataque: são apenas um meio de obter acesso.

Os três principais alvos em uma cadeia de suprimentos são dependências, pipelines e dependências de pipelines.

Dependências

Invasores têm como alvo as dependências de código aberto que os desenvolvedores incorporam ao criar aplicações. Se um invasor inserir malware em um pacote comum de código aberto explorando uma vulnerabilidade conhecida, as aplicações de software que o instalarem como dependência ficarão expostas. Como as aplicações de software podem ter mais de uma dependência que contém outras dependências, é difícil rastrear possíveis vulnerabilidades. Isso torna as dependências alvos fáceis.

Pipelines

Em um ataque a pipelines, usuários mal-intencionados têm como alvo o pipeline de integração e entrega contínuas (CI/CD), pois ele oferece uma ampla superfície de ataque. Ele pode dar acesso a configurações padrão, credenciais de segurança, bancos de dados e código proprietário. Assim, quando invasores inserem código malicioso em um pipeline de CI/CD e o comprometem, podem criar uma porta dos fundos nas aplicações que o utilizam.

Dependências de pipelines

Invasores também podem ter como alvo dependências de pipelines para obter acesso a um ambiente de compilação. Por exemplo, os agentes maliciosos envolvidos na violação da Codecov usaram as credenciais de uma imagem Docker para atualizar um script de upload em bash. Eles modificaram o script para enviar a si mesmos as variáveis de ambiente dos usuários da Codecov.

Como identificar vulnerabilidades em dependências de código aberto

Embora o código aberto possa apresentar problemas próprios, ele ainda permite que desenvolvedores façam coisas incríveis e aproveitem o trabalho de outras pessoas. Mas os desenvolvedores precisam conseguir identificar vulnerabilidades e avaliar a qualidade do código aberto usado em seus projetos. No entanto, para a maioria das organizações, não é viável dedicar os recursos necessários à revisão manual de código e à auditoria do código aberto antes de usá-lo.

Seria difícil detectar vulnerabilidades como estouros de buffer, ponteiros nulos, estouros e subestouros de inteiros, entre outras, em cada dependência C/C++ da cadeia de suprimentos. Por exemplo, uma vulnerabilidade de ponteiro nulo em um trecho de código aberto C/C++ usado na cadeia de suprimentos de software pode ser explorada por hackers e causar uma falha. Não importa se o código da aplicação não tem vulnerabilidades: as vulnerabilidades no código aberto tornam a aplicação insegura.

Os dois principais métodos para identificar vulnerabilidades em dependências de código aberto são criar uma cadeia de suprimentos de software segura, em que cada etapa conte com um participante confiável, e usar scanners automatizados de vulnerabilidades, como o Snyk para C/C++.

Como criar uma cadeia de suprimentos de software segura

Acompanhar cada participante da cadeia de suprimentos e garantir que seja confiável é uma boa solução na teoria, mas extremamente difícil de implementar. A cadeia de suprimentos de software inclui muitos desenvolvedores responsáveis por várias bibliotecas e componentes usados em uma aplicação.

Scanners automatizados de vulnerabilidades, como o Snyk para C/C++

Uma solução mais prática é analisar o código aberto em busca de vulnerabilidades de segurança. No entanto, fazer essas análises manualmente pode consumir muito tempo e estar sujeito a erros. A prática recomendada é analisar o código aberto C++ com um scanner automatizado de vulnerabilidades, como o Snyk.

Com o Snyk Open Source, os desenvolvedores têm visibilidade do código aberto C++ que estão usando. A CLI do Snyk converte os arquivos em assinaturas digitais — ou hashes — que são comparadas com os bancos de dados da Snyk para gerar uma lista de componentes de código aberto correspondentes. Os desenvolvedores podem identificar vulnerabilidades comparando essa lista com a Snyk Vulnerability Database.

Ao contrário de outros scanners de vulnerabilidades, que analisam arquivos individualmente, o Snyk considera o contexto dos arquivos. Com arquivos auxiliares, como arquivos readme e scripts de instalação, o Snyk reduz o número de alertas de vulnerabilidade falsos positivos. Isso diminui o ruído e ajuda os desenvolvedores a se concentrarem no que precisa ser corrigido.

Depois que uma vulnerabilidade é identificada, o Snyk notifica os desenvolvedores no IDE ou na CLI e identifica automaticamente a atualização mínima necessária para corrigir a vulnerabilidade sem afetar o restante do código.

Conclusão

A popularidade do software de código aberto está crescendo. Com isso, mais aplicações contêm mais bibliotecas e componentes de terceiros, escritos e mantidos por pessoas desconhecidas. Como essas bibliotecas estão disponíveis em repositórios públicos, invasores podem explorar as menos seguras para obter acesso.

Para evitar vulnerabilidades ao trabalhar com código aberto em projetos C++, use um scanner automatizado de vulnerabilidades, como o Snyk Open Source. Com ele, você pode analisar projetos C++ de código aberto na sua aplicação em busca de vulnerabilidades, identificar bibliotecas maliciosas e proteger seu software contra comprometimentos.

Acesse a documentação do Snyk para C/C++ para saber como analisar seus projetos C/C++.