do_brk() exploit

I hadn't seen this posted yet.... one of the kernels affected is Linux Kernel 2.4.22 which came with my version of RedHat 9.

Proof of Concept: http://www.derkeiler.com/Mailing-Lis...3-12/0017.html

more information: http://isec.pl/vulnerabilities/isec-0012-do_brk.txt

the exploit: http://www.k-otik.net/exploits/12.02.brk_poc.asm.php

And: http://core.geekheim.de/archives/000515.html

/me skips away singing "a patchin I will go...

EDIT: I did find a paper where this has been seen in the wild, but I can't remember where I found it... DOH!

Found it: https://utils.its.caltech.edu/piperm...03/000000.html

i tried the 2 exploits for k-otik.net on my stock kernel slack 9.1 box. one of them just seg faulted and the other asm one crashed. my friend wtih slack 9.1 also tried this and the same effects.

yeah__ it didnt work on my ReDHar9 eather
seg :D fault

If its causing segfaults then you are probably vulnerable since that would indicate you are probably screwing around in memory you shouldnt be which is what this vuln is about. Are you using an exploit with shellcode or just a proof-of-concept?

-Maestr0

damn... on mine it popped up a dialog box that said "y0u'v3 833n 0wn3d"..... :D

Can I just explain something:

Causing a segfault does not imply that the system is vulnerable, as any process can cause a segfault without affecting system security or stabililty.

Causing an "Oops" (which in turn usually causes a segfault as far as userspace is concerned) is something completely different - as it's caused by a protection fault in kernel space, and should not happen.

An exploit which causes a segfault is probably either broken or running on a non-vulnerable system. An exploit which causes an "Oops" indicates a vulnerable system, root access can potentially be obtained, and DoS is probably quite easy.

The problem is, that if you're remotely testing this (or in X), you might not be able to easily tell the difference between segfault and Oops, however, look at the system log (/var/log/messages usually), and an "Oops" is clearly indicated (the word "Oops" appears in it, and a lot of hex numbers usually). Segfaults are not reported in the system log.

Slarty

Although any code can cause a seg fault, I glanced at the first link provided and noted the author of the code commented that the exploit exits cleanly when run against the 2.4.23 kernel. Now to be honest I really didnt read any further than that but when purpose of the exploit is to extend the users memory space into the kernel space,and since most people are still running the 2.4.22, I would say you are probably vulnerable. Of course it may be that you are not and the exploit is dorked but if you are able to crash the machine(not a good sign) with one of the exploits and segfault with another, then I think you may want to take a closer look. Of course as slarty pointed out, although seg faults may not show up in your system logs any protection faults should so you may find your answer right there.

-Maestr0

Quote:

---

most people are still running the 2.4.22

---

Speak for yourself :)

I'm certainly not running any 2.4.22

And my redhat boxes all have updated redhat kernels (2.4.20) which include a patch against that.

Unfortunately more patching now due, as there is *yet another* kernel exploit kicking around now, need to go to 2.4.24 to mitigate mremap() bug.

Slarty

Linux kernel do_mremap() proof-of-concept exploit code

http://www.securitylab.ru/42037.html

reboots the system............with user previleges!
Not far from binding rootshell....slight modifications required
I'm not good at C, but shouldnt be that hard......... :)