O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 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 erros externos incluem problemas relatados por meio do modelo de Problema de Segurança Android , publicado e prepublished pesquisa acadêmica, a montante abertas mantenedores do projeto fonte, as notificações dos seus parceiros fabricante do dispositivo, e publicamente questões divulgados postados em blogs ou mídias sociais.

Relatando problemas de segurança

Qualquer desenvolvedor, o usuário Android, ou pesquisador de segurança pode notificar a equipe de potenciais problemas de segurança de segurança do Android através do formulário de notificação 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 contexto

Esta tabela cobre as definições dos contextos de segurança de hardware e software. O contexto pode ser definido pela sensibilidade dos dados que ele 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 mínimas são fornecidas.

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

Por exemplo, um aplicativo Android que roda em um domínio SELinux com o untrusted_app_all atributo.
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 capacidades que seria proibido pelo SELinux untrusted_app domínio ou com acesso a privileged|signature permissões.
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), os processadores de comunicação, ou é um de uma série de serviços de utilizador que é considerado equivalente do kernel: apexd , bpfloader , init , ueventd , e vold .
Corrente de 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).
Enclave seguro / Elemento seguro (SE) Um componente de hardware opcional concebido para ser protegida de todos os outros componentes do dispositivo e do ataque físico, tal como definido na introdução de elementos de 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 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 arbitrária de código no TEE ou SE
  • Execução remota de código arbitrário em um contexto privilegiado, a cadeia de bootloader ou TCB
  • Negação de serviço persistente remota (permanente ou exigindo atualização de todo o sistema operacional ou uma redefinição de fábrica)
  • 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 qualquer desenvolvedor, segurança ou configurações de privacidade
  • Bypass de inicialização segura remota
  • Ignorar 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 contas ou tokens de portador)
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 contexto sem privilégios
  • Execução de código arbitrário local em um contexto privilegiado, a cadeia de 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 contexto privilegiado)
  • Negação de serviço persistente local (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 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á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 que permite ataques contra protocolos ponta a ponta, incluindo ataques contra segurança da camada de transporte (TLS) e Bluetooth (BT).
  • Ignorar tela de bloqueio
  • Ignorar a proteção do dispositivo / proteção de redefinição de fábrica / restrições da operadora
  • Prevenção direcionada de acesso a serviços de emergência
  • Ignorar os requisitos de interação do usuário que são garantidos pelo TEE
  • Prevenção remota de acesso ao serviço de celular sem interação do usuário (por exemplo, travar 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 contas ou tokens de portador)
Moderado
  • Execução remota de código arbitrário em um contexto 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 contexto sem privilégios
  • Um desvio geral para uma tecnologia de defesa em profundidade ou de mitigação de exploração em um contexto 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 contexto privilegiado)
  • Ignorar localmente os requisitos de interação do usuário (acesso à funcionalidade ou dados que normalmente exigiriam 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 criptografia ou autenticação de 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 tecnologia de mitigação de exploração em um contexto não privilegiado
  • Documentação incorreta que pode levar a um mal-entendido relacionado à segurança com defeitos de código subsequentes
  • Desvio geral da personalização no dispositivo apresenta como Jogo de voz ou Jogo Rosto
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 exige um sistema de arquivos mal formado, se esse sistema de arquivos é sempre adotado / encriptadas antes de usar.

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 contexto privilegiado para executar o ataque -1 Severidade
Os 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 à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 Severidade
Requer acesso físico às partes internas do dispositivo enquanto o dispositivo está ligado e foi desbloqueado anteriormente -2 Gravidade
Um ataque local que requer que a cadeia do bootloader seja desbloqueada 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 ativada 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 o propósito de nossas classificações de gravidade, também consideramos 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. Consideramos os ataques de banda ultralarga (UWB) e baseados em NFC como proximais e, portanto, remotos.

Ataques locais exigem a vítima para executar um aplicativo, seja por instalar e executar um aplicativo ou ao consentir para executar um instantâneo App . Para fins de classificações de gravidade, também consideramos 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. 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 estão 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 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 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 mesmo os melhores sistemas pode ser enganado por um quase-jogo (ver Desenvolvedores Android Blog: LockScreen e autenticação melhorias no Android 11 ). 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. 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, 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 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), isso é uma barreira significativa o suficiente para limitar o número de pessoas afetadas pelo ataque, então há um modificador -1 .

SYSTEM_ALERT_WINDOW e Tapjacking

Para obter informações sobre nossas políticas em relação SYSTEM_ALERT_WINDOW e tapjacking, consulte o "overlay SYSTEM_ALERT_WINDOW vulnerabilidade em um-não-crítica de segurança tela Tapjacking /" na seção da Universidade BugHunter erros sem impacto de segurança página.

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 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 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 é 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 com suporte para backport muda a cada nova versão do Android. Entre em contato com o fabricante do seu 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 o branch master 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 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 o serviço 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. Google também publica imagens Pixel fábrica que podem ser a dispositivos carregados-side.

Atualizando os 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 do lado de fora do Google Play, dispositivos com o Google Play Services também pode usar o Verifique Apps recurso 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. Veja Relatórios de segurança para mais detalhes.