Atualizações e recursos de segurança

A equipe de segurança do Android é responsável por gerenciar as vulnerabilidades de segurança descobertas no a plataforma Android e muitos dos principais apps Android incluídos em 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 informados por terceiros. As fontes de bugs externos incluem problemas informados através do formulário de vulnerabilidade, pesquisa acadêmica publicada e pré-publicada, mantenedores de projetos de código aberto upstream, notificações dos fabricantes de dispositivos parceiros e problemas divulgados publicamente postados blogs ou mídias sociais.

Como 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 com o formulário de vulnerabilidade.

Bugs marcados como problemas de segurança não são visíveis externamente, mas eles podem surgir no futuro visível após a avaliação ou resolução do problema. Se você planeja enviar um patch ou Teste o conjunto de teste de compatibilidade (CTS) para resolver um problema de segurança, anexe-o ao bug e aguarde uma resposta antes de fazer upload do 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 aos usuários.

Tipos de contexto

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

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

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

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

Por exemplo, um app Android com recursos que seriam proibidos pelo domínio SELinux untrusted_app ou com acesso a privileged|signature.
Kernel do SO Funcionalidade que:
  • é 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 do dispositivo)
  • consegue 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 oferecem funcionalidades essenciais aos principais casos de uso do dispositivo (como bandas de base celulares, DSPs, GPUs e ML) processadores).
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 hostil de SO (por exemplo, TrustZone e hipervisores, como pKVM, que protegem máquinas virtuais do SO kernel).
Enclave de Segurança / Elemento de Segurança (SE) Um componente de hardware opcional projetado para ser protegido de todos os outros componentes da dispositivo e de ataques físicos, conforme definido nos 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 explorados com sucesso. Use os critérios a seguir para determinar a gravidade.

Rating Consequência de uma exploração bem-sucedida
Crítico
  • Execução arbitrária de código no TEE ou SE
  • Ignorar mecanismos de software criados para evitar softwares ou hardwares relacionados à segurança defeituosos dos componentes (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 do portador)
  • Execução remota de código arbitrário no contexto da banda de base do celular sem usuários interação (por exemplo, exploração de um bug no serviço de rádio celular)
  • Execução remota e arbitrária de código em um contexto com privilégios, a cadeia do carregador de inicialização, THB ou o kernel do SO
  • Ignorar remotamente os requisitos de interação do usuário na instalação do pacote ou equivalente comportamento
  • Ignorar remotamente os requisitos de interação do usuário para desenvolvedores principais, segurança ou configurações de privacidade
  • Negação de serviço persistente e remota (permanente, exigindo a reprogramação de todo o sistema operacional ou uma redefinição de fábrica)
  • Ignorar na inicialização segura remota
  • Acesso não autorizado a dados protegidos pelo SE, incluindo acesso habilitado por chaves fracas em SE.
Alta
  • uma passagem completa de um recurso principal de segurança (por exemplo, SELinux, FBE ou seccomp)
  • Uma via de acesso geral para uma tecnologia de defesa em profundidade ou de mitigação de exploração no cadeia do carregador de inicialização, TEE ou SE
  • Um desvio geral para proteções do sistema operacional que revelam o conteúdo da memória ou do arquivo além dos limites do app, usuário ou perfil
  • Ataques contra um SE que resultam no downgrade para uma implementação menos segura
  • Mudança de firmware bare metal comprometido acessível remotamente (por exemplo, banda de base, CP/processador de comunicação) no kernel do processador de aplicativo (AP) ou passar pelo desvio mecanismos projetados para isolar o firmware bare-metal do kernel do AP
  • Ignorar a proteção do dispositivo/proteção contra 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 Transport Layer Security (TLS) e Bluetooth (BT).
  • Acesso local a credenciais confidenciais usadas para autenticação de serviço remoto (por exemplo, senhas de conta ou tokens do portador)
  • Execução arbitrária local de código em um contexto com privilégios, a cadeia do carregador de inicialização, THB ou o kernel do SO
  • Ignorar na inicialização segura local
  • Ignorar tela de bloqueio
  • Ignorar local dos requisitos de interação do usuário para desenvolvedores principais, segurança ou privacidade configurações
  • Ignorar local dos requisitos de interação do usuário na instalação do pacote ou equivalente comportamento
  • Negação de serviço local persistente (permanente, que exige a atualização de todo o sistema operacional ou redefinir para a configuração original)
  • Acesso remoto a dados protegidos, ou seja, dados limitados a uma contexto)
  • Execução remota de código arbitrário em um contexto sem privilégios
  • Prevenção remota do acesso a serviços de rede celular ou Wi-Fi sem interação do usuário (por exemplo, falha no serviço de rádio celular com um pacote incorreto)
  • 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
  • Transmissão de 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. Observação para que isso não se aplique à criptografia de Wi-Fi (como WEP)
  • Acesso não autorizado a dados protegidos pelo TEE, incluindo acesso ativado por chaves fracas no TEE
