Testando o PaX

Vamos agora testar o nosso PaX para ver se ele realmente consegue nos fornecer uma segurança melhor contra possíveis tentativas de exploração.

Primeiro teste:
Um pequeno script vulnerável a stack overflow, vamos rodar o exploit para tentar obter os privilégios do daemon vulnerável, que esta setado como suid (uid=0).

$ ls -la

-rwsr-xr-x    1 root     root         8424 Mar  9 03:27 vuln*

$ ./exploit
Usage: ./exploit <vuln> <addr_to_buffer>
$ ./vuln
0x5d952570
Segmentation fault

Como podemos ver, o programa vulnerável nos fornece o seu stack point. Agora vamos tentar usar esse addr para explorar o programa e obter o tão cobiçado uid=0:

$ ./exploit ./vuln 0x5d952570
0x5e3ca360
Killed

Bingo, como vemos o script que estava tentando explorar o daemon vulnerável foi "Killado" antes de cumprir o seu objetivo. Pelo visto o PaX realmente cumpriu o seu prometido. Vamos dar uma olhada nos logs que o PaX gerou no momento em que detectou a tentativa de escrita no addr_buffer:

# tail -4 /var/log/messages
Jun 5 08:31:55 unsekurity kernel: PAX: execution attempt in: <NULL>,
00000000-00000000 00000000
Jun 5 08:31:55 unsekurity kernel: PAX: terminating task:
/exploits/lab/vuln-mmap(vuln-mmap):2295, uid/euid: 0/0, PC: 5d952570, SP:
5e3ca3d0
Jun 5 08:31:55 unsekurity kernel: PAX: bytes at PC: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00

Como vimos acima ele mostra o que o programa tentou fazer:

PAX: execution attempt in: <NULL>,
00000000-00000000 00000000

Mostra onde foi encontrado o erro:

Jun 5 08:31:55 unsekurity kernel: PAX: terminating task:
/exploits/lab/vuln-mmap(vuln-mmap):2295, uid/euid: 0/0, PC: 5d952570, SP:
5e3ca3d0

Como podemos ver ele nos deixa bem informados sobre atividades ilícitas em nosso servidor.

Bom, vamos agora verificar outros tipos de exploração que poderiam ser realizadas em um kernel normal.

Como todos sabem a versão da kernel 2.4.24 está vulnerável a um bug na função do_munmap() do_mrepmap(), que causa elevação de privilégios no sistema vulnerável.

Vamos fazer um teste desse kernel normal:

$ uname -r
2.4.24 $ ./mrpmap_exploit
[+] Kernel 2.4.24 vulnerable: YES exploitable YES
** 0x5e3ca360
** 0x5d952570

# id
uid=0(root); gid=0(root); group=0(root)

Como vimos o kernel foi comprometido e nos deu o que tanto queríamos: privilégios totais no sistema Linux.

Agora faremos o mesmo teste com o mesmo kernel, porém com o PaX agregado a ele e veremos se mesmo com a vulnerabilidade exposta ele vai segurar a tentativa de comprometimento.

$ ./mrpmap_exploit
Killed

Logo de cara ele matou a execução do exploit, porque antes de executar qualquer verificação ele faz um alocamento de memória que o PaX não permite, isso nos da a proteção contra a exploração.

Como podemos ver o uso de ferramentas como PaX nos dá uma certa segurança e nos deixa mais leves para não precisarmos atualizar daemons vulneráveis assim tão prontamente, porque como vimos às explorações tornam-se extremamente difíceis. Estive fazendo testes no kernel com PaX desde a versão 2.4.24 (estou na 2.4.26) e não obtive sucesso em nenhum tipo de exploração dentro do kernel protegido.

Se quiser pode tentar algumas técnicas que você achar interessante, as mais avançadas ele barra tranqüilamente. Outra coisa que chama a atenção é quanto ao user space para usuários sem altos privilégios, ele retira totalmente os buffers em desuso fazendo com que qualquer tentativa de alocação por parte de usuários comuns seja barrada.

Caso você como root queira liberar algum binário para executar que o PaX esteja bloqueando, basta utilizar:

# chpax -sp <binário>

Então ele poderá executar normalmente. Tive alguns problemas com o wine, mas nada que com um pouco de estudo e treino não tivesse resolvido. Caso vocês também tenham tentem ler a documentação oficial do projeto PaX em:

• http://pax.grsecurity.net

A documentação esta toda em inglês, porém lá existe um txt detalhando cada uma das funções que existem no PaX, desde seu designer, como também sua aplicação interna na kernel space.