O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
This page was translated by the Cloud Translation API.
Switch to English

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 agrupados com 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. Fontes de bugs externos incluem problemas relatados por meio do modelo de problema de segurança do Android , 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ídia social.

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 através 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 após o problema ser 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 ao AOSP.

Erros de triagem

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 processo

Esta tabela cobre as definições dos tipos de processo. O tipo de processo pode ser definido pelo tipo de aplicativo ou processo ou pela área em que ele é executado. Esta tabela é ordenada do menos para o mais privilegiado.

Tipo de processo Definição de tipo
Processo restrito Um processo executado em um domínio SELinux altamente limitado.
OU
Um processo significativamente mais limitado do que um aplicativo normal.
Processo não privilegiado Um aplicativo ou processo executado em um domínio SELinux com o atributo untrusted_app_all ou é equivalentemente restrito.
Processo privilegiado Um aplicativo ou processo com recursos que seriam proibidos pelo domínio SELinux untrusted_app .
OU
Um aplicativo ou processo com privilégios importantes que um aplicativo de terceiros não pode obter.
OU
Um componente de hardware integrado no dispositivo que não faz parte da base de computação confiável (TCB).
Base de computação confiável (TCB) Funcionalidade que faz parte do kernel, é executada 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 de kernel ( por exemplo, eBPF), o Baseband Processor, ou é um dos vários serviços de usuário que é considerado equivalente do kernel: init , ueventd e vold .
Bootloader Um componente que configura o dispositivo na inicialização e, em seguida, passa o controle para o sistema operacional Android.
Trusted Execution Environment (TEE) Um componente projetado para ser protegido até mesmo de um kernel hostil (por exemplo, TrustZone e Hypervisor).
Elemento seguro (SE) Um componente opcional projetado para ser protegido de todos os outros componentes do dispositivo e de ataques físicos, conforme definido na Introdução aos Elementos Seguros .

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
  • Acesso não autorizado a dados protegidos pela SE
  • Execução de código arbitrário no TEE ou SE
  • Execução remota de código arbitrário em um processo privilegiado, bootloader ou TCB
  • Negação de serviço permanente remota (inoperabilidade do dispositivo: completamente permanente ou exigindo 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 de requisitos de interação do usuário para qualquer desenvolvedor, segurança ou configurações de privacidade
  • Bypass de inicialização segura remota
  • Desvio de mecanismos de segurança projetados para evitar o mau funcionamento de componentes de hardware críticos (por exemplo, proteções térmicas)
Alto
  • Bypass de inicialização segura local
  • Um desvio completo de um recurso de segurança central (como SELinux, FDE ou seccomp)
  • Execução remota de código arbitrário em um processo sem privilégios
  • Execução de código arbitrário local em um processo privilegiado, bootloader ou TCB
  • Acesso não autorizado a dados protegidos pelo TEE
  • Ataques contra um SE que resultam no rebaixamento para uma implementação menos segura
  • Ignorar localmente os requisitos de interação do usuário na instalação do pacote ou comportamento equivalente
  • Acesso remoto a dados protegidos (dados limitados a um processo privilegiado)
  • Negação de serviço local permanente (inoperabilidade do dispositivo: permanente ou exigindo atualização de todo o sistema operacional ou redefinição de fábrica)
  • Ignorar remotamente os requisitos de interação do usuário (acesso à funcionalidade ou dados que normalmente exigiriam iniciação ou permissão do usuário)
  • Transmitir 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 tecnologia de defesa em profundidade ou mitigação de exploração no bootloader, TEE ou SE
  • Um desvio geral para as proteções do sistema operacional que isolam dados de aplicativos ou perfis de usuário uns dos outros
  • Ignorar localmente os requisitos de interação do usuário para qualquer desenvolvedor, segurança ou configurações de privacidade
  • Vulnerabilidade criptográfica na segurança da camada de transporte padrão (TLS) que permite ataques no caminho
  • Ignorar tela de bloqueio
  • Ignorar proteção de dispositivo / proteção de redefinição de fábrica / restrições da operadora
  • Prevenção direcionada ao acesso a serviços de emergência
  • Contornar os requisitos de interação do usuário que são protegidos pelo TEE
Moderado
  • Execução remota de código arbitrário em um processo restrito
  • Negação de serviço temporária de dispositivo remoto (travamento remoto ou reinicialização)
  • Execução de código arbitrário local em um processo sem privilégios
  • Um desvio geral para uma tecnologia de defesa em profundidade ou de mitigação de exploração em um processo privilegiado ou TCB
  • Contornar as 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 processo privilegiado)
  • Ignorar localmente os requisitos de interação do usuário (acesso à funcionalidade ou dados que normalmente exigiriam a iniciação ou permissão do usuário)
  • Vulnerabilidade criptográfica em cripto primitivas padrão que permite o vazamento de texto simples (não primitivas usadas em TLS)
  • Ignorando a criptografia ou autenticação Wi-Fi
