Re: Buffer Overflow Help

From: Steve Bonds (kzzvt3302_at_sneakemail.com)
Date: 11/11/04

  • Next message: Marco Ivaldi: "Re: Buffer Overflow Help"
    Date: Thu, 11 Nov 2004 11:39:21 -0800 (PST)
    To: vuln-dev@securityfocus.com
    
    
    

    On Wed Nov 10 2004 runixd wrote:

    > Depending on your version, options may very, but you should be able to
    > disable stack randomization by setting
    > /proc/sys/kernel/exec-shield-randomize to 0
    > "echo 0 > /proc/sys/kernel/exec-shield-randomize"

    > and you can disable exec shield in /proc/sys/kernel/exec-shield, setting
    > it to 0, should cause it to be disabled, otherwise this is where you
    > have to work with non executable stack and return to libc.

    I'm having the same trouble while working on modifications to an existing
    exploit to get it working reliably on Red Hat 9. On a stock, unpatched
    Red Hat 9 installation I don't see any /proc/sys/kernel/exec-shield*
    entries.

    With the attached C code, on Red Hat 9 I get:

    -----
    $ gcc -Wall -g --static -o stackp stackp.c
    $ for i in 1 2 3 4 5; do ./stackp; done
    &sp is 0xbffff234
    &sp is 0xbffff134
    &sp is 0xbffff034
    &sp is 0xbfffef34
    &sp is 0xbfffee34
    -----

    There's a definite pattern in the stack location, but for the purposes of
    the exploit I'm working on there's brute forcing isn't feasible. (The
    application crashes on a bad guess, and must be restarted manually.)

    I've also tried the same thing on a Red Hat Enterprise 3 system, which
    does have the above /proc entries:

    -----
    # echo 0 > /proc/sys/kernel/exec-shield
    # echo 0 > /proc/sys/kernel/exec-shield-randomize
    # gcc -Wall -g --static -o stackp stackp.c
    # for i in 1 2 3 4 5; do ./stackp; done
    for i in 0 1 2 3 4 5; do ./stackp; done
    &sp is 0xbfffc294
    &sp is 0xbfff9174
    &sp is 0xbfffc414
    &sp is 0xbfffbb14
    &sp is 0xbfffb8f4
    &sp is 0xbfff9634
    -----

    Strangely, I still see the "randomization" even after disabling the
    feature.

    Any suggestions on how to really disable it, or should us newbies stick to
    Red Hat 8? ;-)

      -- Steve

    
    



  • Next message: Marco Ivaldi: "Re: Buffer Overflow Help"

    Relevant Pages

    • Re: Bug? Using KEYEVAL to toggle last stack corrupts local variables?
      ... when you disable Last Stack; the following thread might be interesting, ... but simply a deleted entire environment, ... I often use such "suspended environments". ... is affected by disabling last stack, as long as last stack is ...
      (comp.sys.hp48)
    • Re: Disabling interrupts to protect data
      ... Disabling interrupts is fine, but it is necessary to know at the time of reenabling any instance, what the current interrupt state was for the device, prior to the call. ... The solution was to write a couple of functions to stack the current device interrupt state before disabling, then pop on exit, rather than just a hard disable / reenable. ...
      (comp.arch.embedded)
    • Re: Disabling interrupts to protect data
      ... Disabling interrupts is fine, but it is necessary to know at the time of reenabling any instance, what the current interrupt state was for the device, prior to the call. ... The solution was to write a couple of functions to stack the current device interrupt state before disabling, then pop on exit, rather than just a hard disable / reenable. ...
      (comp.arch.embedded)
    • Re: Trouble with stack space when upgrading from 8.4 to 8.5
      ... be at least somewhat fragile. ...  There are reasons the compiler directive ... Should we add a configuration option to allow disabling of the stack ...
      (comp.lang.tcl)