Permissões personalizadas como estas, são geralmente definidas em ambos os níveis de proteção, "signature" ou "signatureOrSystem". Estes são definidos na documentação Android Open Source Project (AOSP), como:
| Signature | A permissão que o sistema concede, é somente se o aplicativo solicitante for assinado com o mesmo certificado que o aplicativo declarado para a permissão. No caso dos certificados correspondentes, o sistema concede, automaticamente, a permissão sem notificar o usuário ou pedir a aprovação explícita do usuário. |
| signatureOrSystem | A permissão dos subsídios do sistema são apenas para aplicativos que estão na imagem do sistema Android, ou para aqueles que são assinados com o mesmo certificado que o aplicativo declarante da permissão. Por favor, evite usar esta opção, porque o nível de proteção da assinatura deve ser suficiente para a maioria das necessidades, e trabalhar independentemente de onde os aplicativos são instalados. O signatureOrSystem é usado para certas situações especiais, e vários fornecedores têm aplicações construídas em uma imagem do sistema e precisam compartilhar recursos específicos explicitamente, porque eles estão sendo construídas em conjunto. |
Isso fez com que os desenvolvedores do Android acreditassem que apenas as aplicações do sistema ou aplicativos com a mesma assinatura (provavelmente criado pelo mesmo desenvolvedor), podem acessar essas permissões. Devido a isso, o controle de acesso adicional pode não ter sido implementado. Porém, esse não é o caso. O que precisa ser enfatizado é que o sistema operacional Android mantém o controle dessas permissões personalizadas, utilizando apenas seus nomes.
Definição de Permissões, Proteção de Dados e Instalação de App Malicioso
Uma vez que uma permissão é definida, outros aplicativos não podem modificá-los. Suponhamos que um app "bem conhecido A" definiu a permissão A com um nível de proteção da assinatura, a fim de proteger os seus próprios dados. No entanto, vamos supor que antes de instalar A, o usuário tenha instalado um aplicativo malicioso B. Se B é projetado para roubar informações do app legítimo A, seria criada a permissão-A antes de "A" ter a chance de criá-la, em seguida à aplicação "B" pode ser concedida a permissão-A. Uma vez que a aplicação "A" for instalada, "B " terá a permissão para ler os dados protegidos da aplicação "A" .
Foram encontradas cerca de 10.000 aplicativos que estão em risco para esta vulnerabilidade. Dessa forma, os pesquisadores da Trend Micro não estão divulgando quais aplicativos estão imediatamente vulneráveis, mas uma rápida verificação que foi feita em relação aos de aplicativos vulneráveis incluem:
- Uma popular store, com vazamentos de seu histórico de navegação online; Um aplicativo de chat popular, além de vazamentos em app de compras do usuário, e da popularidade das redes sociais contendo mensagens falsas inseridas através do seu aplicativo.
Vale ressaltar que os desenvolvedores não devem se basear exclusivamente, nos níveis de proteção quando as suas atividades/ Receivers /Serviços/ Provedores forem acessados. Além disso, diversas funções como getCallingUid e getCallingPackage são fornecidas pelo sistema operacional, e podem ser utilizadas para identificar quaisquer aplicações e implementar controle de acesso, conforme necessário. Em virtude disso, os profissionais da Trend Micro já informaram a equipe de segurança do Google Android sobre este assunto.
Saiba Mais:
[1] Security Intelligence http://blog.trendmicro.com/trendlabs...eak-user-data/