Implementações baseadas no código aberto do Apple Lossless Audio Codec permitiam exploração por arquivo de áudio malformado e elevação local de privilégio em serviços de mídia do Android.
| Componente | Decodificadores ALAC OpenMAX usados em chipsets MediaTek e Qualcomm, incluindo as bibliotecas libMtkOmxAlacDec.so, libOmxAlacDecSw.so e libAlacSwDec.so. |
| Vetor | Arquivo de áudio .m4a malformado processado pelo framework de mídia do Android ou quadro ALAC enviado por aplicativo Android sem privilégios via android.media.MediaCodec. |
| Impacto | Execução remota de código no processamento de mídia e elevação local de privilégio contra serviço privilegiado de mídia, com risco de acesso a conversas de usuário e mídia armazenada. |
| Prioridade | Aplicar atualizações dos boletins de segurança de dezembro de 2021 da MediaTek e da Qualcomm e validar exposição de dispositivos que ainda carregam decodificadores ALAC vulneráveis. |
| CVEs | CVE-2021-0674 e CVE-2021-0675 para MediaTek; CVE-2021-30351 para Qualcomm. |
| Artefatos | Configurações e bibliotecas relacionadas a OpenMAX em /vendor/etc/media_codecs.xml, /vendor/etc/mtk_omx_core.cfg, /vendor/lib/libOmxCore.so e bibliotecas ALAC de fornecedor. |
Falhas graves foram identificadas em implementações do Apple Lossless Audio Codec, conhecido como ALAC, incorporadas por fornecedores de chipsets móveis em decodificadores de áudio usados pelo Android. O problema tem origem na reutilização de código aberto do codec publicado em 2011 e, desde então, não atualizado na mesma base pública, embora a implementação proprietária mantida pela Apple tenha recebido correções ao longo do tempo. O efeito prático é que projetos e fabricantes que copiaram ou portaram essa base antiga passaram a carregar vulnerabilidades de memória em componentes expostos ao processamento de mídia, uma superfície tradicionalmente sensível porque arquivos de áudio podem ser abertos por aplicativos comuns e encaminhados ao framework de mídia do sistema.
As implementações analisadas em chipsets MediaTek e Qualcomm expunham condições de leitura e escrita fora dos limites durante a decodificação de quadros ALAC. Em dispositivos Android, o risco não se limitava a um aplicativo de reprodução específico: um arquivo .m4a malformado podia alcançar o decodificador por meio de uma aplicação que usa o framework de mídia do Android, e um aplicativo sem permissões especiais podia iniciar a decodificação por APIs de baixo nível. A consequência técnica confirmada incluía execução remota de código via arquivo de áudio malicioso e elevação local de privilégio contra o serviço de mídia. As correções foram associadas a CVE-2021-0674, CVE-2021-0675 e CVE-2021-30351, publicadas nos boletins de segurança de dezembro de 2021 dos respectivos fornecedores.
No Android, os codecs de mídia são expostos por meio do mecanismo Stagefright e da integração com OpenMAX, uma interface em C usada para abstrair processamento multimídia. O sistema mantém a lista de codecs disponíveis em /vendor/etc/media_codecs.xml, incluindo nome do codec e tipo de conteúdo. A relação entre nomes de codec e bibliotecas dinâmicas fica incorporada à biblioteca de núcleo OpenMAX, como /vendor/lib/libOmxCore.so; em dispositivos MediaTek, essa associação também aparece em formato de configuração textual em /vendor/etc/mtk_omx_core.cfg. Quando um aplicativo solicita a decodificação de ALAC, o serviço de mídia carrega a biblioteca correspondente do fornecedor, como libMtkOmxAlacDec.so em MediaTek ou libOmxAlacDecSw.so em Qualcomm, e repassa quadros de áudio para a lógica nativa de decodificação.
A fragilidade central está no tratamento de parâmetros controláveis de áudio, especialmente comprimento de quadro, profundidade de bits e número de amostras codificado no próprio quadro. Na implementação MediaTek, o método de inicialização do decodificador preenche um objeto interno com dados fornecidos pelo cabeçalho do arquivo ou por csd-0, incluindo setinfo_max_samples_per_frame e setinfo_sample_size. A alocação de buffers de trabalho é derivada desses valores, mas sem validação adequada de estouro inteiro em ambiente de 32 bits. Durante a decodificação, a função que processa o quadro aceita um número de amostras efetivo vindo do conteúdo codificado e não aplica validação suficiente antes de gravar no buffer de saída. Com combinações malformadas desses campos, o decodificador podia copiar dados além da área alocada ou vazar conteúdo adjacente da heap para o buffer de saída. A implementação Qualcomm apresentava a mesma classe de problema: libOmxAlacDecSw.so atuava como wrapper sobre libAlacSwDec.so, com alocação de mMixBufferU baseada no comprimento de quadro e ausência de verificação robusta do número de amostras informado pelo quadro.
A exposição atinge dispositivos que incorporaram decodificadores ALAC baseados no código vulnerável em bibliotecas de fornecedor. MediaTek e Qualcomm foram destacados porque seus decodificadores estavam presentes em grande parte do ecossistema móvel, e o contexto técnico aponta que dois terços dos smartphones vendidos em 2021 eram vulneráveis. A superfície inclui tanto o processamento de arquivos de áudio recebidos pelo usuário quanto chamadas locais ao codec por aplicativos instalados. Como a classe android.media.MediaCodec permite acesso a codecs de baixo nível e a decodificação pode ser iniciada sem permissões Android específicas, a fronteira de segurança relevante passa a ser a robustez do serviço de mídia e das bibliotecas nativas carregadas no processo privilegiado.
A análise também encontrou pacotes populares do repositório Universe do Ubuntu baseados no mesmo código ALAC vulnerável, o que amplia o tema para além de smartphones. Nesse cenário, a ameaça técnica é a mesma classe de corrupção de memória durante a decodificação de áudio, mas o alvo passa a ser um ambiente Linux com reprodutores, conversores ou bibliotecas que integrem a base antiga. Para operadores de segurança, a conclusão operacional é separar exposição por fornecedor, tipo de decodificador e caminho de processamento: dispositivo móvel com codec OpenMAX de hardware ou software, estáção Linux com pacote derivado da base vulnerável, e qualquer aplicação que processe .m4a de origem externa.
Os principais pontos de exposição são dispositivos Android com chipsets MediaTek que carregam libMtkOmxAlacDec.so, dispositivos Android com chipsets Qualcomm que carregam libOmxAlacDecSw.so e libAlacSwDec.so, serviços de mídia que aceitam quadros ALAC vindos de arquivos .m4a, aplicativos Android capazes de acionar MediaCodec sem permissão especial, e pacotes Linux derivados do decodificador ALAC aberto e não corrigido.
- Dispositivos Android que declaram suporte a ALAC em
/vendor/etc/media_codecs.xml. - Bibliotecas OpenMAX de fornecedor responsáveis por decodificação ALAC em partições
/vendor. - Aplicativos que processam áudio
.m4arecebido de mensagens, downloads, anexos ou armazenamento local. - Pacotes Ubuntu Universe baseados na implementação ALAC vulnerável.
A detecção deve priorizar sinais de processamento anômalo de mídia, falhas nativas e tentativas de acionar decodificação ALAC por aplicações que não têm perfil esperado de reprodução ou edição de áudio. Em Android, equipes de resposta devem revisar tombstones, relatórios de crash e logs de serviço relacionados ao processo de mídia, especialmente quando o crash menciona bibliotecas ALAC de fornecedor, OpenMAX ou falhas de heap durante a decodificação. O evento isolado de crash não confirma exploração, mas a repetição associada a um mesmo aplicativo, arquivo de áudio ou fluxo de entrada externo aumenta a prioridade de análise. Também é relevante identificar apps sem permissões sensíveis que ainda assim interagem com codecs de baixo nível, porque o vetor de elevação local de privilégio não depende de permissões Android tradicionais.
Em gestão de frota móvel, o hunting deve cruzar modelo do dispositivo, chipset, nível de patch de segurança e presença das bibliotecas vulneráveis. Em ambientes Linux, a busca deve localizar pacotes que embutem a implementação aberta de ALAC e rastrear uso de conversores ou reprodutores que processam áudio de fontes não confiáveis. Como os detalhes públicos demonstram primitivas de leitura e escrita de heap, a telemetria defensiva deve tratar crashes de decodificação como possíveis eventos de segurança, não apenas instabilidade de mídia. Arquivos .m4a que antecedem falhas do serviço de mídia devem ser preservados para análise controlada, sem distribuição operacional, e manipulados em ambiente isolado.
Sinais observáveis incluem crash de serviço de mídia após abertura de .m4a, carregamento de libMtkOmxAlacDec.so ou libOmxAlacDecSw.so imediatamente antes de falha nativa, chamadas incomuns à API android.media.MediaCodec por aplicativo sem função legítima de mídia, inconsistência entre nível de patch do dispositivo e boletins de dezembro de 2021, e pacotes Linux com código ALAC antigo usado em fluxos automatizados de conversão.
- Tombstones Android envolvendo bibliotecas ALAC, OpenMAX ou serviço
/vendor/bin/hw/de mídia. - Aplicativos sem perfil multimídia que inicializam decodificação ALAC via
MediaCodec. - Arquivos
.m4arecebidos de origem externa imediatamente antes de crashes de heap. - Dispositivos MediaTek ou Qualcomm sem atualização correspondente aos boletins de dezembro de 2021.
- Reprodutores ou conversores Linux baseados na implementação ALAC aberta sem manutenção.
A mitigação principal é garantir que dispositivos MediaTek e Qualcomm tenham recebido as correções publicadas nos boletins de segurança de dezembro de 2021. Para Android corporativo, isso exige validação por modelo, fabricante, versão do sistema e nível de patch, porque a presença do chipset corrigido no boletim não significa que todos os aparelhos em campo receberam firmware atualizado. Onde a atualização não estiver disponível, a organização deve reduzir a exposição a arquivos de mídia não confiáveis, restringir instalação de aplicativos fora de lojas e políticas corporativas, monitorar crashes do serviço de mídia e priorizar substituição de dispositivos que permanecem presos a imagens de fornecedor antigas.
No lado de engenharia e resposta, a ação defensiva deve incluir inventário de codecs declarados, verificação de bibliotecas ALAC de fornecedor, análise de aplicações que processam anexos de áudio e revisão de pipelines que convertem mídia automaticamente. Para Linux, a correção passa por identificar pacotes derivados do decodificador vulnerável, aplicar atualizações disponíveis ou remover componentes que processem ALAC de fontes externas. Em qualquer ambiente, arquivos suspeitos devem ser tratados como artefatos potencialmente exploráveis: a análise deve ocorrer em sandbox, com coleta de metadados, preservação de logs e sem execução em estáções de trabalho comuns. A validação final deve confirmar ausência de crashes reproduzíveis no serviço de mídia e presença das versões corrigidas indicadas pelos fornecedores.
A ordem recomendada de resposta é inventariar dispositivos por chipset e nível de patch, confirmar presença de correções de dezembro de 2021, bloquear ou isolar aparelhos sem atualização em perfis de maior risco, revisar telemetria histórica de crashes de mídia, preservar amostras suspeitas somente em ambiente controlado, atualizar pacotes Linux afetados e acompanhar recorrência de falhas nativas após a correção.
- Aplicar firmware ou atualização de segurança que inclua
CVE-2021-0674,CVE-2021-0675eCVE-2021-30351. - Validar
/vendor/etc/media_codecs.xmle bibliotecas OpenMAX para mapear suporte ALAC em dispositivos Android. - Monitorar crashes de serviço de mídia associados a
.m4ae bibliotecas ALAC. - Restringir processamento automático de áudio não confiável em endpoints e servidores Linux.
- Tratar aparelhos sem atualização de fornecedor como ativos com risco residual elevado.
0 Comentários