CVE-2023-35674

Falha de lógica em WindowState.java (Android Framework) permite que um app já instalado — sem privilégios adicionais — contorne a proteção contra Background Activity Launch (BAL) e lance uma activity mesmo estando em segundo plano. É escalação de privilégio local, sem interação do usuário, e o próprio boletim do Google indica exploração limitada e direcionada antes da publicação — por isso entrou no catálogo KEV da CISA.

O Android restringe quando um app em background pode iniciar uma activity (BAL — Background Activity Launch), justamente para impedir que apps maliciosos sequestrem a tela do usuário sem que ele tenha interagido com esse app. Essa decisão é tomada em parte pelo WindowManager, olhando se o app requisitante possui alguma janela 'visível' que justifique a permissão.

O commit de correção (Bug 264029851 / 205130886) revela o mecanismo: janelas do tipo TYPE_PRESENTATION associadas a displays virtuais estavam sendo contabilizadas como janelas visíveis normais no cálculo de onCreate/verificação de BAL do WindowState.java. Um app conseguia manter uma dessas janelas de apresentação em um display virtual e usar essa condição para satisfazer artificialmente o critério de 'app com janela visível', destravando a permissão para lançar activities em background — sem que o usuário tivesse de fato interagido com esse app.

O tipo de falha é um erro de lógica de autorização/controle de acesso (a descrição oficial usa literalmente 'logic error'): a checagem de visibilidade não diferenciava corretamente presentation windows em displays virtuais (que não são tela principal visível ao usuário) de janelas realmente na tela primária. Isso quebra a premissa de segurança do BAL, que depende de 'visibilidade real para o usuário' como proxy de interação legítima.

O atacante controla: qual app malicioso instalar, e a capacidade de criar/gerenciar uma janela TYPE_PRESENTATION em um display virtual sob seu controle — ambas ações possíveis com privilégios de app comum, sem permissão especial documentada como pré-requisito adicional além do vetor PR:L do CVSS.

O pré-requisito real é ter um app malicioso instalado no dispositivo com privilégios normais (PR:L no CVSS, AV:L — ataque local, executado a partir do próprio dispositivo). Não há interação do usuário necessária depois da instalação: o app abusa da lógica de BAL para lançar activities em background por conta própria, no momento que o atacante escolher.

O resultado prático é escalação de privilégio local: o app consegue lançar telas/activities fora do fluxo normal de interação do usuário, contornando uma proteção projetada especificamente para impedir isso. Isso é usado como primitiva em cadeias maiores — por exemplo, para forçar a exibição de uma activity de outro componente/app com efeito de sequestro de tela, phishing por overlay, ou como passo intermediário dentro de uma cadeia de exploração mais ampla que visa comprometimento total do dispositivo.

O boletim do Android de setembro de 2023 registra explicitamente 'indications that CVE-2023-35674 may be under limited, targeted exploitation' antes da correção — linguagem típica de uso em campanhas de spyware comercial contra alvos específicos, não exploração massiva. A CISA adicionou a falha ao KEV em 13/09/2023 com prazo de correção em 04/10/2023, mas não detalha o autor da exploração nem confirma uso em ransomware ('Known To Be Used in Ransomware Campaigns: Unknown'). Existe PoC pública conforme catalogado, mas os detalhes de reprodução não estão nas fontes oficiais consultadas.

A correção é a atualização do dispositivo para o nível de patch de segurança Android 2023-09-05 ou posterior — o próprio boletim afirma que patch levels dessa data ou mais recentes endereçam todas as falhas listadas, incluindo as do lote 2023-09-01 (onde CVE-2023-35674 está catalogada, referência A-264029851). A disponibilidade depende do fabricante do dispositivo (OEM) empacotar e distribuir esse patch level nas suas próprias atualizações — dispositivos fora de suporte ou com atraso de patch do fabricante permanecem expostos indefinidamente.

Não há flag de configuração, permissão a revogar ou controle compensatório documentado que neutralize a falha sem o patch: o problema está na lógica interna do WindowManager do framework, não em um parâmetro exposto ao usuário ou administrador. O Google Play Protect pode ajudar a detectar apps maliciosos que tentem abusar da técnica, mas isso é redução de superfície (menos apps hostis instalados), não uma correção da vulnerabilidade em si — não deve ser tratado como mitigação equivalente ao patch.

Para ambientes que não conseguem atualizar (dispositivos legados, gestão de frota corporativa com patch atrasado), a única redução de risco real é restringir a instalação de apps a fontes controladas e monitoradas, já que a exploração exige um app malicioso já residente no dispositivo — isso não elimina o risco, apenas reduz a chance do vetor inicial (instalação do app atacante) se materializar.

Não há assinatura de rede ou log de servidor a procurar — a exploração ocorre inteiramente no dispositivo, dentro da lógica interna do WindowManager, sem tráfego externo característico. Em telemetria local/EDR móvel, um indicador possível seria um app sem foco/interação recente do usuário criando ou mantendo janelas do tipo TYPE_PRESENTATION associadas a displays virtuais, seguido do lançamento de activities enquanto permanece em segundo plano — mas isso não é um artefato documentado publicamente como IOC confiável, e as fontes consultadas não descrevem um método de detecção validado.