Pixel mais seguro graças ao Rust: Google integra DNS no modem e reduz a superfície de ataque

O Google deu um passo notável na proteção de seus telefones Pixel ao integrar um analisador DNS escrito em Rust dentro do firmware do modem. Trata-se de uma decisão que não só reduz riscos concretos em uma peça crítica do stack de comunicações, mas também serve como experimento prático sobre o que significa levar linguagens com segurança de memória a camadas muito próximas do hardware.

Rust fornece garantias de segurança contra erros clássicos de memória, como transbordamentos de búfer ou acessos fora de faixa, que são precisamente as vulnerabilidades que muitas vezes permitem ataques remotos contra a baseband (o processador que gere as rádios celulares). Por isso, o Google escolheu implementar o parser DNS com uma biblioteca em Rust: o manejo de pacotes DNS é uma dependência fundamental das redes móveis modernas e, quando se faz com código que não protege a memória, pode se tornar uma porta de entrada para exploits.

A caixa de ferramentas que o Google tem vindo a disponibilizar sobre o modem não se limita ao Rust. Nos últimos anos, a empresa documentou o uso intensivo de sanitizadores para detectar comportamentos indefinidos em tempo de execução —herramientas como as que oferece o projeto LLVM/Clang permitem detectar sobreflujos e violações de limites durante o desenvolvimento — e outras medidas específicas para mitigar ataques sobre tecnologias antigas como 2G. Se você quer aprofundar em como esses sanitizadores funcionam, a documentação do LLVM é um bom ponto de partida: https://clang.llvm.org/docs/Sanitizers.html.

O objetivo técnico por trás desta migração é claro: diminuir a “superficie de ataque” que surge quando componentes críticos permanecem implementados em linguagens que permitem erros de memória. O Google afirmou que algumas vulnerabilidades reais em componentes de rede têm explorado precisamente acessos fora dos limites de memória; um exemplo identificado publicamente com sua entrada correspondente no catálogo de vulnerabilidades é CVE-2024-27227, que ilustra a classe de problemas que se tentam evitar com essas medidas.

Para implementar DNS no ambiente restrito do modem, o Google adaptou o crate Rust conhecido como "hickory-proto", um cliente/servidor/resolver DNS desenvolvido na comunidade Rust. A versão utilizada foi modificada para ser executada em ambientes “bare metal” e embebidos, o que implica alterar pressupostos habituais de um sistema operacional completo. A gestão de dependências introduzidas por esse crate foi facilitada, segundo a empresa, com uma ferramenta interna chamada “cargo-gnaw” que ajuda a resolver e manter mais de trinta dependências derivadas da integração.

A integração técnica seguiu um padrão de interoperabilidade pragmático: o Google declarou a interface de parsing de respostas DNS em C, e depois a implementou em Rust. De Rust é devolvido um código inteiro que representa o resultado da operação; quando é necessário atualizar as estruturas de dados em memória que já estão geridas pelo código C existente, a implementação em Rust invoca as funções C prévias para realizar essas modificações. Esta abordagem híbrida evita reescrever completamente a base de código C já validada e permite uma adoção incremental de código seguro por memória.

No entanto, a adoção de Rust em um firmware com recursos limitados também traz desafios. As crates de Rust nem sempre são projetadas para ambientes com restrições de tamanho de código e memória; por isso o Google sugere que uma otimização adicional pode ser alcançada através do uso de flags de característica que permitam compilar apenas os elementos necessários, reduzindo a pegada binária e a superfície exposta por código desnecessário.

Além do caso concreto do parser DNS, este trabalho faz parte de uma tendência mais ampla: a indústria do software embebido e do sistema operacional móvel está explorando e adotando cada vez mais linguagens e técnicas que limitam as classes de erros mais perigosas. Android, por exemplo, mantém documentação e guias sobre sua estratégia de adotar linguagens seguras em partes críticas do sistema: https://source.android.com/docs/security/memory-safety. E a própria linguagem Rust, que nasce com a segurança de memória como prioridade, explica em seu site por que esse modelo reduz muitos dos erros clássicos: https://www.rust-lang.org.

Que implicações práticas tem tudo isso para os usuários e para a indústria? No curto prazo, significa que dispositivos como o Pixel 10 podem resistir melhor tentativas de exploração que busquem comprometer o modem. No médio e longo prazo, a experiência de portar e operar componentes críticos em Rust fornecerá lições valiosas sobre interoperabilidade, gestão de dependências e otimização para ambientes restritos, e poderia acelerar que mais partes do sistema – tanto no Android como em outros produtos – migrem para código com garantias de segurança mais rigorosas.

Esta não é uma solução mágica, mas sim um avanço significativo: Reduzir classes inteiras de vulnerabilidades através de decisões de design de linguagem e arquitetura melhora a postura de segurança de um dispositivo de base. A chave agora será entender os custos de manutenção, os impactos no tamanho do firmware e as melhores práticas para combinar código Rust e C em componentes críticos sem introduzir novas fragilidades.

Se você se interessa ler sobre vulnerabilidades históricas da baseband e estudos de segurança em rádios celulares, bem como iniciativas técnicas do Google neste âmbito, você pode consultar entradas e recursos públicos da empresa e da comunidade de segurança: o blog de segurança do Google e a documentação Android são bons pontos de partida para aprofundar. Um exemplo de documentação oficial sobre segurança no Android está disponível em https://source.android.com/security, que recolhe relatórios e guias relacionados a este esforço.