Moderada
  • uma passagem geral para uma tecnologia de defesa em profundidade ou de mitigação de exploração em uma contexto privilegiado, THB, ou o kernel do SO
  • Um desvio geral para proteções de sistemas operacionais que revelam o estado do processo ou metadados em limites de apps, usuários ou perfis
  • Ignorar 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 primitivos usados 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 local dos requisitos de interação do usuário (acesso a funcionalidades ou dados que normalmente exigiria orientação ou permissão do usuário)
  • Acesso remoto a dados desprotegidos (ou seja, dados normalmente acessíveis a qualquer pessoa localmente app instalado)
  • Execução remota de código arbitrário em um contexto restrito
  • Negação de serviço temporária do dispositivo remoto (interrupção ou reinicialização remota)
Baixa
  • Uma passagem geral para uma tecnologia de defesa profunda ou mitigação de ataques no nível do usuário em em um contexto sem privilégios
  • Ignorar uma regra nível de proteção permissão
  • Vulnerabilidade criptográfica em uso não padrão
  • Ignorar 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 na segurança (NSI, na sigla em inglês) insignificante
  • uma vulnerabilidade cujo impacto foi atenuado 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 inferior a Baixa, embora o problema do código continue
  • Qualquer vulnerabilidade que exija um sistema de arquivos malformado, caso esse sistema esteja sempre adotados/criptografados antes do uso.
  • Negação de serviço temporária local, por exemplo, quando a condição pode ser resolvida reiniciando o dispositivo ou desinstalando o app de acionamento.

Modificadores de classificação

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

Motivo Efeito
Exige a execução como um contexto privilegiado para executar o ataque (não aplicável a TEE, SE, e hipervisores, como pKVM) -1 Gravidade
Os detalhes específicos da vulnerabilidade limitam o impacto do problema -1 Gravidade
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 reduzem 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 será possível se o dispositivo estiver desligado ou não foi desbloqueada desde que foi ligado -1 Gravidade
Requer acesso físico aos componentes internos do dispositivo enquanto ele estiver ligado e tiver sido usado anteriormente foi desbloqueado -2 Gravidade
Ataque local que exige que a cadeia do carregador de inicialização seja desbloqueada Não superior a Baixo
Ataque local que exige o modo de desenvolvedor ou qualquer configuração persistente desse modo para estar ativada no dispositivo no momento (e não ser um bug no Modo de Desenvolvedor). Não superior a Baixo
Se nenhum domínio SELinux puder conduzir a operação sob o SEPolicy fornecido pelo Google Impacto insignificante na segurança

Local x proximal x remoto

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

Vetores de ataque proximais são considerados remotos. Isso inclui bugs que só podem ser explorados por um invasor que esteja fisicamente perto do dispositivo-alvo, por exemplo, um bug que exige ao enviar pacotes Wi-Fi ou Bluetooth malformados. Consideramos banda ultralarga (UWB) e tecnologia NFC ataques como proximais e, portanto, remotos.

Os ataques locais exigem que o atacante tenha acesso prévio à vítima. Em um cenário hipotético por exemplo, por meio de um app malicioso que a vítima tenha instalado ou Instant App que eles têm consentiu a exibição.

Os vetores de ataque físico são considerados locais. Isso inclui bugs que podem ser explorados apenas por um invasor que tem acesso físico ao dispositivo, por exemplo, um bug em uma tela de bloqueio que requer a conexão de um cabo USB. Como é comum que os dispositivos sejam desbloqueados enquanto conectados a uma porta USB, os ataques que exigem uma conexão USB têm a mesma gravidade, se é necessário desbloquear o dispositivo.

