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 pelo 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 |
Funcionalidades que:
|
Base de hardware confiável (THB) | Componentes de hardware discretos, geralmente no SoC, que fornecem funcionalidade essencial 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 seguro / 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 |
|
Alta |
|
Moderada |
|
Baixa |
|
Impacto na segurança (NSI, na sigla em inglês) insignificante |
|
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 proximal 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.
Dispositivos pareados com sucesso (como dispositivos complementares Bluetooth) são considerados locais. Qa distinguir entre um dispositivo pareado e um dispositivo que está participando de um pareamento fluxo
- Bugs que prejudicam a capacidade do usuário de identificar o outro dispositivo que está sendo pareado (por exemplo, do Google) são consideradas proximais e, portanto, remotas.
- Bugs que ocorrem durante o fluxo de pareamento, mas antes do consentimento do usuário (ou seja, autorização) foram estabelecidas são consideradas proximais e, portanto, remotas.
- Os bugs que ocorrem após o consentimento do usuário ser estabelecido são considerados locais, mesmo que o pareamento acabará falhando.
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 do veículo. 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 enviadas 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 maneiras 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. Bom lugares para começar:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
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.