Atualizações e recursos de segurança

A equipe de segurança do Android é responsável por gerenciar as vulnerabilidades de segurança descobertas na plataforma Android e em muitos dos principais apps do Android incluídos nos dispositivos.

A equipe de segurança do Android encontra vulnerabilidades de segurança por meio de pesquisas internas e também responde a bugs informados por terceiros. As fontes de bugs externos incluem problemas informados pelo formulário de vulnerabilidade, pesquisas acadêmicas publicadas e pré-publicadas, mantenedores de projetos de código aberto upstream, notificações de nossos parceiros fabricantes de dispositivos e problemas divulgados publicamente em blogs ou mídias sociais.

Informar problemas de segurança

Qualquer desenvolvedor, usuário do Android ou pesquisador de segurança pode notificar a equipe de segurança do Android sobre possíveis problemas de segurança usando o formulário de vulnerabilidade.

Os bugs marcados como problemas de segurança não são visíveis externamente, mas podem ser mostrados após a avaliação ou resolução do problema. Se você planeja enviar um patch ou um teste do conjunto de testes de compatibilidade (CTS, na sigla em inglês) para resolver um problema de segurança, anexe-o ao relatório de bug e aguarde uma resposta antes de fazer upload do código para o AOSP.

Triagem de bugs

A primeira tarefa para lidar com uma vulnerabilidade de segurança é identificar a gravidade do bug e qual componente do Android é afetado. A gravidade determina como o problema é priorizado, e o componente determina quem corrige o bug, quem é notificado e como a correção é implantada para os usuários.

Tipos de contexto

Esta tabela abrange as definições de contextos de segurança de hardware e software. O contexto pode ser definido pela sensibilidade dos dados que ele processa normalmente ou pela área em que ele é executado. Nem todos os contextos de segurança são aplicáveis a todos os sistemas. Essa tabela é ordenada do menor para o maior privilégio.

Tipo de contexto Definição de tipo
Contexto limitado Um ambiente de execução restrito em que apenas as permissões mínimas são fornecidas.

Por exemplo, apps confiáveis que processam dados não confiáveis em um ambiente em sandbox.
Contexto sem privilégios Um ambiente de execução típico esperado por código sem privilégios.

Por exemplo, um app Android executado em um domínio SELinux com o atributo untrusted_app_all.
Contexto privilegiado Um ambiente de execução privilegiado que pode ter acesso a permissões elevadas, processa várias PIIs de usuários e/ou mantém a integridade do sistema.

Por exemplo, um app Android com recursos que seriam proibidos pelo domínio untrusted_app do SELinux ou com acesso a permissões privileged|signature.
Kernel do SO Funcionalidade que:
  • faz parte do kernel
  • é executado no mesmo contexto de CPU que o kernel (por exemplo, drivers de dispositivo)
  • tem acesso direto à memória do kernel (por exemplo, componentes de hardware no dispositivo)
  • tem a capacidade de carregar scripts em um componente do kernel (por exemplo, eBPF)
  • é um dos poucos serviços de usuário considerados equivalentes ao kernel, como apexd, bpfloader, init, ueventd e vold.
Base de hardware confiável (THB, na sigla em inglês) Componentes de hardware discretos, geralmente no SoC, que fornecem funcionalidade crítica para os casos de uso principais do dispositivo (por exemplo, basebands de celular, DSPs, GPUs e processadores de ML).
Cadeia do carregador de inicialização Um componente que configura o dispositivo na inicialização e transmite o controle para o SO Android.
Ambiente de execução confiável (TEE) Um componente projetado para ser protegido até mesmo de um kernel de SO hostil (por exemplo, TrustZone e hipervisores, como pKVM, que protegem máquinas virtuais do kernel do SO).
Enclave seguro / elemento de segurança (SE) Um componente de hardware opcional projetado para ser protegido contra todos os outros componentes do dispositivo e contra ataques físicos, conforme definido em Introdução aos elementos seguros.

Isso inclui o chip Titan-M presente em alguns dispositivos Android.

Gravidade

