Esta página foi traduzida pela API Cloud Translation.

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 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.

Relatando 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 vulnerabilidade .

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 de 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 foi 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 cobre 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 restrito onde apenas as permissões mais mínimas são fornecidas. Por exemplo, aplicativos confiáveis processando dados não confiáveis em um ambiente de área restrita.
Contexto não privilegiado	Um ambiente de execução típico esperado por código não privilegiado. 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 várias PII de usuários e/ou mantém a integridade do sistema. Por exemplo, um aplicativo Android com recursos que seriam proibidos pelo domínio SELinux `untrusted_app` ou com acesso a permissões `privileged\|signature` .
Kernel do sistema operacional	Funcionalidade que: faz parte do núcleo é executado no mesmo contexto da 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)	Componentes de hardware discretos, geralmente no SoC, que fornecem funcionalidade crítica para os principais casos de uso do dispositivo (como bandas básicas de celular, DSPs, GPUs e processadores ML).
Cadeia do Bootloader	Um componente que configura o dispositivo na inicialização e 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 do sistema operacional hostil (por exemplo, TrustZone e hipervisores, como pKVM, que protegem as máquinas virtuais do Kernel do sistema operacional).
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 de Segurança . Isso inclui o chip Titan-M presente em alguns dispositivos Android.

Gravidade

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

Avaliação	Consequência da exploração bem-sucedida
Crítico	Execução de código arbitrário no TEE ou SE Desvio de mecanismos de software 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) Execução remota de código arbitrário dentro do contexto de banda base 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 bootloader, THB ou o Kernel do sistema operacional Ignorar remotamente os requisitos de interação do usuário na instalação do pacote ou comportamento equivalente Ignorar remotamente os requisitos de interação do usuário para o desenvolvedor principal, segurança ou configurações de privacidade Negação de serviço remota persistente (permanente, exigindo reflash de todo o sistema operacional ou redefinição de fábrica) Bypass de inicialização segura remota Acesso não autorizado a dados protegidos pelo SE, incluindo acesso habilitado por chaves fracas no SE.
Alto	Um bypass completo de um recurso de segurança central (por exemplo, SELinux, FBE ou `seccomp` ) Um desvio geral para uma defesa em profundidade ou explorar a tecnologia de mitigação na cadeia de bootloader, TEE ou SE Um desvio geral para proteções do sistema operacional que revelam a memória ou o conteúdo do arquivo em aplicativos, usuários ou limites de perfil Ataques contra um SE que resultam em rebaixamento para uma implementação menos segura Ignorar a proteção do dispositivo/proteção de redefinição de fábrica/restrições da operadora Ignorar os 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 da camada de transporte (TLS) e Bluetooth (BT). Acesso local a credenciais confidenciais usadas para autenticação de serviço remoto (por exemplo, senhas de conta ou tokens de portador) Execução de código arbitrário local em um contexto privilegiado, a cadeia de bootloader, THB ou o Kernel do sistema operacional Desvio de inicialização segura local Ignorar a tela de bloqueio Ignorar localmente os requisitos de interação do usuário para configurações principais de desenvolvedor, segurança ou privacidade Desvio local dos requisitos de interação do usuário na instalação do pacote ou comportamento equivalente Negação de serviço persistente local (permanente, exigindo reflash de todo o sistema operacional ou redefinição de fábrica) Acesso remoto a dados protegidos (ou seja, dados limitados a um contexto privilegiado) Execução remota de código arbitrário em um contexto não privilegiado Prevenção remota de acesso ao serviço de celular ou Wi-Fi sem interação do usuário (por exemplo, travando o serviço de rádio celular com um pacote malformado) Ignorar remotamente os requisitos de interação do usuário (acesso a funcionalidades ou dados que devem exigir iniciação ou permissão do usuário) Prevenção direcionada de acesso a serviços de emergência Transmitir informações confidenciais por 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) Acesso não autorizado a dados protegidos pelo TEE, incluindo acesso habilitado por chaves fracas no TEE
Moderado	Um desvio geral para uma defesa em profundidade ou explorar a tecnologia de mitigação em um contexto privilegiado, THB ou o Kernel do sistema operacional Um desvio geral para proteções do sistema operacional que revelam o estado do processo ou os metadados nos limites do aplicativo, usuário ou perfil Ignorando a criptografia ou autenticação de Wi-Fi Vulnerabilidade criptográfica em primitivas criptográficas padrão que permite vazamento de texto simples (não primitivas usadas em TLS) Acesso local a dados protegidos (ou seja, dados limitados a um contexto privilegiado) Execução de código arbitrário local em um contexto não 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) Acesso remoto a dados desprotegidos (ou seja, dados normalmente acessíveis a qualquer aplicativo instalado localmente) Execução remota de código arbitrário em um contexto restrito Negação de serviço de dispositivo temporário remoto (interrupção remota ou reinicialização)
Baixo	Um desvio geral para uma defesa em nível de usuário em profundidade ou explorar a tecnologia de mitigação em um contexto não privilegiado Ignorar uma permissão de nível de proteção normal Vulnerabilidade criptográfica em uso fora do padrão Desvio 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 falsa expectativa de segurança
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 (não aplicável a TEE, SE e hypervisors como pKVM)	-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 tiver sido 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 ativado 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 requer o envio de pacotes Wi-Fi ou Bluetooth malformados. Consideramos os ataques de banda ultralarga (UWB) e baseados em NFC como próximos e, portanto, remotos.

