[FUG-BR] Exploit

[Patrick Tracanelli]

Luiz Otavio O Souza escreveu:
>> Pessoal,
>>
>> Não sei se to enganado, ou se já foi comentado aqui na lista, porém
>> se já foi enviado, deletem esse email, por favor!
>>
>> http://www.phrack.org/issues.html?issue=66&id=8&mode=txt
>>
>>
>> Sds
>> Loiaco.
> 
> Bah... exploitando assim até eu que sou mais bobo...
> 
> Não vi os detalhes do papel, não sei dizer se existe ou não um bug no 
> FreeBSD ou se nós estamos falando apenas de um software oportunista (que é o 
> que me parece...).
> 
> Mas para tornar esse exploit possível você precisa carregar um módulo no 
> kernel e pra isso você precisa ter acesso ao root...
> 
>> // Again, we load the KLD as root:
>> [root em julius ~/code/bug]# kldload -v ./bug.ko
>> bug loaded at 210
>> Loaded ./bug.ko, id=4
> 
> Olha lá ele confirmando que o módulo esta carregado antes de rodar o 
> exploit:
> 
>> [argp em julius ~]$ uname -r
>> 7.2-RELEASE
>> [argp em julius ~]$ kldstat | grep bug
>>  4    1 0xc25b0000 2000     bug.ko
>> [argp em julius ~]$ id
>> uid=1001(argp) gid=1001(argp) groups=1001(argp)
>> [argp em julius ~]$ gcc ex2.c -o ex2
>> [argp em julius ~]$ ./ex2
>> ---[ free items on the 256 zone: 34
>> ---[ consuming 34 items from the 256 zone
>> [*] bug: 0: item at 0xc243c800
>> [*] bug: 1: item at 0xc25b3900
> 
> Pode rodar o exploit na sua maquina (sem o módulo) que ele não faz nada, não 
> funciona.
> 
> Isso me parece mais uma prova de conceito do que um "exploit" propriamente 
> dito (se você pode carregar um modulo do kernel, você realmente precisa de 
> tudo isso pra fazer algum estrago ?)
> 
> Att.,
> Luiz
> PS: prova de conceito porque ele sobre-escreve as credenciais no kernel, 
> roda o shell code e ainda consegue manter o kernel funcionando (isso deve 
> dar trabalho absurdo) 

Do trabalho:

The main requirement for successful arbitrary code execution, in
addition to having an overflow bug in the kernel, is that we should be
able to make repeated allocations of kernel memory from userland without
having the kernel automatically deallocate our items.  We also need to
have control over the deallocation of these items to fully control the
process.

Ou seja, precisamos de um bug que não existe, de modificar um
comportamento de kernel, e ainda impedir que a vm libere as paginas de
memoria por conta propria. Enfim, basta intervir completamente no
subsistema de memoria do kernel pra ter a vulnerabilidade. Acho mais
simples fazer um fork privilegiado em 3 linhas de codigo, ja que é pra
intervir no kernel...

De qualquer forma o trabalho parece mesmo meio que uma prova de
conceito, coisa academica ou uma inspiracao do livro BSD rootkits. Tem
seu merito pois é uma discussaozinha tecnica interessante pra quem gosta
ou quer aprender internals. Mas o pecado maior é a expressão "exploit"
do titulo do mini-paper "Exploiting UMA, FreeBSD's kernel memory
allocator". Seria bem mais interessante renomear para "Exploring UMA,
FreeBSD's kernel memory allocator ".



-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"