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 aplicativos Android incluídos nos dispositivos Android.

A equipe de segurança do Android encontra vulnerabilidades de segurança por meio de pesquisas internas e também responde a bugs relatados por terceiros. As fontes de bugs externos incluem problemas relatados por meio do modelo Android Security Issue , 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 postados em blogs ou mídias sociais.

Como relatar 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 por meio do formulário de relatório de vulnerabilidade de segurança .

Bugs marcados como problemas de segurança não são visíveis externamente, mas podem eventualmente se tornar visíveis depois que o problema for avaliado ou resolvido. Se você planeja enviar um patch ou teste do Compatibility Test Suite (CTS) para resolver um problema de segurança, anexe-o ao relatório de bug e aguarde uma resposta antes de enviar o código para o AOSP.

Triagem de bugs

A primeira tarefa ao 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 normalmente processa ou pela área em que é executado. Nem todos os contextos de segurança são aplicáveis ​​a todos os sistemas. Esta tabela é ordenada do menos para o mais privilegiado.

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

Por exemplo, aplicativos "sandboxes" para processamento de dados não confiáveis ​​sem permitir acesso ao sistema subjacente.
Contexto sem privilégios Um ambiente de execução típico esperado por código sem privilégios.

Por exemplo, um aplicativo 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, lida com PII de vários usuários e/ou mantém a integridade do sistema.

Por exemplo, um aplicativo Android com recursos que seriam proibidos pelo domínio untrusted_app do SELinux ou com acesso a permissões privileged|signature .
Base de computação confiável (TCB) Funcionalidade que faz parte do kernel, roda no mesmo contexto de CPU que o kernel (como drivers de dispositivo), tem acesso direto à memória do kernel (como componentes de hardware no dispositivo), tem a capacidade de carregar scripts em um componente do kernel ( por exemplo, eBPF), os processadores de comunicação ou é um dos poucos serviços de usuário considerados equivalentes ao kernel: apexd , bpfloader , init , ueventd e vold .
Cadeia do carregador de inicialização Um componente que configura o dispositivo na inicialização e, em seguida, passa o controle para o sistema operacional Android.
Ambiente de Execução Confiável (TEE) Um componente projetado para ser protegido até mesmo de um kernel hostil (por exemplo, TrustZone e Hypervisor).
Enclave Seguro / Elemento Seguro (SE) Um componente de hardware opcional projetado para ser protegido de todos os outros componentes do dispositivo e de ataques físicos, conforme definido em Introdução aos elementos seguros .

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

Gravidade

A gravidade de um bug geralmente reflete o dano potencial que poderia ocorrer se um bug fosse explorado com sucesso. Use os critérios a seguir para determinar a gravidade.

Avaliação Consequência da exploração bem-sucedida
Crítico
  • Acesso não autorizado a dados protegidos pelo SE
  • Execução de código arbitrário no TEE ou SE
  • Execução remota de código arbitrário em um contexto privilegiado, a cadeia de bootloader ou o TCB
  • Negação de serviço persistente remota (permanente ou exigindo a atualização de todo o sistema operacional ou uma redefinição de fábrica)
  • Desvio remoto dos requisitos de interação do usuário na instalação do pacote ou comportamento equivalente
  • Desvio remoto dos requisitos de interação do usuário para qualquer configuração de desenvolvedor, segurança ou privacidade
  • Bypass de inicialização segura remota
  • Bypass de mecanismos projetados para evitar o mau funcionamento de componentes de software ou hardware relacionados à segurança (por exemplo, proteções térmicas)
  • Acesso remoto a credenciais confidenciais usadas para autenticação de serviço remoto (por exemplo, senhas de conta ou tokens de portador)
Alto
  • Bypass de inicialização segura local
  • Um desvio completo de um recurso de segurança principal (como SELinux, FDE ou seccomp)
  • Execução remota de código arbitrário em um contexto sem privilégios
  • Execução de código arbitrário local em um contexto privilegiado, a cadeia de bootloader ou o TCB
  • Acesso não autorizado a dados protegidos pelo TEE
  • Ataques contra um SE que resultam em downgrade para uma implementação menos segura
  • Desvio local dos requisitos de interação do usuário na instalação do pacote ou comportamento equivalente
  • Acesso remoto a dados protegidos (dados limitados a um contexto privilegiado)
  • Negação de serviço persistente local (permanente ou exigindo a atualização de todo o sistema operacional ou redefinição de fábrica)
  • Desvio remoto dos requisitos de interação do usuário (acesso a funcionalidades ou dados que normalmente exigiriam iniciação ou permissão do usuário)
  • Transmissão de informações confidenciais por meio de um protocolo de rede inseguro (por exemplo, HTTP e Bluetooth não criptografado) quando o solicitante espera uma transmissão segura (observe que isso não se aplica à criptografia Wi-Fi, como WEP)
  • Um desvio geral para uma defesa em profundidade ou tecnologia de mitigação de exploração na cadeia de bootloader, TEE ou SE
  • Um desvio geral para proteções do sistema operacional que isolam dados de aplicativos ou perfis de usuários uns dos outros
  • Desvio local dos requisitos de interação do usuário para qualquer configuração de desenvolvedor, segurança ou privacidade
  • Vulnerabilidade criptográfica que permite ataques contra protocolos de ponta a ponta, incluindo ataques contra segurança da camada de transporte (TLS) e Bluetooth (BT).
  • Desvio de tela de bloqueio
  • Ignorar a proteção do dispositivo/proteção de redefinição de fábrica/restrições da operadora
  • Prevenção direcionada do acesso a serviços de emergência
  • Ignorar os requisitos de interação do usuário que são protegidos pelo TEE
  • Prevenção remota de acesso ao serviço celular sem interação do usuário (por exemplo, travando o serviço de rádio celular com um pacote malformado)
  • Acesso local a credenciais confidenciais usadas para autenticação de serviço remoto (por exemplo, senhas de conta ou tokens de portador)
