realmente não faz muito sentido todo esse trabalho para tornar o sistema vulneravel... pra poder explorá-lo...
Tudo bem, funciona, mas entendo como puro masoquismo. 2009/9/11 Patrick Tracanelli <[email protected]> > 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: > >> [r...@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: > > > >> [a...@julius ~]$ uname -r > >> 7.2-RELEASE > >> [a...@julius ~]$ kldstat | grep bug > >> 4 1 0xc25b0000 2000 bug.ko > >> [a...@julius ~]$ id > >> uid=1001(argp) gid=1001(argp) groups=1001(argp) > >> [a...@julius ~]$ gcc ex2.c -o ex2 > >> [a...@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 > [email protected] > http://www.freebsdbrasil.com.br > "Long live Hanin Elias, Kim Deal!" > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
