Atualizações e recursos de segurança

A equipe de segurança do Android é responsável por gerenciar 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 postados 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 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 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 confidencialidade 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 está ordenada da menos para a mais privilegiada.

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

Por exemplo, aplicativos confiáveis ​​que processam dados não confiáveis ​​em um ambiente em área restrita.
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 .
Kernel do sistema operacional Funcionalidade que:
  • faz parte do núcleo
  • é 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) Componentes de hardware discretos, geralmente no SoC, que fornecem funcionalidade crítica para os principais casos de uso do dispositivo (como bandas base celulares, DSPs, GPUs e processadores de ML).
Cadeia do bootloader Um componente que configura o dispositivo na inicialização e depois passa o controle para o sistema operacional Android.
Ambiente de execução confiável (TEE) Um componente projetado para ser protegido até mesmo contra um kernel de sistema operacional hostil (por exemplo, TrustZone e hipervisores, como pKVM, que protegem máquinas virtuais do kernel do sistema operacional).
Enclave Seguro/Elemento Seguro (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 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 arbitrária de código no TEE ou SE
  • Ignorar mecanismos de software projetados para evitar 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 ao portador)
  • Execução remota de código arbitrário dentro do contexto de banda base celular sem interação do usuário (por exemplo, explorando um bug no serviço de rádio celular)
  • Execução remota de código arbitrário em um contexto privilegiado, na cadeia do bootloader, no THB ou no kernel do sistema operacional
  • Ignorar remotamente os requisitos de interação do usuário na instalação de pacotes ou comportamento equivalente
  • Ignorar remotamente os requisitos de interação do usuário para configurações principais de desenvolvedor, segurança ou privacidade
  • Negação de serviço persistente remota (permanente, exigindo atualização de todo o sistema operacional ou redefinição de fábrica)
  • Ignorar inicialização segura remota
  • Acesso não autorizado a dados protegidos pela SE, incluindo acesso permitido por chaves fracas na SE.
Alto
  • Um desvio completo de um recurso de segurança principal (por exemplo, SELinux, FBE ou seccomp )
  • Um desvio geral para uma defesa profunda ou tecnologia de mitigação de exploração na cadeia do bootloader, TEE ou SE
  • Um desvio geral para proteções do sistema operacional que revelam conteúdo de memória ou arquivo além dos limites de aplicativos, usuários ou perfis
  • Ataques contra um SE que resultam no downgrade para uma implementação menos segura
  • Pivô de firmware bare-metal comprometido e acessível remotamente (por exemplo, banda base, CP/processador de comunicação) para o kernel do processador de aplicativos (AP) ou ignorar mecanismos projetados para isolar firmware bare-metal do kernel AP
  • 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 protegidos pelo TEE
  • Vulnerabilidade criptográfica que permite ataques contra protocolos 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 local de código arbitrário em um contexto privilegiado, na cadeia do bootloader, no THB ou no kernel do sistema operacional
  • Bypass de inicialização segura local
  • Ignorar tela de bloqueio
  • Ignorar localmente os requisitos de interação do usuário para configurações principais de desenvolvedor, segurança ou privacidade
  • Ignorar localmente os requisitos de interação do usuário na instalação de pacotes ou comportamento equivalente
  • Negação de serviço persistente local (permanente, exigindo atualização 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 sem privilégios
  • Prevenção remota de acesso ao serviço celular ou Wi-Fi sem interação do usuário (por exemplo, travamento do 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 do acesso a serviços de emergência
  • Transmitir informações confidenciais através 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)
  • Acesso não autorizado a dados protegidos pelo TEE, incluindo acesso permitido por chaves fracas no TEE
Moderado
  • Um desvio geral para uma defesa profunda ou tecnologia de mitigação de exploração em um contexto privilegiado, THB ou kernel do sistema operacional
  • Um desvio geral para proteções do sistema operacional que revelam o estado do processo ou metadados entre aplicativos, usuários ou limites de perfil
  • Ignorando a criptografia ou autenticação de Wi-Fi
  • Vulnerabilidade criptográfica em criptografias primitivas 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 sem privilégios
  • Ignorar localmente os 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 remota temporária de dispositivo (travamento ou reinicialização remota)
Baixo
  • Um desvio geral para uma defesa profunda em nível de usuário ou tecnologia de mitigação de exploração em um contexto sem privilégios
  • Ignorar uma permissão de nível de proteção normal
  • Vulnerabilidade criptográfica em uso fora do padrão
  • Ignorar 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 insignificante na segurança (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.
  • Negação de serviço temporária local , como quando a condição pode ser resolvida reiniciando o dispositivo ou desinstalando o aplicativo acionador.

Modificadores de classificação

Embora a gravidade das vulnerabilidades de segurança seja muitas vezes 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 hipervisores como pKVM) -1 Gravidade
Detalhes específicos da vulnerabilidade limitam o impacto do problema -1 Gravidade
Desvio 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 às partes internas 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 às partes internas do dispositivo enquanto o dispositivo estiver ligado e tiver sido desbloqueado anteriormente -2 Gravidade
Um ataque local que requer o desbloqueio da cadeia do bootloader 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 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 a instalação de 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 do dispositivo alvo, 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 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 . Os dispositivos complementares emparelhados serão considerados 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 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-os e verificando-os apenas quando chegarem ao destino final. Por causa disso, as vulnerabilidades que comprometem a segurança da rede na camada de enlace são classificadas como menos graves do que as vulnerabilidades em HTTPS/TLS: a criptografia Wi-Fi por si só é 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 Android: melhorias na tela de bloqueio e na autenticação no Android 11 ). Estas classificações de gravidade distinguem entre duas classes de ataques e destinam-se a reflectir o risco real para o utilizador final.

A primeira classe de ataques permite contornar a autenticação biométrica de forma generalizada, 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 nos resíduos deixados 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 ignorar a 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 redes 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 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 relacionadas a SYSTEM_ALERT_WINDOW e tapjacking, consulte a seção " Tapjacking/sobreposição de vulnerabilidade SYSTEM_ALERT_WINDOW em uma tela não crítica de 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 formatos. 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 pegou emprestado o veículo do proprietário do carro. Para acomodar casos de uso como esse, 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 já conhecidos publicamente podem ser corrigidos diretamente no branch principal do AOSP disponível publicamente; caso contrário, eles serão corrigidos primeiro em nossos repositórios internos.

O componente também é um fator na forma 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.

Notificando parceiros

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 seu dispositivo para obter a lista de dispositivos suportados.

Liberando código para AOSP

Se o bug de segurança estiver em um componente AOSP, a correção será enviada ao AOSP depois que o OTA for liberado para os usuários. Correções para problemas de baixa gravidade podem ser enviadas diretamente para a filial 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 do 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 fornece serviço ao 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) da operadora. O Google também publica imagens de fábrica do Pixel que podem ser carregadas nos 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 existem 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 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 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 de desenvolvedores do Android. Bons lugares para começar:

Relatórios

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