Moderado
  • Execução remota de código arbitrário em um contexto restrito
  • Negação de serviço de dispositivo temporário remoto (travamento remoto ou reinicialização)
  • Execução de código arbitrário local em um contexto sem privilégios
  • Um desvio geral para uma defesa em profundidade ou tecnologia de mitigação de exploração em um contexto privilegiado ou o TCB
  • Ignorar restrições em um processo restrito
  • Acesso remoto a dados desprotegidos (dados normalmente acessíveis a qualquer aplicativo instalado localmente)
  • Acesso local a dados protegidos (dados limitados a um contexto privilegiado)
  • Desvio local dos requisitos de interação do usuário (acesso a funcionalidades ou dados que normalmente exigiriam iniciação ou permissão do usuário)
  • Vulnerabilidade criptográfica em primitivos de criptografia padrão que permite vazamento de texto simples (não primitivos usados ​​em TLS)
  • Ignorando a criptografia ou autenticação Wi-Fi
Baixo
  • Execução de código arbitrário local em um contexto restrito
  • Vulnerabilidade criptográfica em uso não padrão
  • Um desvio geral para uma defesa em nível de usuário em profundidade ou explorar a tecnologia de mitigação em um contexto sem privilégios
  • Documentação incorreta que pode levar a um mal-entendido relacionado à segurança com defeitos de código subsequentes
  • Desvio geral de recursos de personalização no dispositivo, como Voice Match ou Face Match
Impacto de segurança insignificante (NSI)
  • Uma vulnerabilidade cujo impacto foi mitigado por um ou mais modificadores de classificação ou alterações de arquitetura específicas da versão, de modo que a gravidade efetiva esteja abaixo de Baixa, embora o problema de código subjacente possa permanecer
  • Qualquer vulnerabilidade que exija um sistema de arquivos malformado, se esse sistema de arquivos for sempre adotado/criptografado antes do uso.

Modificadores de classificação

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

Razão Efeito
Requer execução como um contexto privilegiado para executar o ataque -1 Gravidade
Os detalhes específicos da vulnerabilidade limitam o impacto do problema -1 Gravidade
Bypass de autenticação biométrica que requer informações biométricas diretamente do proprietário do dispositivo -1 Gravidade
As configurações do compilador ou da plataforma atenuam 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 foi desbloqueado desde que foi ligado -1 Gravidade
Requer acesso físico aos componentes internos do dispositivo enquanto o dispositivo está ligado e foi desbloqueado anteriormente -2 Gravidade
Um ataque local que requer que a cadeia de bootloader seja desbloqueada Não superior a Baixo
Um ataque local que requer que o modo de desenvolvedor ou qualquer configuração persistente do modo de desenvolvedor esteja atualmente habilitado no dispositivo (e não é um bug no próprio modo de desenvolvedor). Não superior a Baixo
Se nenhum domínio SELinux puder conduzir a operação sob a SEPolicy fornecida pelo Google Impacto de segurança insignificante

Local versus Proximal versus Remoto

Um vetor de ataque remoto indica que o bug pode ser explorado sem instalar um aplicativo ou sem 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 conectar-se a uma rede hostil. Para fins de nossas classificações de gravidade, também consideramos vetores de ataque "proximais" como remotos. Isso inclui bugs que podem ser explorados apenas por um invasor que esteja fisicamente próximo ao dispositivo de destino, por exemplo, um bug que exige o envio de pacotes malformados de Wi-Fi ou Bluetooth. Consideramos ataques baseados em banda ultralarga (UWB) e NFC como proximais e, portanto, remotos.