A gravidade de um bug geralmente reflete o possível dano que pode ocorrer se ele for explorado. Use os critérios a seguir para determinar a gravidade.

Classificação Consequência de uma exploração bem-sucedida
Crítico
  • Execução arbitrária de código no TEE ou SE
  • Bypass de mecanismos de software projetados para evitar que componentes de software ou hardware relacionados à segurança apresentem mau funcionamento (por exemplo, proteções térmicas)
  • Acesso remoto a credenciais sensíveis usadas para autenticação de serviços remotos (por exemplo, senhas de conta ou tokens de portador)
  • Execução remota de código arbitrário no contexto da baseband celular sem interação do usuário (por exemplo, exploração de um bug no serviço de rádio celular)
  • Execução remota de código arbitrário em um contexto privilegiado, a cadeia de carregador de inicialização, o THB ou o kernel do SO
  • Bypass remoto dos requisitos de interação do usuário na instalação do pacote ou comportamento equivalente
  • Bypass remoto de requisitos de interação do usuário para configurações principais de desenvolvedor, segurança ou privacidade
  • Negação de serviço remota persistente (permanente, exigindo a reinstalação de todo o sistema operacional ou uma redefinição para a configuração original)
  • Bypass remoto da inicialização segura
  • Acesso não autorizado a dados protegidos pelo SE, incluindo o acesso ativado por chaves fracas no SE.
Alta
  • Um bypass completo de um recurso de segurança principal (por exemplo, SELinux, FBE ou seccomp)
  • Um bypass geral para uma defesa em profundidade ou tecnologia de mitigação de exploits na cadeia de inicializadores de inicialização, TEE ou SE
  • Um bypass geral para proteções do sistema operacional que revelam conteúdo de memória ou arquivo em limites de app, usuário ou perfil
  • Ataques contra um SE que resultam em downgrade para uma implementação menos segura
  • Mudança de um firmware de bare metal comprometido acessível remotamente (por exemplo, baseband, processador de comunicação (CP)) para o kernel do processador de apps (AP) ou mecanismos de bypass projetados para isolar o firmware de bare metal do kernel do AP.
  • Bypass da proteção do dispositivo, da proteção contra redefinição de fábrica ou das restrições da operadora
  • Bypass dos requisitos de interação do usuário que são protegidos pelo TEE
  • Vulnerabilidade criptográfica que permite ataques contra protocolos de ponta a ponta, incluindo ataques contra segurança de camada de transporte (TLS) e Bluetooth (BT).
  • Acesso local a credenciais sensíveis usadas para autenticação remota de serviços (por exemplo, senhas de conta ou tokens de portador)
  • Execução de código arbitrário local em um contexto privilegiado, a cadeia de carregador de inicialização, o THB ou o kernel do SO
  • Bypass local de inicialização segura
  • Ignorar a tela de bloqueio
  • Bypass local de requisitos de interação do usuário para configurações principais de desenvolvedor, segurança ou privacidade
  • Bypass local de requisitos de interação do usuário na instalação de pacotes ou comportamento equivalente
  • Negação de serviço local persistente (permanente, exigindo a reinstalação de todo o sistema operacional ou a redefinição para a configuração original)
  • Acesso remoto a dados protegidos (ou seja, dados limitados a um contexto privilegiado)
  • Execução remota de código arbitrário em um contexto sem privilégios
  • Prevenção remota de acesso a serviços de celular ou Wi-Fi sem interação do usuário (por exemplo, falhar o serviço de rádio celular com um pacote malformado)
  • Bypass remoto de requisitos de interação do usuário (acesso a recursos ou dados que precisam de iniciação ou permissão do usuário)
  • Prevenção direcionada de acesso a serviços de emergência
  • Transmitir informações sensíveis por um protocolo de rede não seguro (por exemplo, HTTP e Bluetooth não criptografado) quando o solicitante espera uma transmissão segura. Isso não se aplica à criptografia Wi-Fi (como WEP).
  • Acesso não autorizado a dados protegidos pelo TEE, incluindo o acesso ativado por chaves fracas no TEE.
