Gregório Patriota Correia
SECURE-COMPAPP: UMA ABORDAGEM PARA APLICAÇÕES
COMPARTIMENTALIZADAS
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
Gregório Patriota Correia
SECURE-COMPAPP: UMA ABORDAGEM PARA APLICAÇÕES
COMPARTIMENTALIZADAS
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Djamel Fawzi Hadj Sadok
RECIFE 2016
Catalogação na fonte
Bibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758
C824s Correia, Gregório Patriota.
Secure-compapp: uma abordagem para aplicações compartimentalizadas / Gregório Patriota Correia. – 2016.
81f.: fig., tab.
Orientador: Djamel Fawzi Hadj Sadok.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2016.
Inclui referências e apêndice.
1. Segurança de dados críticos. 2. Controle de acesso. 3.Comunicação interprocesso. I. Sadok, Djamel Fawzi Hadj. (Orientador). II. Titulo.
Gregório Patriota Correia
Secure-CompApp: Uma Abordagem para Aplicações
Compartimentalizadas
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação.
Aprovado em: 29/07/2016
BANCA EXAMINADORA
__________________________________________________ Prof. Dr. Djamel Fawzi Hadj Sadok
Centro de Informática / UFPE (Orientador)
___________________________________________________ Prof. Dr. Eduardo Luzeiro Feitosa
Instituto de Computação / UFAM
___________________________________________________ Prof. Dr. Rafael Roque Aschoff
I dedicate this dissertation to all my family, friends and professors who gave me the necessary support to get here.
Agradecimentos
Sou grato por todos esses anos nunca ter tido uma jornada solitário. Sempre alguém a me apoiar, motivar e criticar minhas atitudes. Família, amigos e companheiros, sempre me mostrando a razão quando eu menos a enxergava. Encontrar a motivação necessária para continuar não é fácil. Mas todos que me cercavam sempre mostraram que a motivação que eu procurava teria de vir de dentro de mim: "motivação vem de dentro e inspiração vem de fora". Família, amigos e companheiros foram a maior inspiração que precisei.
Agradeço primeiramente a Deus e a minha família: Pai, Mãe e irmãos. Sou muito grato ao meu grupo de trabalho e principalmente as orientações de: Djamel Sadok e Judith Kelner. As equipes com quem trabalhei. Os primeiros passos dados na antiga equipe SEFIN: Thiago Rodrigues, Josias Junior e Rodrigo Melo. A equipe SIRCAM: Ernani Azevedo, Marcos Machado e Daniel Rosendo. Aos que não que não compartilharam projetos mas tiveram grande influência: Wesley Melo. Cada fio de cabelo perdido e também cada novo fio branco que ganhe, cada uma destas marcas mostram o quão loga foi a jornada.
Agradeço também a quem desde pequeno sempre me estimulou a estudar, minha avó. Jamais esquecerei quando ela me perguntava se "esse negócio de consertar computador dá dinheiro?". Sou muito grato por todo o suporte que ela me deu e que muito me ensinou. Agradecimentos em memória de Isaura Barros Patriota.
Por fim, agradeço ao Grupo de Pesquisa em Redes e Telecomunicações (GPRT), ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) e a Universidade Federal de Pernambuco (UFPE).
"Mas nem sempre a fraqueza que se sente quer dizer que a gente não é forte" —GABRIEL CONTINO
Resumo
O uso de códigos monolíticos permite com maior facilidade que um atacante consiga escalar privilégios e a partir de então ter autoridade para executar qualquer tipo de ação maliciosa. O Princípio da Separação de Privilégios propõem mitigar essas vulnerabilidades transformando a estrutura do código monolítico em uma estrutura distribuída que se comunica através de canais interprocessos, desta forma os domínios de cada parte estarão isolados dificultando a escalação de privilégios. Entretanto o uso incauto destes canais de comunicação interprocessos tem sido alvo de novos ataques que exploram tanto as fraquezas dos canais de comunicação quanto as interfaces mal definidas destes processos particionados. Como proposta de mitigar a escalação de privilégio proveniente da exploração destes canais de comunicação este trabalho propõem uma ferramenta de gerenciamento de processos compartimentalizados e seus canais de comunicação interprocesso. A solução apresentada neste trabalho é chamada de Secure-CompApp. Foi avaliado o impacto da solução sobre a performance das aplicações compartimentalizadas e este estudo mostra que a diminuição de performance é justificada por maiores garantias de segurança e rastreabilidade oferecida pela solução Secure-CompApp.
Palavras-chave: Segurança de Dados Críticos. Separação de Privilégio. Monitor de Referência. Políticas. Controle de Acesso. Comunicação Interprocesso
Abstract
Application with any kind of bug or any point with memory leak represent an opportunity for an attacker engage. In the case of some applications implemented with monolithic code, this allows an attacker to escalate privileges of a user easily. The Principle of Least Privilege (PoLP) proposes to mitigate these vulnerabilities transforming the structure of the monolithic code in a distributed structure that communicate through interprocess channels, so the domains of each part will be isolated, making it difficult to privilege escalation. However the incautious use of these interprocess communication channels has been the target of new attacks that exploit the weaknesses of communication channels and the ill-defined interfaces of these partitioned processes. As a proposal to mitigate the privilege escalation from the exploitation of these communication channels this paper proposes a management tool for compartmentalized processes and its interprocess communication channels. The Secure-CompApp is a reference monitor for compartmentalized applications, this is the solution introduced in this paper. The impact of the solution on the performance of compartmentalized applications was evaluated and this study shows that the decrease of performance is justified by the greater guarantees of security and traceability offered by the Secure-CompApp.
Keywords: Critical Safety Data. Privilege Separation. Reference Monitor. Policies. Access Control. Inter-process Communication
Lista de Figuras
1.1 Total de vulnerabilidades nos principais sistemas operacionais . . . 14
1.2 Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais Linux 15 1.3 Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais Microsoft . . . 16
1.4 Aplicação de Principle of Least Privilege (PoLP) a um processo monolítico . . 17
2.1 Esquema de Confinamento de Aplicação com Sandbox . . . 22
2.2 Representação do Confused Deputy Attack . . . 24
2.3 Representação do Collusion Attack . . . 25
2.4 Análise de performance entre os métodos Inter-Process Communication (IPC) dentro do Kernel Linux 2.2.5-15 ao enviar 5000 mensagens . . . 27
2.5 Diagrama de Classe do padrão Monitor de Referência . . . 28
2.6 Diagrama de Sequência do padrão Monitor de Referência . . . 29
4.1 Proposta de Secure-CompApp . . . 41
4.2 Estrutura do Secure-CompApp . . . 42
4.3 Abstração do Secure-CompApp . . . 45
4.4 Máquina de estado do Servidor . . . 46
4.5 Máquina de estado do Cliente . . . 46
4.6 Formato da mensagem de requisição do processo ao monitor de referência . . . 47
4.7 Formato da mensagem de resposta do monitor de referência ao processo . . . . 47
4.8 Formato da mensagem trocada entre os processos . . . 48
4.9 Estrutura organizacional do Organization-based Access Control (OrBAC) . . . 50
5.1 Regras criadas na ferramenta MotOrBAC para o cenário 01 . . . 57
5.2 Cenário simples com a solução Secure-CompApp . . . 57
5.3 Cenário simples sem a solução Secure-CompApp . . . 58
5.4 Cenário extenso com a solução Secure-CompApp . . . 59
5.5 Regras criadas na ferramenta MotOrBAC para os cenários estendidos . . . 60
6.1 Análise de tempo do protocolo de bootstrap . . . 62
6.2 Análise das etapas que compõem o bootstrap . . . 62
6.3 Análise de tempo do protocolo de handshake . . . 64
6.4 Análise de delay das mensagens . . . 65
6.5 Análise das etapas delay das mensagens . . . 66
6.6 Arquivo de log com as ocorrências de fluxo não permitido . . . 68
Lista de Tabelas
2.1 Métodos IPCs mais usados . . . 26
2.2 Esquemas de Controle de Acesso . . . 29
5.1 Parâmetros de simulação no cenário da Figura 5.2 . . . 56
5.2 Parâmetros de simulação para avaliação do delay das mensagens nos cenários das Figuras 5.2 e 5.3 . . . 58
5.3 Parâmetros de simulação para avaliação da escalabilidade no cenário da Fi-gura 5.4 . . . 59
6.1 Estatísticas do bootstrap . . . 61
6.2 Estatísticas do bootstrap: etapa de geração do par de chaves . . . 63
6.3 Estatísticas do bootstrap: etapa do esquema de políticas . . . 63
6.4 Estatísticas do bootstrap: etapa de abertura do canal de comunicação . . . 63
6.5 Estatísticas do protocolo de handshake com Secure-CompApp . . . 64
6.6 Estatísticas do protocolo de handshake sem Secure-CompApp . . . 64
6.7 Estatísticas de delay das mensagens com Secure-CompApp . . . 65
6.8 Estatísticas de delay das mensagens sem Secure-CompApp . . . 65
Lista de Acrônimos
ACL Access Control List. . . 28
AOSP Android Open Source Project. . . 34
API Application Program Interface . . . 33
CVE Common Vulnerabilities and Exposures . . . 14
DAC Discretionary Access Control. . . 49
DoS Denial of Service. . . 53
DHCP Dynamic Host Configuration Protocol. . . 36
GID Group Identifier. . . 27
ICC Inter-Component Communication. . . 33
IDS Intrusion Detection System. . . 15
IMEI International Mobile Station Equipment Identity . . . 35
IPC Inter-Process Communication. . . 25
JNI Java Native Interface. . . 63
JVM Java Virtual Machine. . . 50
MAC Mandatory Access Control. . . 35
MACE Mining Access Control Errors. . . 31
MTL Metric Temporal Logic . . . 34
OrBAC Organization-based Access Control. . . 44
PID Process Identifier . . . 27
PoLP Principle of Least Privilege. . . 16
RBAC Role-based Access Control. . . 49
RPC Remote Procedure Call. . . 33
RSA Rivest-Shamir-Adleman. . . 51
UID User Identifier. . . 27
Sumário
1 Introdução 14
2 Conceituação 19
2.1 Privilégios e a Vulnerabilidade de Ganho de Privilégio . . . 19
2.2 Escalação de Privilégios . . . 19
2.2.1 Escalação Vertical de Privilégios . . . 20
2.2.2 Escalação Horizontal de Privilégios . . . 20
2.3 Princípio de Privilégios Mínimos . . . 20
2.3.1 Paradigmas de Linguagens Object-Capability . . . 21
2.3.2 Confinamento da Aplicação . . . 21
2.3.3 Separação de Privilégios . . . 22
2.4 Ataques de Escalação de Privilégios . . . 23
2.4.1 Confused Deputy Attacks . . . 24
2.4.2 Collusions Attacks . . . 25
2.5 Comunicação entre Processos . . . 25
2.6 Padrão de Projeto Seguro Monitor de Referência . . . 27
2.7 Modelos de Controle de Acesso . . . 29
2.8 Recapitulação . . . 30
3 Estado da Arte 31 3.1 Trabalhos Relacionados . . . 31
3.1.1 Separação de Privilégio em Web Services . . . 31
3.1.2 Separação de Privilégio em Android . . . 32
3.1.3 Separação de Privilégio em Desktop . . . 35
3.2 Discussão . . . 37
3.3 Recapitulação . . . 39
4 Proposta 40 4.1 Estrutura . . . 40
4.2 Contramedidas aos Ataques . . . 43
4.3 Prova de Conceito . . . 44
4.3.1 Módulo Monitor de Referência . . . 45
4.3.2 Módulo de Controle de Processos . . . 49
4.3.3 Módulo de Gerenciamento de Políticas de Controle de Acesso . . . 49
4.3.4 Módulo de Criptografia . . . 50
13 4.4 Discussão . . . 52 4.4.1 Vantagens . . . 52 4.4.2 Desvantagens . . . 52 4.5 Recapitulação . . . 53 5 Avaliação 54 5.1 Metodologia . . . 54 5.1.1 Ambiente . . . 54 5.1.2 Métricas . . . 54 5.1.2.1 Tempo de bootstrap . . . 55 5.1.2.2 Tempo de handshake . . . 55 5.1.2.3 Tempo de delay . . . 55 5.1.2.4 Escalabilidade . . . 55
5.1.2.5 Contramedidas aos Ataques . . . 56
5.1.3 Cenário . . . 56 6 Resultados 61 6.1 Bootstrap . . . 61 6.2 Handshake . . . 64 6.3 Delay . . . 65 6.4 Escalabilidade . . . 67 6.5 Redução de ataques . . . 68
6.5.1 Confused Deputy Attack . . . 68
6.5.2 Collusion Attack . . . 69 6.6 Discussão . . . 69 6.7 Recapitulação . . . 70 7 Conclusão 72 7.1 Contribuições . . . 73 7.2 Trabalhos Futuros . . . 73 Referências 75 Apêndice 79 A Dificuldades Encontradas 80 A.1 Gerenciamento de Threads . . . 80
A.2 Gerenciamento de canais IPC . . . 80
14 14 14
1
Introdução
Atualmente está cada vez mais acessível aos usuários dispositivos compactos com alto poder de processamento. A indústria de hardware tem crescido bastante e com isto alavancando junto a indústria de software. Esta alta acessibilidade e o alto poder de processamento dos dispositivos deram margem para o desenvolvimento de aplicações mais robustas, provendo assim uma variedade de serviços aos usuários. Entretanto, além das vantagens agregadas, estas aplicações têm estado mais expostas a vulnerabilidades e isto tem levantado grandes preocupações com a segurança destes dispositivos e das suas aplicações.
O Common Vulnerabilities and Exposures (CVE) é um sistema que detém uma base de dados com as ameaças e vulnerabilidades catalogadas. Esta entidade tem apontado para um aumento significativo das vulnerabilidades que intentam a segurança tanto dos sistemas operacionais baseado em Microsoft (CVE,2015a) quanto os sistemas operacionais baseado em Linux (CVE,2015b).
Figura 1.1: Total de vulnerabilidades nos principais sistemas operacionais
Fonte: Adaptado deCVE(2015b) eCVE(2015a)
A Figura 1.1 nos mostra a quantidade de vulnerabilidades por ano dos dois principais sistemas operacionais lado a lado, estes valores foram coletados de 1999 até Julho de 2016.
15 Através da leitura deste gráfico é possível observar pequenas oscilações nas quantidades de vulnerabilidades ao longo dos anos que tem apontado para um crescimento no total de vulnerabi-lidades. Isto é perceptível pelo montante de vulnerabilidades presentes nos primeiros anos (entre os anos de 1999 e 2001) ser inferior ao montante de vulnerabilidades presentes nos últimos anos (entre os anos de 2013 e 2015).
Há um conjunto de ferramentas que visam mitigar estas vulnerabilidades relatadas, ferramentas estas como por exemplo: Intrusion Detection Systems (IDSs), Firewalls e Antivírus. Os Antivírus (Chionis; Nikolopoulos; Polenakis,2013) e os IDSs (Ashoor; Gore,2011) possuem um esquema de detecção baseado na assinatura da anomalia, sendo então eficientes para combater malwarespreviamente conhecidos nos hospedeiros. Além disto, os IDS também podem combater estes malwares com base na análise de um comportamento anômalo. Já os Firewalls (Wool,
2004) são definidos como o pilar da segurança das intranets corporativa.
Contudo, estas ferramentas citadas não possuem grande eficiência em situações que a falha está dentro da própria aplicação, como por exemplo: bugs e vazamento de memória. A vulnerabilidade de Ganho de Privilégio é proveniente de falhas como estas que permitem o vazamento de informações ou comprometam o funcionamento do resto da aplicação. Esta vulnerabilidade permite que seja executado um ataque de escalação de privilégio, onde o atacante consegue ter acesso não autorizado a um conjunto de privilégios (Provos; Friedl; Honeyman,
2003). No pior dos casos podendo escalar privilégios de administrador do sistema.
O CVE nos mostra também que a vulnerabilidade de ganho de privilégio está sempre presente nos sistemas operacionais Linux (Figura 1.2) e Microsoft (Figura 1.3) ao longo dos anos.
Figura 1.2: Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais Linux
Fonte:CVE(2015b)
De acordo com a base de dados do CVE as vulnerabilidades de ganho de privilégio correspondem a cerca de 10% do total de ameças catalogadas. O ponto mais crítico com relação
16
Figura 1.3: Total de Vulnerabilidades x Ganho de Privilégio nos sistemas operacionais Microsoft
Fonte:CVE(2015b)
a esta vulnerabilidade são os danos que ela pode vir a causar, pois um ataque bem sucedido a este tipo de vulnerabilidade pode comprometer todo o sistema operacional do hospedeiro.
Contra este tipo de vulnerabilidade é aplicado o Principle of Least Privilege (PoLP) (Saltzer; Schroeder, 1975). Este princípio relata que cada ação deve receber o mínimo de privilégio necessário para que possa ser executado sem comprometer a integridade de qualquer outra ação que execute no mesmo ambiente. Ele não só aumenta a segurança contra ataques de malwaresmas também protege o resto do sistema contra bugs e vazamentos de dados dentro da aplicação.
O PoLP separa os privilégios de uma aplicação dentro de domínios isolados. Assim cada domínio detém um conjunto reduzido de privilégios que passam a ser interligados via canais de comunicação (Gukda et al.,2012).
Por exemplo (Figura 1.4), há uma aplicação que detém uma estrutura monolítica, ou seja, ela aglomera em uma mesma região de memória todas as ações, recursos e privilégios da aplicação. Ao aplicar o PoLP os domínios de cada privilégio passam a ficar isolados das demais ações, ficando confinados em partes (compartimentos) distintas. A aplicação deste princípio classifica as partes como: a parte privilegiada e a parte não privilegiada (Provos; Friedl; Honeyman,2003). É possível aumentar a granularidade da separação e isolar cada vez mais um menor conjunto de privilégios por mais partes (compartimentos), conforme pode ser visto na Figura 1.4.
Devido a sua importância contra ataques de escalação de privilégios, há muitos trabalhos na literatura que focam em ferramentas automatizadas para a aplicação do PoLP. Como exemplo há uma ferramenta que mostra conseguir minimizar os privilégios de uma aplicação a 22% (Wu et al., 2013). Todavia, alguns autores tem alertado sobre os problemas associados a compartimentalização das aplicações.
17
Figura 1.4: Aplicação de Principle of Least Privilege (PoLP) a um processo monolítico
Fonte: Do autor
Em (Gukda et al.,2012) é exposto que aplicações mais compartimentalizadas (maior nível de granularidade) impõem dificuldades nas fases de desenvolvimento, depuração e manute-nibilidade do software. Além disto, há vulnerabilidades que podem comprometer a aplicação devido ao uso incauto dos canais de comunicação (Trapp; Rossberg; Schaefer,2015).
O CVE apontou nos últimos anos o surgimento de ataques de escalação de privilégio que ocorreram através de canais de comunicação (CVE,2011a,b,2013,2015c). Este uso incauto de canais de comunicação também é salientado por (Bugiel et al.,2012) que apontou dois ataques desenhados contra aplicações que implementam o PoLP: Confused Deputy Attack (Hardy,1988) e Collusion Attack (Marforio et al.,2011). Sendo o Confused Deputy Attack um ataque que explora falhas nas interfaces de comunicação (interfaces confusas) de aplicações privilegiadas. Enquanto que o Collusion Attack trata-se de ataque onde o encadeamento de várias permissões possibilita o atacante executar ações além dos seus privilégios individuais. Ambos os ataques visam explorar falhas através das interfaces de comunicação.
Ou seja, o PoLP visa mitigar os ataques de escalação de privilégio, entretanto o uso des-cuidado dos canais de comunicação entre as partes acabou gerando outro ponto de falha. Assim, este trabalho tem como foco mitigar os ataques provenientes das interfaces de comunicação.
18
Joosen,2009). Ela foi chamada de Secure-CompApp e constitui um método para estruturação de uma aplicação compartimentalizada que visa mitigar os ataques de escalação de privilégio decorrentes das interfaces de comunicação.
O principal objetivo deste trabalho é mitigar os ataques de escalação de privilégio, ata-ques estes que advém de falhas nos canais de comunicação das aplicações compartimentalizadas. Foi proposto o uso de um elemento intermediário entre os processos de uma aplicação comparti-mentalizada, sendo este elemento capaz de interceptar as interações destes processos e operar como um elemento de controle de acesso.
Este elemento centralizado atua como um monitor de referência dedicado à uma aplicação compartimentalizada. Sua principal função é de gerenciar os canais de comunicação estabelecidos entre os processos de uma aplicação, além disto ele também fica incumbido de garantir segurança às interfaces, aos dados trocados e aos processos compartimentalizados.
Esta dissertação está estrutura de forma que no Capítulo 2 disserta-se sobre os conceitos da área de pesquisa. O Capítulo 3 traz o estado da arte e em seguida o Capítulo 4 discorre sobre a solução proposta, além de detalhar sobre a ferramenta desenvolvida como prova de conceito da proposta. O Capítulo 5 apresenta a metodologia do trabalho seguido pelos resultados coletados no Capítulo 6. As considerações finais são apresentadas no Capítulo 7.
19 19 19
2
Conceituação
Primeiramente neste capítulo serão descritos os conceitos mais importantes da área de separação de privilégio, conceitos estes fundamentais para o entendimento da aplicação do PoLP.
Em seguida serão descritos conceitos que fundamentaram a solução Secure-CompApp, conceitos como o do padrão de segurança monitor de referência, modelos de controle de acesso e canais de comunicação inter-processos.
2.1
Privilégios e a Vulnerabilidade de Ganho de Privilégio
Privilégio é definido (Provos; Friedl; Honeyman,2003) como um atributo de segurança que é requisitado por alguma operação. Assim, os privilégios concedidos são como limitantes de acesso que um usuário pode ter a arquivos ou códigos, por exemplo. Um privilégio não é algo único e pode ser usado por várias entidades.
Já uma vulnerabilidade é definida como a intersecção de três elementos: a falha no sistema, o acesso do atacante a falha e a capacidade do atacante explorar a falha (Chen; Tian,
2015). Assim, uma vulnerabilidade de ganho de privilégio é um ponto de falha que permite que um usuário não autêntico tenha acesso de forma não autorizada a um conjunto de privilégios.
2.2
Escalação de Privilégios
Escalação de Privilégio é um tipo de ataque em que o invasor obtém privilégios perten-centes a outro usuário, com o objetivo de adquirir maiores níveis de privilégios. Ele visa obter acesso a recursos que seriam por padrão protegidos de um conjunto de usuários ou aplicações, seja por meio de vulnerabilidades em softwares em execução ou até mesmo no próprio sistema operacional.
Há duas possíveis classificações para ataques de escalação de privilégios (Monshizadeh,
2.3. PRINCÍPIO DE PRIVILÉGIOS MÍNIMOS 20
2.2.1
Escalação Vertical de Privilégios
Também conhecido como Elevação de Privilégio, ocorre quando um usuário (ou processo) de menor privilégio no sistema tem acesso a recursos alocados exclusivamente para um usuário (ou processo) de maior privilégio no sistema. Em um pior cenário o atacante pode escalar os privilégios de administrador do sistema (root), tendo assim controle total sobre o hospedeiro e podendo instalar rootkits ou até modificar funções de mais baixo nível do sistema.
2.2.2
Escalação Horizontal de Privilégios
Uma escalação horizontal de privilégio ocorre quando um usuário com um dado nível de privilégio acessa dados e recursos de terceiros, cujo o nível de privilégio é o mesmo. Por exemplo em um cenário com dois usuários com o mesmo nível privilégio: usuário A e usuário B. O usuário A acessa funções e recursos alocados apenas para o usuário B.
2.3
Princípio de Privilégios Mínimos
O Princípio do Menor Privilégio, ou PoLP, é também conhecido como Princípio de Privilégios Mínimos ou Princípio da Menor Autoridade (Saltzer; Schroeder,1975). Na primeira publicação sobre este princípio, Saltzer et al. afirmam que “cada programa e cada usuário privilegiado do sistema deve operar utilizando o menor conjunto de privilégios para completar o trabalho”. Em outras palavras, ele fala que para cada usuário, ou ação, ou até mesmo comando deve receber o mínimo de privilégio necessário para que possa ser executado sem comprometer a integridade de qualquer outra ação que execute no mesmo ambiente.
A ideia consiste em aumentar a granularidade dos processos de uma aplicação para que cada ação seja representada por um componente especializado dentro da aplicação, assim cada componente especializado irá possuir um nível próprio e mínimo de privilégio para executar as ações contidas no componente.
Este princípio minimiza os danos causados por um ataque de escalação de privilégio a partir do momento que a quantidade de privilégios de cada entidade é reduzida. Assim, o PoLP não só aumenta a segurança contra ataques de malwares mas também protege o resto do sistema contra bugs e vazamentos de dados dentro da aplicação. Além disto, este princípio aumenta a rastreabilidade (Bittau; Marchenko,2008) ajudando ao desenvolvedor a auditar o código e descobrir de onde surgiu a falha.
O PoLP propõem-se a prevenir que um usuário não autorizado tenha acesso à funções e/ou recursos extras. O objetivo é limitar a quantidade de privilégio fornecido a uma determinada ação minimizando assim os possíveis danos causados pela ação de algum malware. Existem algumas formas de garantir um isolamento seguro de recursos: uso de Linguagens Seguras baseadas em Capabilities e Confinamento da Aplicação, por exemplo. Porém estas abordagens mostram-se ortogonais à Separação de Privilégios, que é o foco deste trabalho.
2.3. PRINCÍPIO DE PRIVILÉGIOS MÍNIMOS 21
2.3.1
Paradigmas de Linguagens Object-Capability
São linguagens desenhadas para provê segurança, pois o seu uso permite que os progra-madores apliquem o PoLP aos programas (Mettler; Close,2010). Neste paradigma todos os estados de um programa estão contidos dentro de objetos que não podem ser escritos e nem lidos diretamente, é necessário fazer uso de uma referência para aquele objeto.
Tais referencias criadas são definidas de uma forma que não é possível ignora-las e ter acesso direto aos objetos. Há uma gama de linguagens que fazem uso deste paradigma e que são utilizadas em sistemas operacionais específicos que também fazem uso deste paradigma.
Seguem os sistemas operacionais que implementam o modelo de object capability: KeyKOS, EROS, Integrity, CapROS, Coyotos, seL4, OKL4 e Fiasco.OC.
Seguem as linguagens que implementam o object capability: Act 1 (1981), Eden (1985), Vulcan (1986), Emerald (1987), Trusty Scheme (1992), W7 (1995), Joule (1996), Original-E (1997), E (1998), J-Kernel (1999), Oz-E (2005), Joe-E (2005), CaPerl (2006), Emily (2006) e Caja (2007).
2.3.2
Confinamento da Aplicação
Um forma de limitar o alcance a recursos por uma aplicação é executa-lo dentro de um ambiente isolado, um sandbox. Desta forma os recursos acessíveis estarão sempre contidos naquela região delimitada (Schreuders; Payne; McGill,2013). Confinando as aplicações dentro de uma região limitada é possível reduzir os danos causados por um ataque bem sucedido de escalação de privilégio.
Nesta abordagem é relatado que os efeitos de um programa em execução dentro de um sandboxé completamente isolado dos recursos externos, ou seja, tais recursos externos o sandbox não possuí autoridade para atuar. Assim, aplicações restritas em sandbox mitigam ataques dado que os privilégios/recursos da aplicação estão limitados a apenas a aquela região de memória.
Um dos problemas relatados pelos autores é que esta abordagem requer uma redundância significante dos recursos contidos em um sandbox. No caso do uso de máquinas virtuais que envolvem duplicação de todo o sistema operacional, há um grande overhead no gerenciamento das configurações das máquinas virtuais.
A Figura 2.1 representa esta abordagem de confinamento de aplicações. Na figura, a aplicação A inicia a aplicação B que está confinada dentro de um sandbox. A aplicação B pode acessar os recursos dentro do sandbox, entretanto ela não pode acessar os recursos que estão fora do escopo do sandbox. Já as aplicações que não estão contidas dentro do sandbox (aplicação A) não são sujeitas às mesmas regras de controle de acesso, sendo então livres para acessar todos os recursos fora do escopo, inclusive os recursos do sandbox também.
2.3. PRINCÍPIO DE PRIVILÉGIOS MÍNIMOS 22
Figura 2.1: Esquema de Confinamento de Aplicação com Sandbox
Fonte: Adaptada deSchreuders; Payne; McGill(2013)
2.3.3
Separação de Privilégios
A técnica que separação de privilégio é a mais aplicada dentre as citadas anteriormente, por não depender de nenhum tipo de recurso extra para ser aplicado. Esta técnica divide o código em duas partes: sendo uma parte detentora de privilégios e outra sem privilégios, respectivamente definidas como: Monitor e Escravo (Provos; Friedl; Honeyman,2003). Podendo estar presente desde a camada mais baixa em um sistema operacional até no ato de desenvolvimento de uma aplicação de software.
Sua forma mais eficiente é implementada na arquitetura de um sistema operacional, sendo intrínseco no sistema, ao invés de um recurso de software extra (Perrin, 2009). Nos sistemas operacionais baseados em Linux as ferramentas setuid() e setgid() são responsáveis pela separação de privilégio no ambiente.
No nível da aplicação, uma aplicação que passou pelo processo de separação de privilégio é compartimentalizada em processos independentes. Assim, seus domínios passam a ficar isolados uns dos outros e cada processo passa a conter um conjunto reduzido de privilégios.
Existem duas formas de aplicar a separação de privilégios em uma aplicação, Manual ou Automatizada. A classe de mecanismos Automatizados é subdividida em Automáticos de Análise Estática e Automáticos de Análise Dinâmica.
O método manual de separação de privilégio é aplicado no ato de desenvolvimento do software. O desenvolvedor fica responsável por estruturar o sistema de forma a isolar os domínios de cada processo. Há um conjunto de padrões de projeto (Hafiz; Adamczyk; Johnson,
2012) que quando bem aplicados garantem processos compartimentalizados com isolamento de domínio (Seção 2.6). Todavia, o uso de métodos manuais de separação de privilégios demonstram ser complexos, exigindo do desenvolvedor um alto conhecimento e cuidados no ato
2.4. ATAQUES DE ESCALAÇÃO DE PRIVILÉGIOS 23 do desenvolvimento (Gukda et al.,2012).
Já os métodos automáticos são ferramentas com intuito de executar a separação para o desenvolvedor. O nível de interação com o desenvolvedor é mínimo e a granularidade é limitada a ferramenta. Estes métodos surgiram como forma de diminuir a responsabilidade do desenvolvedor em executar a separação de privilégios. As ferramentas automáticas são classificadas em dois grupos de acordo com o tipo de análise. No grupo dos analisadores automatizados estáticos a ferramenta de separação de privilégio é aplicada ao código fonte. Enquanto o grupo dos analisadores automatizados dinâmicos é executada sobre o sistema em tempo de compilação.
Há uma outra abordagem onde o privilégio de um processo é elevado apenas no instante em que ele deve executar a ação que requer o dado privilégio e ao fim da ação os privilégios são revogados para aquele processo, o Privilege Bracketing é utilizada nos sistemas operacionais Solaris (Brunette,2007).
Os exemplos mais conhecidos e bem sucedidos de aplicações que implementam a separação de privilégio são a implementação do SSH (Lonvick; Ylonen,2006) o OpenSSH (OpenBSD,2009) e o navegador Google Chrome (Geneiatakis et al.,2012).
Para se proteger de vulnerabilidades provenientes de suas extensões o Google Chrome (Carlini; Felt; Wagner,2012) tem em sua estrutura um mecanismo de separação de privilégio que divide cada extensão entre: content scripts e core extension. Estas duas partes são executadas em processos distintos que se comunicam via um canal de comunicação autenticado. A proposta de sua arquitetura é proteger a parte privilegiada core extension da parte mais susceptível a ataques e que não necessita de privilégios, o content script.
Já o OpenSSH (Provos; Friedl; Honeyman,2003) é uma ferramenta que provê acesso remoto seguro através da internet. Algumas de suas etapas necessitam de privilégio de root para serem executadas, entretanto essas etapas devem estar isoladas de forma que o usuário remoto não tenha acesso direto a elas.
Assim, no OpenSSH para cada nova conexão remota estabelecida é necessário um conjunto processos de privilegiados para: gerenciar os pseudo terminais para o usuário, autenticar o processo de troca de chaves, criar novos processos privilegiados para o usuário autenticado, etc. A estrutura do OpenSSH é dividida em três processos: um processo monitor e dois processos escravos. O processo monitor fica responsável por confinar todos os privilégios da ferramenta enquanto que a interação com o usuário remoto é executada via os dois processos escravos: um gerencia o processo de autenticação e o outro escravo gerencia os pseudo terminais do usuário autenticado.
2.4
Ataques de Escalação de Privilégios
O PoLP surgiu visando melhorar a segurança dos softwares, entretanto para burlar este princípio também surgiram ataques com o intuito unicamente de escalar privilégios das aplicações
2.4. ATAQUES DE ESCALAÇÃO DE PRIVILÉGIOS 24 que passaram pelo processo de separação de privilégios. Trata-se de: Confused Deputy Attacks (Hardy,1988) e Collusions Attacks (Marforio et al.,2011).
A partir do momento que a aplicação é compartimentalizada e seus domínios são isolados do resto, são as interfaces de comunicação que passam a ser o novo ponto de falha que podem conceder a escalação de privilégios.
2.4.1
Confused Deputy Attacks
O Confused Deputy Attack refere-se a um ataque que explora falhas nas interfaces de comunicação de aplicações privilegiadas (Bugiel et al., 2012). Recorrente em aplicações compartimentalizadas com interfaces de comunicação mal definidas, onde não há um conjunto de regras e restrições que delimitem o acesso a esta interface de comunicação.
Através de sucessivas requisições, partindo de um elemento não autentico para um processo privilegiado, um atacante espera que uma de suas requisições possa vir a ser respondida pelo processo privilegiado com algum tipo de informação ou recurso protegido.
Figura 2.2: Representação do Confused Deputy Attack
Fonte: Do autor
Exemplificando com a Figura 2.2, em um cenário onde uma aplicação detém alguns privilégios e os demais não, as ações privilegiadas são então delegadas para a aplicação privilegi-ada. Caso as interfaces de comunicação entre o elemento privilegiado e não-privilegiado não estejam bem definidas o elemento privilegiado é então denominado de processo confuso. Assim o Confused Deputy Attack ocorre quando uma aplicação maliciosa tenta explorar as interfaces de uma aplicação detentora de privilégios, conforme ilustrado na Figura 2.2.
2.5. COMUNICAÇÃO ENTRE PROCESSOS 25
2.4.2
Collusions Attacks
O Collusions Attack é um ataque malware bastante sofisticado e de difícil detecção (Baraiya; Diwanji,2015). Este ataque permite que aplicações (ou processos) executem operações indiretamente que eles não deveriam ser capazes de executar com base nas suas permissões declaradas.
Assim, o Collusion Attackt trata-se de ataque onde são encadeadas várias permissões que possibilitam um atacante executar ações além dos seus privilégios individuais.
Figura 2.3: Representação do Collusion Attack
Fonte: Adaptado deBugiel et al.(2011)
A Figura 2.3 ilustra um cenário formado por três aplicações com duas ações permitidas definidas entre as aplicações. Todavia, há uma ação possível neste cenário que não foi definida como uma ação permitida. O conluio das duas ações permitidas acaba possibilitando que a aplicação 01 tenha acesso aos componentes da aplicação 03 através da aplicação 02.
2.5
Comunicação entre Processos
Os ataques anteriormente citados (Seção 2.4), assim como outros citados pelo CVE (CVE,2011a,b,2013,2015c), foram ataques que ocorrem via os canais de comunicação dessas aplicações compartimentalizadas. Esses canais de comunicação entre processos e aplicações são conhecidos como Inter-Process Communication (IPC).
IPC é um mecanismo de compartilhamento de dados entre processos, que permite que processos isolados possam interagir. Há várias formas de se estabelecer um canal IPC entre as partes, como por exemplo: mensagens, arquivos, região de memória comum, etc. Em geral os IPCs possuem uma aplicabilidade local, ficando restrito ao ambiente de domínio do sistema operacional, entretanto, há implementações que garantem interações entre processos que não estão alocados no mesmo hospedeiro.
Sendo fundamental para a decomposição de sistemas em domínios distintos e protegidos, as aplicações nas quais o PoLP foi aplicado fazem largo uso deste mecanismo. Desta forma a comunicação entre os processos isolados é garantida.
2.5. COMUNICAÇÃO ENTRE PROCESSOS 26
Tabela 2.1: Métodos IPCs mais usados
Método Descrição
Pipe Estabelece um canal por onde o fluxo de dados irá passar definindo qual o processo detém o padrão de escrita e qual processo detém o padrão de leitura no canal. Porém, apenas um carácter é lido por vez.
Mensagem A comunicação entre os processos é feita através das filas de mensagens do Sistema Operacional. É possível desta forma a interação entre múltiplos processos sem estar necessariamente conectados uns aos outros.
Memória Compartilhada Uma determinada região de memória volátil é alocada para que dois ou mais processos tenham permissão de leitura e escrita, isto possibilita a interação entre múltiplos processos.
Socket Provê um canal de comunicação além do mesmo hospedeiro. O fluxo de dados é enviado através da interface de rede, permitindo assim que os processos estejam alocados no mesmo hospedeiro ou até em hospedeiros diferentes da rede.
Sinal Sem objetivo de transmitir dados, os sinais constituem um sistema de mensagens enviadas entre processos que transmitem comandos remotos.
Semáforo Meio de sincronização de recursos entre múltiplos processos. Esta estrutura permite compartilhar recursos entre múltiplos processos de forma síncrona.
2.6. PADRÃO DE PROJETO SEGURO MONITOR DE REFERÊNCIA 27
Figura 2.4: Análise de performance entre os métodos IPC dentro do Kernel Linux 2.2.5-15 ao enviar 5000 mensagens
Fonte: Adaptado deImmich; Bhagavatula; Pendse(2003)
A Tabela 2.1 dispõem dos métodos mais comuns (Stevens; Fenner; Rudoff, 2004) utilizados nas implementações. Cada um dos métodos possui características diferentes de desempenho (vide Figura 2.4), porém é relatado que esses mecanismos não possuem por padrão fortes rotinas de segurança (Stevens; Rago,2013;Lidie; Walsh,2002).
Tratam-se de rotinas de autenticação entre o lado cliente e o lado servidor onde eles trocam elemento de identificação única. Como no caso do sockes IPC que possui um mecanismo padrão autenticação onde através do canal o cliente envia para um servidor suas credenciais (Kerrisk et al.,2009), uma tupla com identificadores únicos: Process Identifier (PID), User Identifier(UID) e Group Identifier (GID). Este processo de autenticação ocorre durante a troca da primeira mensagem entre cliente e servidor, porém isto não evita que um atacante forje estes parâmetros e nem impede que qualquer processo consiga obter conexão com o dado servidor.
2.6
Padrão de Projeto Seguro Monitor de Referência
Especificado como um padrão de segurança (Hafiz; Adamczyk; Johnson, 2012), o monitor de referência é um módulo que detém o conhecimento das ações do seu domínio. Idealmente todo o tráfego de pacotes, sinais, chamadas remotas, e etc., deve passar pelo monitor, pois ele é responsável por restringir ou liberar o acesso de processo e/ou usuários à operações do sistema através da aplicação de políticas. Este padrão impõem que um monitor de referência deve satisfazer os seguintes requisitos (Rooker,1993):
Ser um mecanismo de controle de acesso Ser um mecanismo de autorização Prover execução controlada
2.6. PADRÃO DE PROJETO SEGURO MONITOR DE REFERÊNCIA 28 O monitor de referência (Jaeger,2011) também pode ser definido como um mecanismo de validação que deve:
Mediar as ações no sistema
- O monitor deve ser invocado para toda e qualquer operação
Ser à prova de falsificação
- Um atacante é impossibilitado de burlar as políticas aplicadas
Ser íntegro nas verificações
- O monitor não deve falhar nas rotinas de teste, verificação e aplicação das políticas
O maior exemplo dentre os monitores reais é o Kernel do Linux. Responsável por ser o núcleo de todos os sistemas Linux, o Kernel constitui uma das mais importantes aplicações do padrão Monitor de Referência (Rooker,1993). O Kernel administra as funções dentro do Sistema Operacional sendo responsável por tentar garantir os devidos acessos dos programas aos dados e recursos sem comprometer a integridade do Sistema Operacional. Assim como o Kernel Linux outros sistemas também fazem largo uso deste padrão, como por exemplo o sistema operacional mobile Android.
O Design Patterns do Monitor de Referência (Schumacher et al.,2013) é mostrado em um Diagrama de Classe (Figura 2.5) e um Diagrama de Sequência (Figura 2.6). Eles ilustram a estrutura organizacional e a estrutural comportamental de um monitor de referência.
Figura 2.5: Diagrama de Classe do padrão Monitor de Referência
Fonte: Adaptado deSchumacher et al.(2013)
As regras de autorização, no diagrama de classe, representam um conjunto organizado de regras que tanto pode ser um Access Control List (ACL) ou qualquer outra estrutura organiza-cional, visto na Figura 2.5.
2.7. MODELOS DE CONTROLE DE ACESSO 29
Figura 2.6: Diagrama de Sequência do padrão Monitor de Referência
Fonte: Adaptado deSchumacher et al.(2013)
Quando um processo corrente requisita acesso a um recurso tal requisição deve passar pela análise do Monitor de Referência, vide Figura 2.6. O monitor verifica a existência de uma regra de autorização para aquela requisição, caso exista então a requisição de acesso é autorizada e o processo corrente obtém acesso ao recurso desejado.
2.7
Modelos de Controle de Acesso
No mundo físico controle de acesso é definido por rotinas que a partir de credencias de identificação é determinado se um indivíduo tem acesso ou não a um recurso. Usado para aplicar proibições ou permissões, os mecanismos de controle de acesso são muito utilizados na computação. Quando pretende-se aplicar restrições quanto ao uso de um recurso do hospedeiro, o mecanismo de controle de acesso deve intermediar uma requisição de acesso ao recurso e prover como resposta se o acesso é permitido ou proibido (Samarati; Capitani,2001). A partir das políticas de controle de acesso é possível classificar os modelos de controle de acesso como dispostos na Tabela 2.2.
Tabela 2.2: Esquemas de Controle de Acesso
Esquema Descrição
DAC Utiliza a identidade do processo/usuário que requisita a ação como o único elemento para restringir ou liberar a ação. O termo discricionário diz que o usuário tem a capacidade de transmitir seus privilégios para outro sujeito. MAC As regras aplicadas baseado em mandatos de uma entidade central para
restrin-gir um processo/usuário de operar sobre um determinado objeto/recurso. RBAC As regras são aplicadas para um grupo de usuários/processos definidos por uma
função/papel dentro da organização. Mais flexível que os modelos anteriores. OrBAC É uma expansão do modelo anterior, inserindo o conceito de organização além
2.8. RECAPITULAÇÃO 30 O controle de acesso baseado em políticas demonstra conceitos poderosos de autenticação e autorização. Quando o modelo possui regras bem formuladas, com uma alta granularidade e sem inconsistências, pode prover um sistema pouco susceptível a vulnerabilidades.
2.8
Recapitulação
Os privilégios concedidos a um processo/usuário são como limitantes de acesso a algum recurso, operando assim como atributos de segurança. Entretanto, vulnerabilidades de ganho de privilégio permitem que atacantes consigam escalar esses privilégios para si, obtendo assim, de forma não autêntica, acesso a recursos antes protegidos.
O PoLP minimiza os danos causados pelos ataques de escalação de privilégios por reduzir a quantidade de privilégios de cada entidade susceptível a estes ataques. A aplicação do PoLP pode ser executada através técnicas como: Linguagens Seguras baseadas em Capabilities, Confinamento de Aplicações ou Separação de Privilégios.
Como o uso deste princípio mitiga os ataques de escalação de privilégio, foram então criadas contramedidas pelos atacantes. Foram desenhados ataques contra aplicações que im-plementam o PoLP para obter vantagens de suas estruturas, são: Confused Deputy Attack e Collusion Attack.
Por fim, neste capítulo também foram introduzido os conceitos do padrão de projeto seguro monitor de referência, os modelos de controle de acesso, além dos conceitos sobre os canais de comunicação IPCs. Estes são conceitos fundamentais para a proposta deste trabalho (Capítulo 4).
No capítulo seguinte, será dissertado sobre os trabalhos mais recentes que aplicam a técnica do PoLP.
31 31 31
3
Estado da Arte
Os trabalhos mais atuais encontrados na área estão dispostos em três grandes ambientes: web, desktop e Android. A seguir, foram sumarizados estes trabalhos e classificados para cada um dos três grandes ambientes. Por fim, a seção de discussão (Seção 3.2) trata das vantagens e desvantagens destes trabalhos.
3.1
Trabalhos Relacionados
3.1.1
Separação de Privilégio em Web Services
O WebJail (Van Acker et al., 2011) é um trabalho que foca no lado cliente de uma aplicação web. O WebJail constitui uma camada de políticas dentro do browser para evitar que componentes maliciosos provenientes de Mashup’s1possam vir a escalar privilégios do usuário.
Os autores inseririam dentro do browser Mozilla Firefox uma camada de políticas e um elemento que intermedeia as chamadas de funções dos mashup’s e aplica as políticas definidas. Sobre o WebJail foi feita uma análise de performance e os autores mediram o overhead causado no page load e na execução de funções do browser, criando assim um benchmark para a proposta. Os autores afirmaram ter uma penalidade insignificante de tempo diante da inserção da solução, sendo de 7ms o impacto no page load e de 0.1ms o overhead para cada função no tempo de execução.
Mining Access Control Errors(MACE) (Monshizadeh; Naldurg; Venkatakrishnan,2014) foi uma ferramenta desenvolvida com proposito de detectar a existência de vulnerabilidades dentro do código de uma aplicação que permitissem ataques de escalação vertical e horizontal de privilégios. Esta ferramenta executa análises em busca de inconsistências nas políticas de autorização no lado servidor de uma aplicação web.
Os autores afirmam que para a corretude das aplicações web é preciso verificar cada operação executada. É preciso que exista um arquivo com políticas bem definidas para cada operação que possa ser permitida para um dado usuário. Analisando a interação de uma aplicação
3.1. TRABALHOS RELACIONADOS 32 webcom uma base de dados, o MACE avalia três pontos: o estado da autorização, o contexto da autorização e a consistência do contexto da autorização.
O trabalho relata que as análises são de melhor esforço, mas o grande valor agregado pela ferramenta é a capacidade de detectar falhas ainda desconhecidas. Ou seja, com o uso desta ferramenta nas aplicações web é possível evitar a criação de brechas que podem vir a ser exploradas no futuro.
O Passe (Blankstein; Freedman,2014) é um protótipo para o framework web Django que limita a comunicação entre componentes compartimentalizados. Os autores afirmam que mesmo para aplicações que sejam executadas em ambientes isolados há ataques que exploram os canais de comunicação ou as regiões de memória compartilhada. Assim, o Passe protege os dados entre componentes, limitando as interações para consultas restritas de dados.
O Passe insere um tipo de proxy entre as aplicações e a base de dados, e também um tokenque valida as políticas em vigor por aplicação. Este proxy confiável é responsável por permitir ou proibir as consultas de dados, as ações são tomadas com base em um conjunto de restrições. Assim, cada aplicação, que roda em uma área separada e restrita, tem suas consultas à base de dados intermediadas pelo proxy que checa a validade do token e a política associada.
Os autores avaliaram a vazão e a latência das consultas mas constaram que a inserção do Passe tem um impacto que varia conforme a aplicação usada. Tendo o maior impacto nas aplicações que necessitam de alguma operação de I/O do que para aquelas que interagem com a base de dados. Também foi avaliado o overhead da ferramenta Passes que apresentou ter um consumo excessivo de memória.
3.1.2
Separação de Privilégio em Android
Os autores (Felt et al., 2011) apontaram para os riscos introduzidos pela ameaça de redelegação de permissão. Redelegação de permissão trata-se de um caso especial do confused deputy attack em que uma aplicação detentora de privilégios executa uma ação para uma aplicação sem privilégios. O IPC Inspection foi um mecanismo proposto pelos autores para combater a redelegação de permissões.
Foi implementado um protótipo para o Android 2.2, nele foi adicionado o suporte do IPC Inspectionao PackageManager2e ao ActivityManager3. Estas duas modificações permitem um controle sobre as interações IPC, reduzindo assim os privilégios entre aplicações. Além disto, também foi estendido o formato do manifest Android para limitar as mensagens recebidas pelas aplicações.
Os autores primeiramente avaliaram 872 aplicações Android a fim de demonstrar suas fragilidades diante da redelegação de permissões, constatando que 11 de cada 16 aplicações estão em risco. Já na avaliação da solução IPC Inspection, foram avaliados: eficiência, facilidade
2o PackageManager é responsável por instalar aplicações, armazenar e aplicar as permissões
3.1. TRABALHOS RELACIONADOS 33 no desenvolvimento e performance. Os autores fizeram uma análise qualitativa quanto às métricas avaliadas e afirmaram que o IPC Inspection não impõem restrições no desenvolvimento, conseguindo com baixo impacto evitar todos os ataques de redelegação de permissões.
XMandroid (Bugiel et al.,2011) é um monitor de referência para o Android com um esquema de políticas que controla os canais de comunicação Inter-Component Communication (ICC). Assim, os autores propuseram um framework que estende o monitor padrão do Android. O sistema de políticas proposto reforça o esquema padrão do Android com um conjunto de regras seguras que visam evitar a escalação de privilégios via os canais ICC.
Na estrutura do Android, os autores modificaram o comportamento do monitor de referência, assim, para cada canal de comunicação ICC aberto, o monitor de referência passa a consultar um sistema de decisão do XMandroid que irá permitir ou proibir aquela interação. Os autores atentam que o sucesso na detecção de malwares pela solução depende das políticas definidas, pois regras inadequadas podem vir a gerar novas brechas e afetar o comportamento de aplicações genuínas.
A solução XMandroid foi avaliada utilizando aplicações maliciosas dentro da plataforma Android. Os autores afirmaram que a solução conseguiu detectar ataques de transitividade (Collusion Attacks) entretanto houve um impacto significativo sobre o tempo das chamadas de ICC.
PScout (Wain et al.,2012), ou na forma extensa Permission Scout, foi uma ferramenta desenvolvida para ambiente Android incumbida de analisar as permissões necessárias para uma aplicação a partir do código fonte desta aplicação. Os autores constataram que as aplicações e Application Program Interfaces (APIs) utilizam em média 22% mais permissões do que o necessário, abrindo assim brechas para atacantes explorarem estes privilégios. O PScout é uma ferramenta que reduz o número de permissões desnecessárias nestas aplicações mobile.
A solução utiliza uma ferramenta de bytecode Java para executar a análise estática do código-fonte. A extração de permissões pelo PScout é executada em três etapas. Primeiro, são identificadas todas as checagens de permissões pelo Android. Em seguida é construído um grafo de chamadas de funções incluindo IPC e Remote Procedure Call (RPC). Por fim, é executado uma verificação em sentido contrário sobre o gráfico, onde são encontradas todas as APIs que podem alcançar uma determinada permissão dentro do sistema operacional.
Os autores estimaram a qualidade de solidez e completude da ferramenta sobre a aplicação UI Fuzzer e sobre quatro versões do sistema operacional Android: 2.2, 2.3, 3.2 e 4.0. Sobre a aplicação, os autores mostraram obter precisão na detecção das permissões pela ferramenta. Sobre os sistemas operacionais, os autores mostraram que há pouca redundância nas permissões do sistema, entretanto, é possível encontrar um pequeno conjunto de permissões em APIs não documentadas.
A API AdDroid (Pearce et al.,2012) foi proposta para o sistema operacional Android para separar os privilégios compartilhados entre a aplicação e as bibliotecas de propaganda usadas na aplicação. Os autores afirmam que estas bibliotecas de propaganda têm acesso a
3.1. TRABALHOS RELACIONADOS 34 todos os privilégios da aplicação de forma desnecessária. Assim, o AdDroid usa a separação de privilégios para isolar os privilégios da aplicação e conceder as bibliotecas de propaganda apenas o necessário para operar.
Como prova de conceito foi implementado um protótipo do AdDroid dentro do Android Open Source Project(AOSP) na versão Gingerbread, o AdDroid é formado por três componentes: a região de uso da biblioteca, um novo sistema de serviço Android e as permissões Android. O primeiro componente constitui a interface de interação entre a aplicação e as propagandas, que via chamadas de IPC interage com o componente do sistema de serviço. Este por sua vez, que roda em background, verifica no componente de permissões a existência das permissões de propaganda e então faz a consulta da propaganda na rede. Por fim o resultado obtido é retornado via IPC para o primeiro componente.
Foram analisadas as aplicações do Android Market4e constataram que 46% das aplica-ções que hospedam propagandas tem privilégios em excesso devido ao uso das bibliotecas de propagandas. Com o uso das permissões exclusivas para propagandas inseridas pelo AdDroid foi possível prevenir que as propagandas obtivessem acesso a privilégios extras da aplicação.
Os autores (Gunadi; Tiu,2014) constataram que apesar de estrutura do Android isolar as aplicações e seus recursos um dos outros, as vias de comunicação IPC representavam pontos para os ataques de escalação de privilégio Confused Deputy Attack e Collusion Attack. Os autores desenvolveram como prova de conceito a eficiência no uso de políticas Metric Temporal Logic (MTL) para mitigar estes ataques. Eles propuseram uma extensão para o sistema de políticas do Android que intercepta as chamadas IPC e mitiga os ataques.
O framework Android foi alterado para inserir o algoritmo de monitoramento. Foi adicionado um recurso ao framework que redireciona as checagens de permissões das aplicações para a solução antes da mesma ser passada ao sistema operacional Android. Assim, antes do sistema operacional Android checar em sua base de políticas regras para aquela ação o MTL é executado.
Foram implementadas quatro políticas para interceptar chamadas IPC: a política 1 para bloquear acessos diretos a recursos por aplicações não confiáveis e as demais para bloquear ataques de transitividade. Os autores avaliaram o impacto de tempo causado sobre essas chamadas por cada uma das políticas. Os autores detectaram que a política 1, pela simplicidade do bloqueio, teve um overhead em média de 1ms enquanto que as demais políticas chegaram a dobrar o tempo das chamadas IPC por se tratar de regras mais complexas.
Uma técnica de monitoramento de comportamento anômalo dentro de aplicações foi proposta (Jeong et al.,2014). Os autores relatam que a popularidade do Android impulsionou o surgimento de alguns malwares e variantes de malwares, assim sistemas de detecção baseados em assinaturas, os antivírus, acabam sendo pouco eficientes no combate a estes malwares.
A proposta de monitoramento é constituída de dois módulos. O primeiro monitora os eventos e mensagens IPC/RPC, enquanto que o segundo módulo registra ações maliciosas
3.1. TRABALHOS RELACIONADOS 35 detectadas dentro da aplicação gerenciada. Ambos os módulos foram implementadas dentro do kernelAndroid. Os autores afirmam que desta forma foi possível detectar ataques de escalação de privilégio como confused deputy attack e collusion attack.
A técnica de monitoramento foi avaliada em ambiente real. Os autores implementaram duas simples aplicações a fim de demonstrar a detecção de um ataque de confused deputy. Uma das aplicações foi implementada com permissão para ler o International Mobile Station Equipment Identity(IMEI) enquanto a outra simulou um atacante sem tal permissão. Assim, todas as requisições foram detectadas pelo kernel via as chamadas RPC e registradas em um arquivo de log.
O SEIntentFirewall (Mutti; Bacis; Paraboschi,2015) é um sistema de políticas baseado no SELinux para gerenciar as Intents5trocadas no ambiente Android. O objetivo é prover uma maior granularidade no controle de acesso Mandatory Access Control (MAC) sobre os objetos Intent.
Foi estendido o AppPolicyModules para alcançar e aplicar políticas sobre os objetos Intent. As modificações feitas pelos autores almejam: recuperar o contexto de segurança associado a aplicação e permitir ao mecanismo de controle de acesso do SELinux manusear as permissões definidas para um objeto Intent.
O uso do SELinux no ambiente Android constitui uma etapa importante para serviços de segurança mais flexíveis e robustos. Os autores afirmam que o SEIntentFirewall é um solução extensível que melhora a aplicação de políticas de controle de acesso.
3.1.3
Separação de Privilégio em Desktop
Codejail (Wu et al.,2012) é uma framework para isolamento de bibliotecas não con-fiáveis. Os autores afirmam que é comum fazer uso de bibliotecas de terceiros para auxiliar no desenvolvimento, entretanto estas bibliotecas compartilham do mesmo espaço de memória que a aplicação e podem trazer bugs que comprometem o funcionamento do programa, como vazamento de dados por exemplo.
O protótipo do Codejail foi portado para o Linux. O Codejail atua como uma interface entre a aplicação e a biblioteca utilizada. A biblioteca é enjaulada pelo Codejail, ficando isolada da aplicação. Os acessos às funções da biblioteca são feitas via socket UNIX pelo Codejail, assim as bibliotecas não tem acesso direto à aplicação. Esta estrutura permite ao Codejail ser efetivo contra ataques de corrupção de memória e execução de código arbitrário.
Foi executado um benchmarking do Codejail avaliando o desempenho de quatro bibliote-cas. Foi medido o desempenho nativo das bibliotecas com o Codejail sem confinar a biblioteca e com o Codejail confinando a biblioteca. As quatro bibliotecas avaliadas foram: libpng, libexpat, libbzip2, libtiff. Os autores apontaram que o uso do framework Codejail sem confinar a biblioteca apresentou em alguns casos um overhead menor que 5%.
5Intenté o mecanismo de comunicação usado no Android para troca de informações entre componentes da
3.1. TRABALHOS RELACIONADOS 36 ProgramCutter (Wu et al.,2013) é uma ferramenta de particionamento automático de códigos a partir de uma análise dinâmica das dependências dos dados. Os autores relatam que o uso de técnicas manuais de separação, por ser bastante custosa e levar a muitos erros no ato do desenvolvimento, acaba promovendo ao desenvolvimento de aplicações monolíticas.
A ferramenta ProgramCutter é aplicada em três etapas: Trace Collector, Graph Partitio-nere Source Translator. Na primeira etapa o código monolítico é aplicado ao trace collector que analisa as interações e dependências entre as parte do código através de labels inseridas pelo desenvolvedor. A partir desta análise é criado uma estrutura de grafo que expressa essas interações, assim na etapa do graph partitioner é criar de fato o grafo. Por fim, a etapa de source translatorutiliza o grafo gerado para reescrever o código monolítico com os privilégios separados.
O ProgramCutter foi aplicado às quatro aplicações: OpenSSH, ping, wget e thttpd. Os autores avaliaram para cada uma das ferramentas o overhead de tempo e a capacidade de minimizar os privilégios das aplicações. Com um impacto de menos de 20% no tempo das ferramentas os autores afirmaram ter conseguido minimizar os privilégios de 100% até 22%.
ARBITER (Wang; Xiong; Liu,2013) foi uma API desenvolvida para gerenciar e isolar as regiões de memória compartilhada entre threads de uma aplicação multithreading. Esta API constitui um monitor de referência que fica incumbido de gerenciar essa memória compartilhada entre as threads.
O ARBITER não faz uso de uma ACL mas sim de um conjunto de labels ao longo do código, estas labels são definidas pelo programador para expressar as políticas de segurança da aplicação. Através das labels que é possível dar permissões as threads para operar e como operar em cada região de memória.
Os autores do ARBITER aplicaram a solução sobre a ferramenta memcached e geraram um microbenchmark para quantificar overhead inserido por esta API. Eles chegaram ao resultado de um aumento de 28% no tempo das chamadas das funções do memcached.
Os autores (Trapp; Rossberg; Schaefer,2015) propuseram um método de análise estática de particionamento de código. Trata-se de um particionador que cria uma aplicação comparti-mentalizada com o mínimo de partes não privilegiadas, pois os autores afirmam que a segurança de uma aplicação compartimentalizada depende de dois fatores: o número de compartimentos de uma aplicação e do gerenciamento dos compartimentos não privilegiados.
Os autores formam um grafo a partir de um modelo que avalia quatro métricas: existência de privilégio na função, complexidade desta função, peso do privilégio e o risco agregado à chamadas IPC para aquela função. Por fim, é feito uso de uma heurística que tende a aglomerar todas as partes não privilegiadas dentro de um compartimento, visando assim minimizar as vulnerabilidades agregadas a estes tipos de compartimentos.
Como relatado pelos autores, a ferramenta não estava completa então o processo de decomposição foi feito manualmente sobre udhcpd que é a versão leve do daemon do Dynamic
3.2. DISCUSSÃO 37 Host Configuration Protocol (DHCP) do projeto BusyBox6. Foram feitas duas separações: dentro de dois processos e dentro de cinco processos. Em relação ao processo monolítico, foi constatado um overhead de 5.9% e 11.3%, respectivamente.
3.2
Discussão
Foram apresentados os trabalhos presentes na área de separação de privilégios. Eles foram classificados em três grandes áreas de atuação: ambiente Web, ambiente Android e ambiente Desktop.
Em geral, a grande preocupação dos trabalhos tem sido de propor ferramentas auto-matizadas de particionamento sem atentar para as vulnerabilidades criadas pelos canais de comunicação. Entretanto, calcado pela infraestrutura provida pelo sistema operacional An-droid, alguns trabalhos demonstraram preocupação com os canais IPC e propuseram meios de mitiga-los.
No ambiente web foram destacados três trabalhos: WebJail, MACE e Passe. Apesar de fazerem parte do mesmo ambiente, o ambiente web, cada uma tem uma proposta de atuação bem diferente.
O MACE é uma ferramenta que é aplicada no ato do desenvolvimento do software capaz de detectar brechas na estrutura do código antes desconhecidas, que permitiriam a escalações de privilégios na aplicação. Sua grande vantagem é evitar a criação destas brechas pelo desenvolve-dor, brechas estas que possam vir a comprometer o comportamento da aplicação. Entretanto, é preciso destacar que é exigido do desenvolvedor o conhecimento necessário para corrigir tais falhas, pois a ferramenta se limita a apontar a sua existência. No MACE são feitas checagens das interações permitidas entre a aplicação e uma base de dados. São verificadas as consultas a base e esta é uma característica marcante da solução, pois já aponta para uma preocupação sobre as interações entre partes separadas.
Assim como o MACE, o Passe tem um enfoque na proteção dos fluxos de dados entre compartimentos. Neste trabalho já é percebido uma preocupação com ataques de escalação de privilégio que se sucedem pelas interfaces de comunicação. Apesar do impacto causado no desempenho da aplicação web pela inserção de um elemento intermediário (o proxy), o uso deste mesmo elemento permite agregar mais e melhores rotinas de segurança. Esta vantagem permitiria aos autores prover maiores garantias de segurança aos fluxos de dados.
Por fim, no ambiente web, o WebJail foi uma proposta de modificação na arquitetura dos browsers com a inclusão de uma camada de política capaz de controlar o acesso à recursos das aplicações que rodem no lado da aplicação cliente. Trata-se de um sistema de políticas que gerencia a interação entre as partes confinadas do browser provenientes de aplicações não-confiáveis. Os autores tiveram como grande vantagem um elemento de controle de acesso centralizado que interferiu pouco no tempo de page load pelo browser.
3.2. DISCUSSÃO 38 Vale destacar que dois dos três trabalhos destacados no ambiente web fizeram uso de um sistema de controle de acesso centralizado, intermediando as interações entre compartimentos. Isto é percebido como uma vantagem que provê maior poder de controle dentro de uma solução. Quando se trata do ambiente Android, este sistema operacional introduz uma série de facilidades sobre o controle de permissões de aplicações e controle sobre o fluxo de dados ICC e isto promoveu o desenvolvimento de muitos trabalhos nesta área que aproveitaram esta facilidade. Facilidade esta que não existe para ambientes Desktop ou Web.
Os trabalhos IPC Inspection, XMandroid, MTL, Jeong et al., e SEIntentFirewall são exemplos de trabalhos calcados pelo suporte que o monitor de referência Android detém. Estes trabalhos então propuseram soluções que visavam maior controle sobre o fluxo de mensagens ICC entre aplicação. Foram propostas de módulos e funcionalidades adicionais dentro do monitor de referência padrão do Android que criam ganchos para os canais IPCs e garantem assim a aplicação de políticas que delimitam essas chamadas com maior granularidade. Amparados pela infraestrutura existente no Android as concepções destas soluções são de grande valor, entretanto as ferramentas ficam confinadas no domínio mobile Android.
O trabalho PScout possui uma ideia que lembra o trabalho do MACE proposto para ambiente Web. Eles se assemelham por terem o enfoque em diagnosticar as falhas e vulne-rabilidades em uma aplicação sem atuar e corrigir a mesma. O PScout mostrou que até os sistemas Android ainda estão bastante vulneráveis e permitindo a escalação de privilégios. Já o AdDroid contribuiu bastante demonstrando as falhas ao se compartilhar todas as permissões entre diferentes bibliotecas dentro de uma aplicação. Apesar de ter o enfoque restrito a bibliotecas de propagandas, este trabalho contribuiu bastante, demonstrando falhas na estrutura Android, assim como o PScout.
Por fim, o ambiente Desktop. Os autores que concentraram esforço para este ambiente tendem a propor métodos de particionamento automático de código. Estas soluções visam diminuir a responsabilidade do desenvolvedor de aplicar os padrões de projetos para segurança. Entretanto, as soluções tendem a desmerecer as vulnerabilidades que os canais IPC passam a expor (relatados na Seção 2.4).
No trabalho dos autores Trapp et al., foi relatado que os canais de comunicação IPC podem expor uma aplicação compartimentalizada. Apesar dos autores não proporem uma solução para prover mais segurança para tais canais, eles propuseram uma heurística para diminuir o número de canais expostos. Ou seja, Trapp et al. ainda tem um trabalho focado em um particionador automático porém destaca ao longo do artigo os problemas devido ao uso incauto de canais de comunicação IPC.
Já o ARBITER e o ProgramCutter foram abordagens focadas em obter melhores partici-onadores automáticos, porém sem demonstrar preocupação com o exaustivo uso de canais de comunicação IPC/RPC. Os autores dos trabalhos têm como preocupação ter uma boa granula-ridade no particionamento, a fim de mitigar a escalação de privilégios, com o menor impacto possível sobre o tempo de uma aplicação. Em ambos os trabalhos é alcançado algo em torno de
