lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux Buffer Overflow Security Exploits
    On Wed, 3 Mar 1999, Albert D. Cahalan wrote:

    > Oliver Xymoron writes:
    > > o The stack growns downwards, making buffer overflows with strings
    > > relatively common. It's possible the other way, it's just less common.
    > > True for most architectures.
    >
    > True for i386, but only convention on RISC. I've long thought it was
    > stupid to keep doing this.

    It doesn't really make a difference. As I said, it's exploitable in both
    directions. In the other direction, all you have to do is overflow a
    buffer passed by a function above you on the call chain. I'm going to
    rescind my statement that this is less common - most overflows occur
    inside library functions operating on stack variables in an application.
    This is actually worse - unless the library was compiled with Stackguard,
    you can't protect against it, as the exploit occurs when the library
    function returns rather than when the caller does.

    Stacks growing downward is not completely arbitrary, either. It's very
    convenient to have a known starting point for both code and data. Since
    code likes to run upwards, it makes sense to have code start near the
    bottom. Since the optimal way to put two growing structures
    (code+heap and stack) in a linear array is to start them at opposite ends
    and have them grow inward, the stack gets placed at the top. Less of a
    concern when you have ridiculously large address spaces like the Alpha,
    but still not arbitrary.
    --
    "Love the dolphins," she advised him. "Write by W.A.S.T.E.."


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:50    [W:3.340 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site