Results 1 to 9 of 9

Thread: do_brk() exploit

  1. #1
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,018

    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

  2. #2
    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.

  3. #3
    yeah__ it didnt work on my ReDHar9 eather
    seg fault

  4. #4
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    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
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  5. #5
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,018
    damn... on mine it popped up a dialog box that said "y0u'v3 833n 0wn3d".....

  6. #6
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  7. #7
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    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
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  8. #8
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    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

  9. #9
    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.........

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •