Fortalecendo as basebands celulares no Android
Os processadores “baseband” celulares do Android estão surgindo como um grande ponto fraco de segurança, já que executam firmware proprietário e opaco com acesso profundo ao hardware e, às vezes, à memória do sistema. Os comentaristas argumentam que as técnicas de hardening propostas pelo Google (sanitizers, toolchains mais seguras) são, no máximo, incrementais enquanto as basebands continuarem fechadas, mal isoladas via IOMMU e controladas por um pequeno oligopólio de fornecedores limitado por patentes e dinâmica regulatória. Vários apontam mudanças mais radicais — stacks de baseband FOSS, mover protocolos complexos como VoLTE/IMS para código auditável em userspace e isolamento de hardware mais rigoroso — como a única forma de limitar de maneira significativa o risco de comprometimento remoto.
Arquitetura da baseband e perfil de risco
- As basebands são processadores separados com seu próprio firmware e sistema operacional, muitas vezes tão poderosos quanto a CPU principal e amplamente opacos para o Google e para os usuários.
- A invasão do firmware da baseband pode permitir o comprometimento total do dispositivo se ela tiver acesso irrestrito à memória; alguns relatam uso real por agentes estatais para espionagem.
- Outros observam que o impacto depende da interconexão e do isolamento: algumas plataformas usam MMU/IOMMU, de modo que a execução de código na baseband expõe principalmente o tráfego de rádio e a localização, e não o sistema completo.
Isolamento, IOMMU e DMA
- Muitos comentaristas argumentam que o uso adequado da IOMMU e tratar a baseband como não confiável são mais importantes do que um fortalecimento incremental do compilador.
- Alguns telefones supostamente ligam as basebands diretamente à RAM do sistema ou ao PCI sem IOMMU, tornando a exploração “jogo encerrado”.
- Pixels e iPhones modernos são citados como exemplos em que IOMMU/MMU são usados para conter DMA, embora os detalhes e a completude disso sejam debatidos.
- Há defesa para executar drivers de baseband em VMs ou kernels isolados; outros observam que isso já ocorre em parte ou que restrições de hardware/tempo real complicam isso.
Ecossistema proprietário, patentes e “teatro da segurança”
- Há forte sentimento de que o firmware fechado da baseband, sem controle do usuário, é o problema central; “acesso remoto” com backdoors por parte de fornecedores é mencionado.
- O oligopólio de Qualcomm/Mediatek/Samsung e a política de patentes/pools são apontados como responsáveis pela falta de კონკorrência e pela lentidão nas melhorias de segurança.
- Alguns suspeitam de enfraquecimento deliberado sob pressão governamental; outros sugerem incompetência e incentivos desalinhados. Reconhece-se que as evidências são em grande parte circunstanciais.
- Vários veem o conselho de hardening do Google como útil, mas no fim limitado, um “teatro da segurança” sem basebands FOSS e isolamento verdadeiro.
Transferindo funcionalidades para fora da baseband
- Um fio argumenta que a solução real é parar de colocar pilhas complexas (IMS/VoLTE/VoWiFi, SIP, TCP/IP, DNS, análise de XML) dentro das basebands.
- Modelo proposto: implementar IMS/VoLTE/VoWiFi como aplicativos open source em userspace (exemplo: projeto IMS em Kotlin) com cooperação mínima de um modem “burro”.
- Isso é visto como uma melhoria em segurança, depuração e agilidade de recursos, embora alguns apontem restrições de tempo real e QoS, além de partes que ainda precisariam permanecer no modem.
Dispositivos, projetos e experimentos
- PinePhone/PinePhone Pro, SoCs não Qualcomm e alguns Pixels são discutidos como relativamente melhores para experimentação ou isolamento; outros questionam o suporte a IOMMU neles.
- Iniciativas de baseband aberta (por exemplo, Osmocom, imagens de modem do PinePhone) são mencionadas, mas os comentaristas dizem que os modems modernos 3G+/5G continuam em grande parte caixas-pretas seladas.