Announcement

Collapse
No announcement yet.

Linux: Exec shield overflow protection

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dev_zero
    replied
    Originally posted by hackajar
    I should say, I was not referring to you (dev zero) as the n00b, just general statment, sorry if I confused ya!
    I didn't thought you wrote that to me, but don't overestimate me. I'm not as experienced as you guys when it comes to things like this. So compared to you guys, I probably am a noob. =)

    Leave a comment:


  • hackajar
    replied
    I should say, I was not referring to you (dev zero) as the n00b, just general statment, sorry if I confused ya!

    Leave a comment:


  • dev_zero
    replied
    hmm I looked around in /proc and I didn't any signs of a file that could have something to do with an execution shield.

    I just found a confirmation that the 2.6 kernel really has address space randomization:
    http://lwn.net/Articles/121845/

    I've also found out that my kernel does not use exec-shield, I looked at exec-shield's homepage and checked the patches up against the kernel source and it looks like the patch is not applied.
    http://people.redhat.com/mingo/exec-shield/

    Edit:
    Guess what? :) I found the problem.. I decided to look through /proc again to see if I missed anything. And suddenly I stumbled over I file named "randomization_va_space".. hmm, I cat'ed it just to check what was inside, and there it was '1', when I saw it I just knew I had to try setting it to '0', so I did. I tried the exploit again and it worked like a charm. ;)

    But I think it's kind of sad to give up when I have gotten this far, so I'm going to try to find a way around to get the exploit to work with randomization on. But so far I haven't gotten any ideas on how to go through with this.
    Last edited by dev_zero; July 5, 2005, 20:37.

    Leave a comment:


  • dev_zero
    replied
    Originally posted by TheCotMan
    Your mention of a 2.6.12.1 Linux kernel causes me to think that this may be a "stock" kernel, but I still want to ask, is this a pre-ackaged kernel or a stock one from kernel.org?
    I downloaded and configured my own from kernel.org.. And thanks for the help, to both of you.. I will look into it as soon as I turn my laptop on ;)

    Leave a comment:


  • hackajar
    replied
    Originally posted by TheCotMan
    Don't blame me for any answer though, it was google that pointed a finger to help.
    Man, no soup kitchen ever made a nickle and a cent giving away the secret sause! sssshhhhhhh, the n00b that keep asking the obvious questions might catch on!

    Leave a comment:


  • TheCotMan
    replied
    Originally posted by hackajar
    It's CotMan to the rescue! I was running out of idea's there man. Doing the FreeBSD thing, have not taken notice of Linux Kernel since 2.2 first hit the street.
    I have not built a 2.6 kernel yet, but google helped me to find most of this. This was not a trivial, "just google it," as it took a few queries with intelligent selections of keywords from previously useful searches, until I found was I was looking for.

    I cheated though... I knew what I wanted; I only needed to know how to get there. ;-)

    Don't blame me for any answer though, it was google that pointed a finger to help.

    Leave a comment:


  • hackajar
    replied
    It's CotMan to the rescue! I was running out of idea's there man. Doing the FreeBSD thing, have not taken notice of Linux Kernel since 2.2 first hit the street.

    Leave a comment:


  • TheCotMan
    replied
    Your mention of a 2.6.12.1 Linux kernel causes me to think that this may be a "stock" kernel, but I still want to ask, is this a pre-ackaged kernel or a stock one from kernel.org?

    A few distributions of Linux have started including security patches to their pre-packaged kernels.

    For Example, I think that Owl Security Enhanced Linux comes with a kernel that include security patches for non-executable stack space.

    RedHat is well known for providing kernels that are far from "stock" and there was a notice that the were going to start including non-executable stack patches in their kernels (maybe not by default) in a new version of RHEL. (I can't find the e-mail sent to me by a peer.)

    Some patches for Linux kernels will actually log in kern.log or may be available in syslog or dmesg. This is one place I would check after running your buffer overrun and exploit code.

    There are a few things that I have seen includedin gcc or kernels that could be causing some of what you report:
    1) (Compiler) Use of "canaries" by gcc in the form of an encrypted copy of the return address that is included on the stack, "above," the return address. Before the return is called, the system or application decrypts the "canary" and compares it to the return address. If not equal, either exception or fault is called an that return is followed.
    2) (Kernel/OS) OS performs randomization of addresses used by executable at load/run time. This may cause the addresses for the return address to change on each executaion of the application.
    3) (Kernel/OS) Non-executable Stack enforced by kernel.

    Because many of these new features are security-based, it is very likely that they were written by security people. As a result, logging of violation attempts to one of the log repositories seems likely. (dmesg/kern.log for kernel-eforced additions and syslog/error/debug for compiler-patched additions.)

    It looks like my memory is floating around
    This makes me think that #2 above is being used.

    Using google provided me with these:
    link quoted
    Originally posted by http://kerneltrap.org/node/3070
    Linux creator Linus Torvalds announced the release of the 2.6.6 stable kernel. A number of notable additions found their way into the mainline 2.6 kernel during this development cycle, including ... support for a non-executable stack on a number of architectures ...
    On that page scroll down to find a reply "the particular patch in quest" and find more about it.
    ...

    After reading the above, I had a few more keywords in future google searches and found that there is support in /proc for enabling/disabling kernel options for this...

    As for Exec Shield... and for your box, try
    # cd /proc/sys/kernel
    # ls *exec*
    If you see "exec-shield-randomize"
    Try:
    # cat exec-shield-randomize
    Is it non-zero? :-)
    # echo "0" >> /proc/sys/kernel/exec-shield-randomize
    Now does the address you notice as changing still change each time it is executed?

    Do you see other "files" with "exec" or "shield" as part of their name? That is a good hint for what may be included in your kernel.

    Maybe if you have /proc/sys/kernel/exec-shield
    # cat /proc/sys/kernel/exec-shield
    If non-zero, then try
    # echo "0" >> /proc/sys/kernel/exec-shield

    If you disable these, does your test on the 2.6.6 (or later) kernel still work as you desire?

    Sorry, I have not moved to 2.6 yet. I said I would when it got to double-digit sub-version (2.6.X where X >= 10) but I have not had the time as of yet.

    HTH
    Last edited by TheCotMan; July 5, 2005, 15:57. Reason: quoting was bad, fixed wording

    Leave a comment:


  • hackajar
    replied
    Originally posted by dev_zero
    msfpscan ruturned 0x00000000... That won't help much :/

    And I did check something else, I tried making the buffer with the shellcode in an environment variable.. Then I used a little program to find where in the memory the variable was, and it turns out that program also returns different addresses everytime i run it.. It looks like my memory is floating around, but the weird thing is that the 2.4 memory doesn't behave anything like this, I guess they must have rewritten the whole memory management in 2.6.. When that's said, I'm out of ideas, I really thought the environment variable was static and that would work but it didn't.
    This appears to float outside of my knowledge. Anyone else got sometin? Me /got nothing

    Leave a comment:


  • dev_zero
    replied
    Originally posted by hackajar
    from command line
    Code:
    ulimit -c unlimited
    Code:
    perl -e 'print <enter shell code here>'
    Code:
    gdb -c core
    This should get you the eip so you can check if it was overwritten

    Get metasploit and run:

    Code:
    ./msfpscan -f vul -s
    That should get you some usable ret addresses to point to in program :)

    Have fun!
    msfpscan ruturned 0x00000000... That won't help much :/

    And I did check something else, I tried making the buffer with the shellcode in an environment variable.. Then I used a little program to find where in the memory the variable was, and it turns out that program also returns different addresses everytime i run it.. It looks like my memory is floating around, but the weird thing is that the 2.4 memory doesn't behave anything like this, I guess they must have rewritten the whole memory management in 2.6.. When that's said, I'm out of ideas, I really thought the environment variable was static and that would work but it didn't.

    Leave a comment:


  • hackajar
    replied
    Originally posted by dev_zero
    To use that method I have to know the return address, at least that's how he shows it in the book and he uses the output from the exploit program as return address.
    Then here is my problem, exploit prints out the return address etc. on execution and in 2.4 the ret address is the same everytime I run exploit, but when I run exploit in 2.6 I get different return address everytime. And if I'm going to do the "perl method" I think it's quite hard to guess the ret address, at least when the differences of the ret addresses I get from exploit everytime I run it, is very different from eachother..
    from command line
    Code:
    ulimit -c unlimited
    Code:
    perl -e 'print <enter shell code here>'
    Code:
    gdb -c core
    This should get you the eip so you can check if it was overwritten

    Get metasploit and run:

    Code:
    ./msfpscan -f vul -s
    That should get you some usable ret addresses to point to in program :)

    Have fun!

    Leave a comment:


  • dev_zero
    replied
    Originally posted by hackajar
    try throwing the shell code at vul like this:

    perl -e 'print "\x41"x70 . <play with code here>' | vul

    from command line, find what works, then update the exploit.c with new lines from perl statement and recomplie into 2.6.x that's how it's done by hand :)
    To use that method I have to know the return address, at least that's how he shows it in the book and he uses the output from the exploit program as return address.
    Then here is my problem, exploit prints out the return address etc. on execution and in 2.4 the ret address is the same everytime I run exploit, but when I run exploit in 2.6 I get different return address everytime. And if I'm going to do the "perl method" I think it's quite hard to guess the ret address, at least when the differences of the ret addresses I get from exploit everytime I run it, is very different from eachother..

    Leave a comment:


  • hackajar
    replied
    try throwing the shell code at vul like this:

    perl -e 'print "\x41"x70 . <play with code here>' | vul

    from command line, find what works, then update the exploit.c with new lines from perl statement and recomplie into 2.6.x that's how it's done by hand :)

    Leave a comment:


  • dev_zero
    replied
    I'm waving the white flag, I give up.. I have tried to debug the program under both 2.4 and 2.6, I compiled the 2.4 exploit under kernel 2.4 and the other under 2.6 (I don't know if this has anything to say, but I did it anyway).

    This is how i did it:
    2.4:
    I put break point on execl and execve because I noticed execl called execve.. When I was in execve I single stepped until right after it called int 80.. then I checked the memory where the shellcode was suppose to begin and there it was the entire buffer just waiting to be executed.

    2.6:
    I did the same as I did in the 2.4 version, but at the return address there were lots of 0x00.

    After experiencing this, I will say in the 2.4 kernel the buffer actually gets copied into memory, but in the 2.6 kernel it doesn't..
    I'm throwing in the towel now, unless someone can help me, because this is getting way out of my league.

    Leave a comment:


  • hackajar
    replied
    vul won't change, exploit will with kern versions (most times). Find the Nop sled in that code (probably first or second line) and see where it drops you in memory, if it's no where near eip than that's your problem. Use a standard \x90 or \x41 nop sled, and rediscover the eip that way and compare with the example code. This should give you a good start in the right direction

    Leave a comment:

Working...
X