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 316...@sip.freebsdbrasil.com.br 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