[lkml]   [1999]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Unexecutable Stack / Buffer Overflow Exploits...
       From: Steve VanDevender <>
    Date: Thu, 30 Dec 1999 17:58:09 -0800 (PST)

    1. Most buffer overrun exploits are simple stack smashes that
    would be prevented by a nonexecutable stack. Arguing that this
    would provide no real protection because it will force crackers
    to develop on other methods of attack is bogus, because you could
    make the same argument for almost any other built-in OS security
    protection, i.e. restricting file permissions forces crackers to
    find ways to gain the privileges needed to write to the files
    they want, so restricting file permissions is only a temporary
    solution too by that logic. The point is that something that was
    available and easily exploitable to bypass security is no longer

    People keep making this argument, but it's not a valid one.

    Look, making the stack non-executable purports to solve a generic class
    of problems involving stack overruns. The fact is, it doesn't.
    Fundamentally, the real problem is the fact that the program allows an
    automatic array variable to be overrun, and allow the stack to be

    Suppose an attacker find a stack overrun in sendmail and the stack is
    executable; he just simply sends data which overwrites the return
    location on the stack, and contains the code to run execv("/bin/sh").
    If the stack is made non-executable, then all the attacker needs to do
    is find some place in the sendmail text where the instruction "call
    execv" lives. He then overwrites the arguments area of the stack with
    the desired arguments of execv, makes the return address point to the
    "call execv" instruction, and then when the function returns, control is
    transfered to the "call execv" instruction, which then in turn transfers
    control to the execv code in libc, and we're off to the races.

    So making the stack non-executable didn't stop the attack! It changed
    the method by which the attacker might need to exploit a stack smash,
    but that's about it. And once someone writes a tool to automatically
    analyze a binary to find vulnerable places where a stack smashing attack
    can transfer control into a victim program's text area, then any
    advantage making the stack non-executable is well and truely gone. At
    best, making the stack non-executable is really only a
    security-through-obsecurity kind of thing. It will stop stupid
    hackers.... temporarily.... until they adapt their methods to attack the
    very same holes they are attacking today.

    It's like putting antibiotics into chicken feed. It might temporarily
    decrease the spread of certain types of bacteria in improperly cooked
    food, but in the long run, the bacteria develop resistance, and then
    we're back where we're started. And you'll notice that scientists have
    made the argument that it's better not to put antibiotics in chicken
    feed if it isn't going to stop the bacteria in the long run. This is a
    similar situation.

    - Ted

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:3.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site