lkml.org 
[lkml]   [1999]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Unexecutable stack
    Horst von Brand writes:
    > Steve VanDevender <stevev@efn.org> said:
    >
    > > In theory it is possible to write executable code into a buffer
    > > in the data segment and overflow a buffer in the stack so that
    > > the stack frame contains a return address that points into that
    > > data. In practice it is much harder to create an exploit with
    > > this method as it requires quite detailed knowledge of the data
    > > segment layout.
    >
    > Yep, it is somewhat harder, and thus not done regularly by crackers today,
    > as this is rarely needed now. If/when this becomes common, the cracks will
    > become common too. Then we are where we started. Better than buying (false)
    > security is to fix the affected programs.

    You are yet another person making the logically unsupportable
    argument that since a non-executable stack doesn't prevent all
    possible security compromises, it doesn't provide a real security
    benefit. It's true that when you cut off one avenue of attack,
    you cause attackers to concentrate on others. But cutting off
    avenues of attack does make it harder for attackers, and in
    practice making security attacks harder reduces the number of
    successful attacks, and that is a real benefit.

    In this case a non-executable stack prevents a large and
    significant number of attacks, makes those attacks more
    noticeable ("what's that core file doing there?"), buys time to
    fix the vulnerable programs, and gives me some security now
    instead of wishful thinking that there will be perfect security
    later.

    I know that making the stack non-executable is not a cure-all,
    and not a replacement for fixing programs that have buffer
    overflow problems. Even though the Solaris systems I work on
    have noexec_user_stack set, I still keep up with patches, disable
    nonessential daemons, remove unnecessary setuid permissions, and
    take all the other security precautions I can. Security is about
    defense in depth using many methods and layers of protection, and
    monitoring systems on the assumption that they _will_ be broken
    into, rather than assuming they're too secure to be penetrated.

    -
    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:55    [W:0.033 / U:60.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site