Baixo
  • Execução de código arbitrário local em um processo 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 tecnologia de mitigação de exploração em um processo sem privilégios
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 requeira 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 seja geralmente fácil de identificar, as classificações podem mudar com base nas circunstâncias.

Razão Efeito
Requer execução como um processo privilegiado para executar o ataque -1 Severidade
Detalhes específicos da vulnerabilidade limitam o impacto do problema -1 Severidade
Bypass de autenticação biométrica que requer informações biométricas diretamente do proprietário do dispositivo -1 Severidade
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 telefone estiver desligado ou não tiver sido desbloqueado desde que foi ligado -1 Severidade
Requer acesso físico às partes internas do dispositivo enquanto o telefone está ligado e foi desbloqueado anteriormente -2 Gravidade
Um ataque local que requer que o bootloader seja desbloqueado Não mais alto que baixo
Um ataque local que requer o modo de desenvolvedor ou qualquer configuração persistente do modo de desenvolvedor atualmente habilitada no dispositivo (e não é um bug no próprio modo de desenvolvedor). Não mais alto que baixo
Se nenhum domínio SELinux puder conduzir a operação de acordo com 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 para 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, a equipe de segurança do Android também considera os vetores de ataque "proximais" como remotos. Isso inclui bugs que podem ser explorados apenas por um invasor que está fisicamente próximo ao dispositivo de destino, por exemplo, um bug que requer o envio de pacotes de Wi-Fi ou Bluetooth malformados. A equipe de segurança do Android considera os ataques baseados em NFC como proximais e, portanto, remotos.

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ções 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 requer 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 ser desbloqueado ou não; é comum que os dispositivos sejam desbloqueados enquanto estão conectados ao USB.

Segurança de Wi-Fi

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 Wi-Fi ao qual ele 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 isso, as vulnerabilidades que comprometem a segurança do Wi-Fi são classificadas como menos graves do que as vulnerabilidades em HTTPS / TLS: a criptografia de 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. Essas classificações de gravidade distinguem entre duas classes de ataques e têm o objetivo de refletir o risco real para o usuário final.

A primeira classe de ataques permite contornar a autenticação biométrica de uma forma generalizável, sem dados biométricos de alta qualidade do proprietário. Se, por exemplo, um invasor pode colocar um pedaço de chiclete em um sensor de impressão digital e ele concede 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. Visto que é generalizável e potencialmente afeta um número maior de usuários, esse ataque recebe a classificação de gravidade total (por exemplo, Alta, para um desvio de Lockscreen).

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 imagem do perfil de alguém nas redes sociais for suficiente para enganar a autenticação biométrica, um desvio 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), isso é uma barreira significativa o suficiente para limitar o número de pessoas afetadas pelo ataque, então há um modificador -1 .

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 certos 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 são corrigidos em nossos repositórios internos primeiro.

O componente também é um fator de 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 é corrigida em um Boletim de Segurança do Android, notificaremos os parceiros do Android sobre os detalhes do problema e forneceremos correções. A lista de versões compatíveis com backport muda a cada nova versão do Android. Contate 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 lançado aos usuários. Correções para problemas de baixa gravidade podem ser enviadas diretamente para o branch master 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ços para o dispositivo. As atualizações do dispositivo Google Pixel são fornecidas pela 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 paralelamente 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 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 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 white papers. Consulte Relatórios de segurança para obter mais detalhes.