Pesquisa em serviços de dados MSM identificou uma vulnerabilidade no manipulador qmi_voicei_srvcc_call_config_req, acessível por processos Android privilegiados com permissão para falar com o modem.
| Componente | Serviço de voz do modem Qualcomm MSM, no manipulador qmi_voicei_srvcc_call_config_req da interface QMI. |
| Vetor | Mensagem QMI em formato TLV enviada a partir do processador de aplicação Android por usuários ou serviços privilegiados autorizados pela política SELinux. |
| Impacto | Sobrescrita de heap no modem, reinicialização do modem e possibilidade condicionada de controle do modem a partir do Android. |
| Prioridade | Restringir o acesso aos serviços QMI, revisar permissões SELinux de usuários privilegiados e aplicar atualizações de firmware ou segurança fornecidas pelo fabricante do dispositivo. |
| Artefatos | QMI, SMD, QuRT, QDSP6, libqmiservices.so, libqmi_cci.so, serviço Voice e mensagens TLV. |
| Superfície | Dispositivos Android baseados em SoCs Qualcomm MSM nos quais serviços QMI do modem ficam expostos ao núcleo de aplicação Linux. |
Uma pesquisa sobre serviços de dados Qualcomm MSM identificou uma falha de corrupção de memória em um serviço de voz do modem acessado por QMI, protocolo proprietário usado para comunicação entre componentes do modem e outros subsistemas do chip. O problema foi localizado no manipulador qmi_voicei_srvcc_call_config_req, associado ao serviço Voice, após fuzzing orientado por emulação de código QDSP6. A vulnerabilidade ocorre no processamento de uma mensagem em formato TLV que descreve contextos de chamada; o manipulador interpreta parte do conteúdo sem impor um limite máximo adequado para a quantidade de entradas recebidas. Como consequência, dados controlados pelo remetente podem ultrapassar a área alocada no heap do modem.
O ponto central do risco não está no acesso direto por qualquer aplicativo comum. O Android protege os serviços MSM por política SELinux, e aplicações de terceiros normalmente não têm autorização para usar QMI. Ainda assim, o contexto técnico mostra que usuários e componentes privilegiados, incluindo rádio, mídia e outros serviços com permissões elevadas, podem alcançar o serviço vulnerável. Em um cenário de comprometimento prévio de um processo com esse nível de acesso, a falha cria um caminho para atacar o modem a partir do processador de aplicação, com impacto potencial sobre a integridade do firmware em execução no ambiente QuRT.
O modem MSM é executado sob o sistema operacional em tempo real Qualcomm QuRT, cuja integridade é protegida por TrustZone e que não pode ser depurado ou extraído diretamente mesmo em dispositivos Android com root. Por isso, a interface QMI representa uma fronteira de ataque importante: ela é um canal legítimo de mensagens entre o Android e serviços do modem, mas também expõe manipuladores escritos por diferentes autores e com graus variados de robustez no tratamento de entradas. A falha encontrada demonstra que mensagens internas, mesmo quando destinadas a componentes privilegiados, precisam ser tratadas como dados não confiáveis.
QMI usa um modelo cliente-servidor no qual serviços registram manipuladores em QuRT e aguardam requisições em filas internas. No lado Android, bibliotecas como libqmiservices.so descrevem objetos de serviço e estruturas de mensagens, enquanto funções de libqmi_cci.so enviam requisições codificadas. Em muitos casos, o framework QMI converte o TLV recebido para estruturas C e executa validações de integridade durante o processo de decodificação. Essa centralização reduz erros de formatação, porque o código comum rejeita inconsistências antes que o manipulador específico trabalhe sobre os campos.
A vulnerabilidade aparece justamente em um caminho que não segue esse padrão defensivo. O manipulador qmi_voicei_srvcc_call_config_req processa diretamente o TLV recebido em vez de depender do framework para transformar a mensagem em uma estrutura validada. Quando encontra um pacote TLV de determinado tipo, a função aloca uma região fixa no heap do modem, lê do conteúdo recebido a quantidade de chamadas e passa a copiar os contextos de chamada para dentro desse buffer. A ausência de checagem de limite sobre o contador permite que uma mensagem criada para exceder a quantidade esperada faça o laço escrever além da área reservada.
Cada contexto de chamada contém campos de um byte e uma área cujo tamanho também deriva da entrada recebida. Isso dá ao remetente influência relevante sobre parte do padrão de escrita, inclusive com a capacidade de contornar proteções de heap baseadas em canários ao avançar sobre bytes intermediários. O material analisado demonstrou que uma mensagem TLV anômala pode sobrescrever dados logo após a alocação e provocar reinicialização do modem. A exploração completa não foi detalhada no material analisado, mas o efeito técnico confirmado é uma sobrescrita de heap no ambiente do modem, com potencial de ser usada como primitiva para controle mais amplo caso outras condições de exploração sejam satisfeitas.
A descoberta foi obtida com uma abordagem de fuzzing fora do dispositivo. O modem ELF foi reconstruído a partir de segmentos extraídos de firmware, incluindo partes compactadas por algoritmos proprietários que precisaram ser descomprimidas para análise. Em seguida, trechos do código de serviços foram carregados em um ambiente QEMU com suporte à arquitetura Hexagon/QDSP6, usando QuRT adaptado para prover chamadas de sistema e suporte básico de execução. Essa estratégia não reproduz todo o estado real do modem, porque vários segmentos de dados não estavam inicializados como no dispositivo, mas permite alcançar o início dos manipuladores, onde a maior parte do parsing de mensagens acontece.
A superfície envolve dispositivos Android com SoCs Qualcomm MSM nos quais o processador de aplicação Linux consegue conversar com serviços QMI do modem. Em chips modernos, o transporte primário citado é o SMD, usado como mecanismo de memória compartilhada entre o Android e o subsistema de modem. O SoC SM8150, usado como referência no contexto da pesquisa, exportava cerca de quarenta serviços QMI, e outros modelos ou fabricantes podem expor serviços adicionais. OEMs também podem adicionar serviços próprios além dos fornecidos pela Qualcomm, ampliando a diversidade de código acessível por esse canal.
O serviço vulnerável está no domínio Voice, e a função afetada processa uma mensagem de configuração relacionada a chamadas. A exploração a partir de aplicativos comuns é limitada pela política SELinux, mas isso não elimina o risco operacional. Processos de rádio, mídia e outros usuários privilegiados podem ter permissão para acessar QMI. Se um desses componentes for comprometido por outra falha, má configuração ou cadeia de ataque local, o invasor pode tentar usar essa permissão legítima para enviar mensagens ao serviço vulnerável. O impacto, portanto, deve ser entendido como uma elevação de controle dentro do dispositivo a partir de um contexto Android já privilegiado, e não como execução remota direta a partir da rede celular confirmada pelo contexto.
O estudo também mostra por que o modem é uma área sensível para defesa móvel. O modem manipula chamadas, SMS, recursos de rádio e funções associadas ao cartão SIM. O contexto analisado afirma que controle sobre o modem poderia permitir acesso a histórico de chamadas e SMS, escuta de conversas e desbloqueio de SIM para contornar limitações impostas pela operadora. Esses efeitos dependem de sucesso na exploração e de controle efetivo do ambiente do modem; a falha comprovada é a corrupção de heap, enquanto os demais impactos representam consequências possíveis caso a primitiva seja convertida em execução confiável no modem.
- Serviço afetado: Voice, no manipulador
qmi_voicei_srvcc_call_config_req. - Canal de acesso: mensagens QMI em TLV entre Android e QuRT.
- Pré-condição operacional: processo, usuário ou serviço Android com permissão SELinux para alcançar o serviço QMI vulnerável.
- Ambiente de interesse: dispositivos com SoCs Qualcomm MSM e serviços QMI expostos ao processador de aplicação.
A detecção prática deve se concentrar na fronteira entre Android e modem, porque o tráfego QMI não aparece como tráfego IP convencional. Em dispositivos gerenciados, equipes de segurança devem procurar anomalias de estabilidade do modem, reinicializações do subsistema de rádio, quedas repetidas de conectividade celular, perda inesperada de serviço de voz ou SMS e eventos de crash em logs do Android relacionados a rádio, RIL, serviços de modem e componentes com acesso privilegiado. Uma reinicialização isolada do modem não confirma exploração, mas recorrência associada a processos específicos pode indicar abuso de interface interna ou falha acionada por entrada anômala.
A telemetria de endpoint móvel, quando disponível, deve mapear quais processos possuem permissões para abrir canais QMI e quais desses processos apresentam comportamento incomum. Mudanças recentes em binários privilegiados, bibliotecas carregadas por serviços de rádio ou mídia, uso anormal de interfaces nativas e falhas repetidas após chamadas a componentes de telefonia são sinais úteis para investigação. Em ambientes corporativos, a contenção deve priorizar dispositivos com firmware desatualizado, builds de fornecedor sem correções recentes e aparelhos nos quais aplicativos com privilégios elevados foram instalados fora do fluxo padrão de gestão.
Para pesquisa defensiva, o caso também recomenda revisar manipuladores que não usam o caminho comum de decodificação do framework QMI. Funções que processam TLV manualmente, laços controlados por contadores vindos da mensagem e cópias para buffers fixos devem ser tratadas como pontos de auditoria prioritários. Em engenharia reversa, nomes de manipuladores e tabelas de serviços podem ajudar a correlacionar IDs de mensagens com funções, mas a análise deve evitar executar payloads ofensivos em dispositivos de produção. O objetivo defensivo é identificar padrões de parsing arriscados, confirmar limites de entrada e validar se a política de acesso impede que componentes não essenciais alcancem serviços sensíveis.
- Reinicializações ou crashes do modem após atividade de serviços de rádio, voz ou mídia.
- Logs Android associados a RIL, telefonia, subsistemas de modem e falhas de comunicação QMI.
- Processos privilegiados acessando serviços QMI fora do padrão esperado para o perfil do dispositivo.
- Manipuladores QMI que interpretam TLV manualmente e usam contadores recebidos sem validação de limite.
A mitigação deve começar pela redução da superfície de acesso. Como a falha depende de envio de mensagem QMI por um contexto autorizado, a política SELinux e as permissões de usuários privilegiados são controles centrais. Serviços que não precisam falar com o domínio Voice ou com outros serviços QMI sensíveis não devem ter essa capacidade. Em imagens corporativas ou customizadas, vale revisar permissões concedidas a componentes de rádio, mídia e integrações de OEM, especialmente quando há serviços adicionais introduzidos pelo fabricante.
A segunda frente é manter firmware, imagens de modem e pacotes de segurança do dispositivo alinhados com o fornecedor. O contexto analisado não fornece um CVE, uma versão corrigida ou uma matriz oficial de modelos afetados, então não é adequado inventar uma lista de versões vulneráveis. A resposta correta é consultar o fabricante do aparelho e o fornecedor do chipset para identificar atualizações de modem aplicáveis ao modelo em uso. Em frotas móveis, dispositivos sem caminho claro de atualização de firmware devem ser tratados como maior risco quando expõem serviços QMI a muitos componentes privilegiados.
Em desenvolvimento e validação de firmware, a correção de classe deve eliminar parsing manual inseguro ou, quando ele for inevitável, impor limites explícitos antes de qualquer cópia para heap. Contadores derivados do TLV precisam ser comparados com o tamanho real do buffer alocado, com o tamanho restante da mensagem e com o número máximo de entradas aceito pela lógica do serviço. O framework comum de QMI, quando disponível, deve ser preferido para validação de formato, porque concentra checagens de integridade que reduzem a chance de cada manipulador repetir erros de limite.
Para resposta a incidente, um dispositivo com sinais consistentes de abuso do modem deve ser isolado da rede corporativa, ter logs preservados, passar por verificação de integridade do firmware e receber reinstalação ou atualização completa de imagem a partir de fonte confiável. Como o modem opera em um ambiente separado do Android, a ausência de malware visível no sistema operacional principal não encerra a investigação. A análise precisa incluir histórico de baseband, estabilidade de rádio, alterações recentes em serviços privilegiados e qualquer cadeia anterior que tenha concedido ao invasor acesso a usuários com permissão para QMI.
- Revisar políticas SELinux para impedir acesso desnecessário a serviços QMI sensíveis.
- Aplicar atualizações de firmware, modem e segurança do fabricante quando disponíveis para o modelo do dispositivo.
- Auditar serviços QMI que processam TLV sem o framework comum de validação.
- Tratar crashes repetidos de modem como sinal investigável quando associados a processos Android privilegiados.
- Validar que contadores e tamanhos de entrada sejam checados antes de cópias para buffers fixos.
0 Comentários