Moderada
  • Um bypass geral para uma defesa em profundidade ou tecnologia de mitigação de exploits em um contexto privilegiado, THB ou o kernel do SO
  • Um bypass geral para proteções do sistema operacional que revelam o estado do processo ou metadados em limites de app, usuário ou perfil
  • Ignorar a criptografia ou autenticação do Wi-Fi
  • Vulnerabilidade criptográfica em primitivas criptográficas padrão que permite o vazamento de texto simples (não primitivas usadas no TLS)
  • Acesso local a dados protegidos (ou seja, dados limitados a um contexto privilegiado)
  • Execução de código arbitrária local em um contexto sem privilégios
  • Bypass local de requisitos de interação do usuário (acesso a recursos ou dados que normalmente exigem a iniciação ou permissão do usuário)
  • Acesso remoto a dados desprotegidos (ou seja, dados normalmente acessíveis a qualquer app instalado localmente)
  • Execução remota de código arbitrário em um contexto restrito
  • Negação de serviço temporária remota do dispositivo (travamento ou reinicialização remota)
Baixa
  • Um bypass geral para uma defesa detalhada no nível do usuário ou uma tecnologia de mitigação de exploração em um contexto sem privilégios.
  • Bypass de uma permissão nível de proteção normal
  • Vulnerabilidade criptográfica em uso não padrão
  • Bypass geral de recursos de personalização no dispositivo, como Voice Match ou Face Match
  • Documentação incorreta que pode levar a uma vulnerabilidade de segurança
  • Execução de código arbitrário local em um contexto restrito
  • Texto definido pelo sistema que inclui uma descrição enganosa que cria uma expectativa de segurança falsa
Impacto de segurança insignificante (NSI, na sigla em inglês)
  • Uma vulnerabilidade cujo impacto foi mitigado por um ou mais modificadores de classificação ou mudanças de arquitetura específicas da versão, de modo que a gravidade efetiva seja menor que "Baixa", embora o problema do código possa permanecer.
  • Qualquer vulnerabilidade que exija um sistema de arquivos com formato incorreto, se esse sistema de arquivos for sempre adotado/criptografado antes do uso.
  • Negação de serviço local temporária, como quando a condição pode ser resolvida reiniciando o dispositivo ou desinstalando o app acionado.

Modificadores de tarifa

Embora a gravidade das vulnerabilidades de segurança seja fácil de identificar, as classificações podem mudar de acordo com as circunstâncias.

Motivo Efeito
Requer execução como um contexto privilegiado para executar o ataque (não aplicável ao TEE, SE e hipervisores, como o pKVM) -1 Gravidade
Detalhes específicos da vulnerabilidade limitam o impacto do problema -1 Gravidade
Bypass de autenticação biométrica que exige informações biométricas diretamente do proprietário do dispositivo -1 Gravidade
As configurações do compilador ou da plataforma mitigam uma vulnerabilidade no código-fonte Gravidade moderada se a vulnerabilidade subjacente for moderada ou superior
Requer acesso físico aos componentes internos do dispositivo e ainda é possível se o dispositivo estiver desligado ou não tiver sido desbloqueado desde que foi ligado -1 Gravidade
Exige acesso físico aos componentes internos do dispositivo enquanto ele está ligado e foi desbloqueado anteriormente -2 Gravidade
Um ataque local que exige que a cadeia do carregador de inicialização seja desbloqueada Não maior que "Baixo"
Um ataque local que exige que o modo de desenvolvedor ou qualquer configuração persistente do modo de desenvolvedor esteja ativado no dispositivo (e não seja um bug no próprio modo de desenvolvedor). Não maior que "Baixo"
Se nenhum domínio do SELinux puder realizar a operação de acordo com a SEPolicy fornecida pelo Google Impacto na segurança insignificante

Local x proximal x remoto

Um vetor de ataque remoto indica que o bug pode ser explorado sem a instalação de um app ou sem o acesso físico a um dispositivo. Isso inclui bugs que podem ser acionados ao navegar em uma página da Web, ler um e-mail, receber uma mensagem SMS ou se conectar a uma rede hostil.