Segurança de rede

O Android supõe que todas as redes são hostis e podem injetar ataques ou espionagem do tráfego de entrada. Enquanto a segurança da camada de links (por exemplo, criptografia Wi-Fi) protege a comunicação entre um dispositivo e o ponto de acesso ao qual ele está conectado, ele não protege o elos restantes na cadeia entre o dispositivo e os servidores com que ele se comunica.

Em contrapartida, o HTTPS geralmente protege toda a comunicação de ponta a ponta, criptografando os dados na origem e, em seguida, descriptografa e verifica o código apenas quando chega ao destino final. Por isso, as vulnerabilidades que comprometem a segurança de rede da camada de links têm classificações menores severas do que as vulnerabilidades em HTTPS/TLS: a criptografia Wi-Fi por si só é insuficiente para a maioria e comunicação 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 um quase correspondente (consulte Blog de desenvolvedores Android: Melhorias na tela de bloqueio e na autenticação no Android 11 (em inglês). Essas classificações de gravidade distinguem duas classes de ataques e visam para refletir o risco real para o usuário final.

A primeira classe de ataques permite ignorar a autenticação biométrica de maneira generalizável, sem dados biométricos de alta qualidade do proprietário. Se, por exemplo, um invasor conseguir colocar um pedaço de chiclete em um sensor de impressão digital, e concede acesso ao dispositivo com base no resíduo restante no sensor, isso é um ataque simples que pode ser realizado em qualquer dispositivo suscetível. Ela não requer nenhum conhecimento do proprietário do dispositivo. Como ele é generalizável pode afetar um número maior de usuários, ele 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 (spoof) baseado em do proprietário do dispositivo. Às vezes, essas informações biométricas são relativamente fáceis de obter (por Por exemplo, se a foto do perfil de alguém em mídias sociais for suficiente para enganar a autenticação biométrica, um desvio biométrico recebe a classificação de gravidade total). Mas se um invasor precisar para adquirir dados biométricos diretamente do proprietário do dispositivo (por exemplo, uma leitura infravermelha do no rosto), isso é uma barreira significativa o suficiente para limitar o número de pessoas afetadas então há um modificador -1.

SYSTEM_ALERT_WINDOW e Tapjacking

Para mais informações sobre nossas políticas relacionadas a SYSTEM_ALERT_WINDOW e roubo de dados, Confira a vulnerabilidade Tapjacking/overlay SYSTEM_ALERT_WINDOW em uma tela que não é crítica para a segurança" do site da BugHunter University Bugs que não afetam a segurança página.

Segurança para vários usuários no Android Automotive OS

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

Componente afetado

A equipe de desenvolvimento responsável por corrigir o bug depende do componente em que ele está. Pode ser um componente central da plataforma Android, um driver de kernel fornecido por um sistema fabricante de equipamento (OEM) ou um dos apps 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 de conhecimento público podem ser corrigidos diretamente no ramificação principal do AOSP disponível publicamente Caso contrário, eles são corrigidos nos nossos repositórios internos primeiro.

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

Como notificar os parceiros

Quando uma vulnerabilidade de segurança no AOSP for corrigida em um boletim de segurança do Android, vamos notificar Parceiros Android com detalhes de problemas e fornecem patches. A lista de versões compatíveis com backport mudanças a cada nova versão do Android. Entre em contato com o fabricante do dispositivo para receber a lista de compatíveis.

Liberação de 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 liberados para os usuários. Correções para problemas de baixa gravidade podem ser enviadas diretamente ao AOSP principal antes que uma correção seja disponibilizada para os dispositivos por um OTA.

Receber atualizações do Android

As atualizações do sistema Android geralmente são entregues aos dispositivos por 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 dos dispositivos Google Pixel vêm da equipe do Google Pixel após serem concluídas por meio de 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 transferidos por sideload para os dispositivos.

Atualizando Serviços do Google

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

Outros recursos

Informações para desenvolvedores de apps Android: https://developer.android.com (link em inglês)

Há informações de segurança em todos os sites do Android Open Source e do desenvolvedor. Boa lugares para começar:

Relatórios

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