A equipe de segurança do Android é responsável por gerenciar as vulnerabilidades de segurança descobertas na plataforma Android e em muitos dos principais apps do 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 informados por terceiros. As fontes de bugs externos incluem problemas informados pelo 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 em blogs ou mídias sociais.
Denunciar 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 usando o formulário de vulnerabilidade.
Bugs marcados como problemas de segurança não ficam visíveis externamente, mas podem ser disponibilizados após a avaliação ou resolução do problema. Se você planeja enviar um patch ou um teste do conjunto de teste de compatibilidade (CTS) para resolver um problema de segurança, anexe-o ao relatório de 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 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 aborda as definições de 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. Essa tabela está ordenada do menos para o mais privilegiado.
| Tipo de contexto | Definição de tipo |
|---|---|
| Contexto restrito |
Um ambiente de execução restrito em que apenas as permissões mínimas são fornecidas. Por exemplo, apps confiáveis que processam dados não confiáveis em um ambiente de sandbox. |
| Contexto sem privilégios |
Um ambiente de execução típico esperado por código sem privilégios. Por exemplo, um app Android que é executado em um domínio do SELinux com o atributo untrusted_app_all.
|
| Contexto privilegiado |
Um ambiente de execução privilegiado que pode ter acesso a permissões elevadas, processa
várias informações de identificação pessoal do usuário e/ou mantém a integridade do sistema. Por exemplo, um app Android com recursos que seriam proibidos pelo domínio untrusted_app do SELinux
ou com acesso a permissões
privileged|signature.
|
| Kernel do SO |
Funcionalidade que:
|
| Base de hardware confiável (THB) | Componentes de hardware discretos, geralmente no SoC, que fornecem funcionalidades essenciais para os principais casos de uso do dispositivo (como bandas de base celular, DSPs, GPUs e processadores de ML). |
| Cadeia de carregadores de inicialização | Um componente que configura o dispositivo na inicialização e depois passa o controle para o SO Android. |
| Ambiente de execução confiável (TEE) | Um componente projetado para ser protegido até mesmo de um kernel de SO hostil (por exemplo, TrustZone e hipervisores, como pKVM, que protegem máquinas virtuais do kernel do SO). |
| Enclave seguro / Elemento de segurança (SE) |
Um componente de hardware opcional projetado para ser protegido de todos os outros componentes do dispositivo e de 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 possível dano que pode ocorrer se ele for explorado com sucesso. Use os critérios a seguir para determinar a gravidade.
| Classificação | Consequência de uma exploração bem-sucedida |
|---|---|
| Crítico |
|
| Alta |
|
| Moderada |
|
| Baixa |
|
| Impacto de segurança insignificante (NSI) |
|
Modificadores de gravidade
Embora a gravidade das vulnerabilidades de segurança seja fácil de identificar, as classificações podem mudar de acordo com as circunstâncias.
| Motivo | Efeito |
|---|---|
| Exige execução como um contexto privilegiado para realizar 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 |
| Ignorar a autenticação biométrica que exige informações biométricas diretamente do proprietário do dispositivo | -1 Gravidade |
| Configurações de compilador ou plataforma mitigam uma vulnerabilidade no código-fonte | Gravidade moderada se a vulnerabilidade subjacente for moderada ou maior |
| Exige acesso físico aos componentes internos do dispositivo e ainda é possível se o dispositivo estiver desligado ou não tiver sido desbloqueado desde que foi ligado. | -1 Gravidade |
| Exige acesso físico aos componentes internos do dispositivo enquanto ele está ligado e foi desbloqueado anteriormente | -2 Gravidade |
| Um ataque local que exige o desbloqueio da cadeia do carregador de inicialização | Não maior que "Baixa" |
| Um ataque local que exige que o modo de desenvolvedor ou qualquer configuração persistente desse modo esteja ativado no dispositivo (e não seja um bug no próprio modo de desenvolvedor). | Não maior que "Baixa" |
| Se nenhum domínio do SELinux puder realizar a operação na SEPolicy fornecida 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 em uma página da Web, ler um e-mail, receber uma mensagem SMS ou se conectar a uma rede hostil.
Vetores de ataque proximais são considerados remotos. Isso inclui bugs que podem ser explorados apenas por um invasor que esteja fisicamente perto do dispositivo de destino, por exemplo, um bug que exige o envio de pacotes Wi-Fi ou Bluetooth malformados. Consideramos ataques de banda ultralarga (UWB) e baseados em NFC como proximais e, portanto, remotos.
Para ataques locais, o invasor precisa ter acesso prévio à vítima. Em um exemplo hipotético somente de software, isso pode acontecer por um app malicioso instalado pela vítima ou um app instantâneo que ela concordou em executar.
Os dispositivos pareados com sucesso (como dispositivos complementares Bluetooth) são considerados locais. Fazemos uma distinção entre um dispositivo pareado e um dispositivo que está participando de um fluxo de pareamento.
- Bugs que prejudicam a capacidade do usuário de identificar o outro dispositivo que está sendo pareado (ou seja, autenticação) são considerados proximais e, portanto, remotos.
- Bugs que acontecem durante o fluxo de pareamento, mas antes que o consentimento do usuário (ou seja, a autorização) seja estabelecido, são considerados proximais e, portanto, remotos.
- Bugs que acontecem depois que o consentimento do usuário é estabelecido são considerados locais, mesmo que o pareamento falhe.
Os vetores de ataque físico são considerados locais. Isso inclui bugs que podem ser explorados apenas por um invasor com acesso físico ao dispositivo, por exemplo, um bug em uma tela de bloqueio ou um que exige a conexão de um cabo USB. Como é comum que os dispositivos estejam desbloqueados enquanto conectados a USB, os ataques que exigem uma conexão USB têm a mesma gravidade, independente de o dispositivo precisar estar desbloqueado ou não.
Segurança de rede
O Android presume que todas as redes são hostis e podem injetar ataques ou espionar 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 a que ele está conectado, ela não faz nada para proteger os links restantes na cadeia entre o dispositivo e os servidores com que ele está se comunicando.
Por outro lado, o HTTPS geralmente protege toda a comunicação de ponta a ponta, criptografando os dados na origem e descriptografando e verificando apenas quando eles chegam ao destino final. Por isso, as vulnerabilidades que comprometem a segurança de rede da camada de enlace 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 é uma área desafiadora, e até mesmo os melhores sistemas podem ser enganados por uma correspondência quase perfeita. Consulte Blog de desenvolvedores Android: melhorias na tela de bloqueio e na autenticação no Android 11 (em inglês). Essas classificações distinguem duas classes de ataques e refletem o risco real para o usuário final.
A primeira classe de ataques permite ignorar a autenticação biométrica de maneira generalizada, sem dados biométricos de alta qualidade do proprietário. Por exemplo, se um invasor puder colocar um chiclete em um sensor de impressão digital e isso conceder acesso ao dispositivo com base no resíduo deixado no sensor, esse é um ataque simples que pode ser realizado em qualquer dispositivo suscetível. Não é necessário ter conhecimento do proprietário do dispositivo. Como ele é generalizável e pode afetar um número maior de usuários, esse ataque recebe a classificação de gravidade total (por exemplo, "Alta", para uma violação da tela de bloqueio).
A outra classe de ataques geralmente envolve um instrumento de ataque de apresentação (spoof) com base no proprietário do dispositivo. Às vezes, essas informações biométricas são relativamente fáceis de conseguir. Por exemplo, se a foto do perfil de alguém em uma rede social for suficiente para enganar a autenticação biométrica, uma violação biométrica vai 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 leitura infravermelha do 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 informações sobre nossas políticas relacionadas a SYSTEM_ALERT_WINDOW e tapjacking,
consulte a seção "Vulnerabilidade de tapjacking/sobreposição SYSTEM_ALERT_WINDOW em uma tela não crítica para a 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 é destinado a uma pessoa física diferente. Por exemplo, um usuário temporário pode ser atribuído a um amigo que pega o veículo emprestado do proprietário. Para atender a casos de uso como esse, os usuários têm acesso por padrão aos componentes necessários para usar o veículo, como configurações de Wi-Fi e rede celular.
Componente afetado
A equipe de desenvolvimento responsável por corrigir o bug depende do componente em que ele está. Pode ser um componente principal da plataforma Android, um driver de kernel fornecido por um fabricante de equipamento original (OEM) ou um dos apps pré-carregados em dispositivos Pixel.
Os bugs no código do AOSP são corrigidos pela equipe de engenharia do Android nos nossos repositórios internos.
O componente também é um fator na forma como os usuários recebem atualizações. Um bug na estrutura ou no kernel exige uma atualização de firmware over-the-air (OTA) que cada OEM precisa enviar. Um bug em um app ou biblioteca publicada 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.
Notificar parceiros
Quando uma vulnerabilidade de segurança no AOSP é corrigida em um Boletim de Segurança do Android, notificamos os parceiros do Android sobre os detalhes do problema e fornecemos patches. A lista de versões compatíveis com backport muda a cada nova versão do Android. Entre em contato com o fabricante do dispositivo para conferir a lista de dispositivos compatíveis.
Lançar código para o AOSP
Se o bug de segurança estiver em um componente do AOSP, a correção será enviada para o AOSP depois que a OTA for lançada para os usuários.
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 para o dispositivo. As atualizações de dispositivos Google Pixel são enviadas pela equipe do Google Pixel depois de passar por 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 transferidas por sideload para dispositivos.
Atualizar os Serviços do Google
Além de fornecer patches para bugs de segurança, a equipe de segurança do Android analisa esses bugs para determinar se há outras maneiras de proteger os usuários. Por exemplo, o Google Play verifica todos os apps e remove aqueles que tentam 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 recurso Verificar apps para alertar os usuários sobre apps potencialmente nocivos.
Outros recursos
Informações para desenvolvedores de apps Android: https://developer.android.com
As informações de segurança estão disponíveis nos sites de código aberto e para desenvolvedores do Android. Ótimos 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 mais detalhes.