Os vetores de ataque proximais são considerados remotos. Isso inclui bugs que só podem ser explorados por um invasor que está fisicamente próximo ao dispositivo de destino. Por exemplo, um bug que exige o envio de pacotes Wi-Fi ou Bluetooth com formato incorreto. Consideramos os ataques de banda ultralarga (UWB) e com NFC como ataques próximos e, portanto, remotos.

Os ataques locais exigem que o invasor tenha acesso prévio à vítima. Em um exemplo hipotético de software, isso pode ser feito por um app malicioso que a vítima instalou ou um app instantâneo que ela permitiu.

Os dispositivos pareados (como dispositivos complementares Bluetooth) são considerados locais. Fazemos uma distinção entre um dispositivo pareado e um que está participando de um fluxo de pareamento.

  • Bugs que degradam a capacidade do usuário de identificar o outro dispositivo pareado (por exemplo, autenticação) são considerados próximos e, portanto, remotos.
  • Os bugs que acontecem durante o fluxo de pareamento, mas antes do consentimento do usuário (ou seja, a autorização) ser estabelecido, são considerados próximos e, portanto, remotos.
  • Os bugs que ocorrem após o consentimento do usuário são considerados locais, mesmo que o pareamento falhe.

Os vetores de ataque físico são considerados locais. Isso inclui bugs que só podem ser explorados por um invasor que tenha acesso físico ao dispositivo, por exemplo, um bug na tela de bloqueio ou um que exija a conexão de um cabo USB. Como é comum que os dispositivos sejam desbloqueados enquanto estão conectados a uma porta USB, os ataques que exigem uma conexão USB têm a mesma gravidade, independentemente de o dispositivo precisar ser desbloqueado ou não.

Segurança de rede

O Android presume que todas as redes são hostis e podem injetar ataques ou espionar o tráfego. Embora a segurança na camada de link (por exemplo, criptografia Wi-Fi) proteja a comunicação entre um dispositivo e o ponto de acesso ao qual ele está conectado, ela não protege os links restantes na cadeia entre o dispositivo e os servidores com os quais ele se comunica.

Por outro lado, o HTTPS normalmente protege toda a comunicação de ponta a ponta, criptografando os dados na origem e, em seguida, descriptografando e verificando-os somente quando eles chegam ao destino final. Por isso, as vulnerabilidades que comprometem a segurança da rede na camada de link são consideradas menos graves do que as vulnerabilidades no HTTPS/TLS: a criptografia do Wi-Fi por si só não é suficiente para a maioria das comunicações na Internet.

Autenticação biométrica

A autenticação biométrica é um espaço desafiador, e até mesmo os melhores sistemas podem ser enganados por uma correspondência aproximada. Consulte Blog para desenvolvedores Android: melhorias na tela de bloqueio e na autenticação do Android 11. Essas classificações de gravidade distinguem duas classes de ataques e têm como objetivo refletir o risco real para o usuário final.

A primeira classe de ataques permite contornar a autenticação biométrica de uma forma geral, sem dados biométricos de alta qualidade do proprietário. Se, por exemplo, um invasor colocar uma goma de mascar em um sensor de impressão digital e conceder acesso ao dispositivo com base no resíduo deixado no sensor, esse é um ataque simples que pode ser realizado em qualquer dispositivo suscetível. Ele não exige nenhum conhecimento sobre o proprietário do dispositivo. Como ele pode ser generalizado e afetar um número maior de usuários, esse ataque recebe a classificação de gravidade total (por exemplo, "Alta", para um desvio da tela de bloqueio).

A outra classe de ataques geralmente envolve um instrumento de ataque de apresentação (falsificação) baseado no proprietário do dispositivo. Às vezes, essas informações biométricas são relativamente fáceis de conseguir. Por exemplo, se a foto do perfil de alguém nas mídias sociais for suficiente para enganar a autenticação biométrica, um bypass biométrico vai receber a classificação de severidade máxima. No entanto, se um invasor precisar adquirir dados biométricos diretamente do proprietário do dispositivo (por exemplo, uma verificação por infravermelho do rosto), essa barreira é significativa o suficiente para limitar o número de pessoas afetadas pelo ataque. Portanto, há um modificador de -1.