Os ataques locais exigem que a vítima execute um aplicativo, instalando e executando um aplicativo ou consentindo em executar um Instant App . Dispositivos complementares emparelhados serão considerados como locais. Para fins de classificação de gravidade, a equipe de segurança do Android também considera os 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.

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, ela 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 e, em seguida, descriptografando e verificando-os apenas quando atingem seu destino final. Por causa disso, as vulnerabilidades que comprometem a segurança da rede na 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 Blog de desenvolvedores do Android: tela de bloqueio e melhorias de autenticação no Android 11 ). Essas classificações de gravidade distinguem 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 colocar um pedaço de 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 total (por exemplo, Alto, para um bypass 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 na mídia social for suficiente para enganar a autenticação biométrica, um bypass biométrico receberá a classificação de gravidade total). Mas se um invasor precisar adquirir dados biométricos diretamente do proprietário do dispositivo (por exemplo, uma varredura infravermelha de seu rosto), essa é uma barreira significativa o suficiente para limitar o número de pessoas afetadas pelo ataque, portanto, há um modificador -1 .

`SYSTEM_ALERT_WINDOW` e Tapjacking

Para obter informações sobre nossas políticas sobre SYSTEM_ALERT_WINDOW e tapjacking, consulte a seção " Vulnerabilidade de tapjacking/overlay SYSTEM_ALERT_WINDOW em uma tela não crítica à segurança " da página Bugs sem impacto na segurança da BugHunter University.

Segurança multiusuário no Android Automotive OS

O Android Automotive OS adota um modelo de segurança multiusuário diferente dos outros fatores de forma. Cada usuário do Android deve 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 do carro. Para acomodar casos de uso como este, os usuários, por padrão, têm acesso aos componentes necessários para usar o veículo, como Wi-Fi e configurações de rede celular.

Componente afetado

A equipe de desenvolvimento responsável por corrigir o bug depende de qual componente o bug está. Pode ser um componente principal 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 na ramificação mestre AOSP disponível publicamente; caso contrário, eles são corrigidos em nossos repositórios internos primeiro.

O componente também é um fator em como os usuários obtêm atualizações. Um bug na estrutura ou no 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.

Parceiros notificadores

Quando uma vulnerabilidade de segurança no AOSP for corrigida em um boletim de segurança do Android, notificaremos os parceiros do Android sobre os detalhes do problema e forneceremos patches. A lista de versões com suporte de 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 o código para o 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 dispositivos por meio de um OTA.

Recebendo atualizações do Android

As atualizações para o sistema Android geralmente são fornecidas 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 Pixel que podem ser carregadas lateralmente para dispositivos.

Atualizando os serviços do Google

Além de fornecer patches para bugs de segurança, a equipe de segurança do Android revisa 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 avisar os usuários sobre aplicativos que podem ser potencialmente prejudiciais.

Outros recursos

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

Existem informações de segurança em todos os sites Android Open Source e Developer. 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.