Os ataques locais exigem que a vítima execute um aplicativo, seja instalando e executando um aplicativo ou consentindo em executar um Instant App . Para fins de classificação de gravidade, também consideramos vetores de ataque físico como locais. Isso inclui bugs que podem ser explorados apenas por um invasor que tenha acesso físico ao dispositivo, por exemplo, um bug em uma tela de bloqueio ou um que exija a conexão de um cabo USB. Observe que os ataques que exigem uma conexão USB têm a mesma gravidade, independentemente de o dispositivo precisar ser desbloqueado ou não; é comum que os dispositivos sejam desbloqueados enquanto conectados ao USB.

Segurança de rede

O Android assume que todas as redes são hostis e podem estar injetando ataques ou espionando o tráfego. Embora a segurança da camada de link (por exemplo, criptografia Wi-Fi) proteja a comunicação entre um dispositivo e o ponto de acesso ao qual está conectado, não faz nada para proteger os links restantes na cadeia entre o dispositivo e os servidores com os quais está se comunicando.

Por outro lado, o HTTPS normalmente protege toda a comunicação de ponta a ponta, criptografando os dados em sua origem, descriptografando-os e verificando-os apenas quando atingirem seu destino final. Por causa disso, as vulnerabilidades que comprometem a segurança da rede da camada de link são classificadas como menos graves do que as vulnerabilidades em HTTPS/TLS: a criptografia Wi-Fi sozinha é insuficiente 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 quase correspondência (consulte o blog de desenvolvedores do Android: tela de bloqueio e melhorias de autenticação no Android 11 ). Essas classificações de gravidade distinguem entre duas classes de ataques e destinam-se a refletir o risco real para o usuário final.

A primeira classe de ataques permite contornar a autenticação biométrica de forma generalizável, sem dados biométricos de alta qualidade do proprietário. Se, por exemplo, um invasor puder colocar um chiclete 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 executado em qualquer dispositivo suscetível. Não requer nenhum conhecimento do proprietário do dispositivo. Dado que é generalizável e potencialmente afeta um número maior de usuários, esse ataque recebe a classificação de gravidade completa (por exemplo, Alta, para um desvio de tela de bloqueio).

A outra classe de ataques geralmente envolve um instrumento de ataque de apresentação (spoof) baseado no proprietário do dispositivo. Às vezes, essas informações biométricas são relativamente fáceis de obter (por exemplo, se a foto do perfil de alguém nas mídias sociais for suficiente para enganar a autenticação biométrica, um desvio biométrico receberia a classificação de gravidade completa). Mas se um invasor precisar adquirir dados biométricos diretamente do proprietário do dispositivo (por exemplo, uma varredura infravermelha do rosto), essa é uma 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 obter informações sobre nossas políticas relacionadas a SYSTEM_ALERT_WINDOW e tapjacking, consulte a seção " Tapjacking/overlay SYSTEM_ALERT_WINDOW Vulnerability on a non-security-critical screen " da página BugHunter University's Bugs with no security impact .

Componente afetado

A equipe de desenvolvimento responsável por corrigir o bug depende de qual componente o bug está. Pode ser um componente central da plataforma Android, um driver de kernel fornecido por um fabricante de equipamento original (OEM) ou um dos aplicativos pré-carregados em dispositivos Pixel .

Bugs no código 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 no branch master do AOSP disponível publicamente; caso contrário, eles serão corrigidos primeiro em nossos repositórios internos.

O componente também é um fator em como os usuários obtêm atualizações. Um bug na estrutura ou kernel requer uma atualização de firmware over-the-air (OTA) que cada OEM precisa enviar. Um bug em um aplicativo ou biblioteca publicado 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.

Notificando parceiros

Quando uma vulnerabilidade de segurança no AOSP for corrigida em um Boletim de segurança do Android, notificaremos os parceiros Android sobre os detalhes do problema e forneceremos 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 obter a lista de dispositivos compatíveis.

Liberando código para AOSP

Se o bug de segurança estiver em um componente AOSP, a correção será enviada para o AOSP depois que o OTA for liberado para os usuários. Correções para problemas de baixa gravidade podem ser enviadas diretamente para a ramificação principal do AOSP antes que uma correção esteja disponível para os dispositivos por meio de um OTA.

Recebendo atualizações do Android

As atualizações para o sistema Android geralmente são entregues aos dispositivos por meio de pacotes de atualização OTA. Essas atualizações podem vir do OEM que produziu o dispositivo ou da operadora que presta serviço ao dispositivo. As atualizações do dispositivo Google Pixel vêm da equipe do Google Pixel depois de passar por um procedimento de teste de aceitação técnica (TA) da operadora. O Google também publica imagens de fábrica de pixels que podem ser carregadas de lado para dispositivos.

Atualizando serviços do Google

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

Outros recursos

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

As informações de segurança existem em todos os sites de código aberto e desenvolvedor do Android. Bons lugares para começar:

Relatórios

Às vezes, a equipe de segurança do Android publica relatórios ou whitepapers. Consulte Relatórios de segurança para obter mais detalhes.