SYSTEM_ALERT_WINDOW e tapjacking

Para informações sobre nossas políticas relacionadas a SYSTEM_ALERT_WINDOW e tapjacking, consulte a seção "Vulnerabilidade de tapjacking/sobreposição SYSTEM_ALERT_WINDOW em uma tela sem importância crítica para a segurança" da página Bugs sem impacto na segurança da Universidade de BugHunter.

Segurança multiusuário no Android Automotive OS

O Android Automotive OS adota um modelo de segurança multiusuário diferente dos outros formatos. Cada usuário do Android precisa ser usado por uma pessoa física diferente. Por exemplo, um usuário convidado temporário pode ser atribuído a um amigo que pega o veículo emprestado do proprietário. Para acomodar casos de uso como esse, os usuários têm acesso por padrão aos componentes necessários para usar o veículo, como as configurações de Wi-Fi e de rede celular.

Componente afetado

A equipe de desenvolvimento responsável pela correção do bug depende do componente em que ele está. Pode ser um componente principal da plataforma Android, um driver do kernel fornecido por um fabricante de equipamento original (OEM) ou um dos apps pré-carregados nos dispositivos Pixel.

Os bugs no código do AOSP são corrigidos pela equipe de engenharia do Android. Bugs de baixa gravidade, bugs em determinados componentes ou bugs que já são conhecidos publicamente podem ser corrigidos diretamente na ramificação principal do AOSP disponível publicamente. Caso contrário, eles são corrigidos primeiro nos repositórios internos.

O componente também é um fator na forma como os usuários recebem atualizações. Um bug no framework ou no kernel requer uma atualização de firmware over-the-air (OTA) que cada OEM precisa enviar. Um bug em um app ou biblioteca publicados no Google Play (por exemplo, Gmail, Google Play Services ou WebView) pode ser enviado aos usuários do Android como uma atualização do Google Play.

Notificar parceiros

Quando uma vulnerabilidade de segurança no AOSP for corrigida em um boletim de segurança do Android, vamos notificar os parceiros do Android sobre os detalhes do problema e fornecer patches. A lista de versões com suporte para backport muda a cada nova versão do Android. Entre em contato com o fabricante do dispositivo para conferir a lista de dispositivos compatíveis.

Liberar código para o AOSP

Se o bug de segurança estiver em um componente do AOSP, a correção será enviada ao AOSP depois que o OTA for lançado para os usuários. As correções de problemas de baixa gravidade podem ser enviadas diretamente para a ramificação principal do AOSP antes que uma correção seja disponibilizada para os dispositivos por uma OTA.

Receber atualizações do Android

As atualizações do sistema Android geralmente são enviadas aos dispositivos por pacotes de atualização OTA. Essas atualizações podem vir do OEM que produziu o dispositivo ou da operadora que fornece o serviço para o dispositivo. As atualizações do dispositivo Google Pixel vêm da equipe do Google Pixel após passar por um procedimento de teste de aceitação técnica (TA, na sigla em inglês) da operadora. O Google também publica imagens de fábrica do Pixel que podem ser transferidas para dispositivos.

Atualizar os Serviços do Google

Além de fornecer patches para bugs de segurança, a equipe de segurança do Android analisa bugs de segurança para determinar se há outras maneiras de proteger os usuários. Por exemplo, o Google Play verifica todos os apps e remove qualquer um que tente explorar um bug de segurança. Para apps instalados fora do Google Play, os dispositivos com Google Play Services também podem usar o recurso Verificar apps para alertar os usuários sobre apps potencialmente nocivos.

Outros recursos

Informações para desenvolvedores de apps Android: https://developer.android.com

As informações de segurança estão disponíveis em todos os sites do Android Open Source e Desenvolvedores. Bons lugares para começar:

Relatórios

Às vezes, a equipe de segurança do Android publica relatórios ou documentos técnicos. Consulte Relatórios de segurança para mais detalhes.