next up previous
Next: Stack Protection Method Up: Protecting from stack-smashing attacks Previous: Attack Scenarios and their


Related work

Several projects have addressed the buffer overflow problem with different approaches. One approach[10] is to eliminate vulnerable code from a source program and to help the application be made safe from the problem. For example, there is an auditing tool that helps automate source code review for security[10]. It helps to eliminate the use of dangerous functions: such as strcpy, gets, etc., but the tool has the limited vulnerability detection in that it can't check the boundaries by a pointer variable.

Another approach provides protection methods against the potential vulnerability of program code. We have defined four categories according to how they protect against an attack.

  1. Avoidance of leakage from an array

    Array bounds checking for C [6] and memory access checking [5] are protection methods that prevent access outside the region allocated for an array. Therefore, these methods are the most secure methods. However, the protection overhead is expensive compared to non-protected code; a slowdown of more than two times in comparison to optimized code is common.

  2. Prohibition on the execution of attack code

    ``Solar Designer'' developed a Linux patch that makes the stack region non-executable [1], so that attack code stored on the stack cannot be executed. This approach has the advantages of no performance overhead and no source code is required. However, it has drawbacks in that it relies on the features of the operating system and the processor, specifically the capability of marking the stack region as non-executable. It doesn't protect every regions described in Section 2, so there is still a possibility that an attacker can take control, by putting the attack code somewhere besides into the stack, such as into a statically allocated buffer and changing the return address to point to the code.

    Janus [4] designed a secure environment for confinement of applications by restricting the programs' access to the operating system. It protects the privileged operations, such as executing /bin/sh in privileged mode, from attack code not just on the stack, but also in static regions. It also relies on the features of the operating system, which must provide debug information such as strace.

  3. Protection not to pass the control of execution to code that has been attacked

    Snarskii has developed a FreeBSD patch [8] that implements a stack integrity check to detect buffer overflows. This is a non-portable implementation embedded in libc.

    StackGuard [3], StackShield [9], and libsafe [2] provide a portable, general protection method. Libsafe provides a solution, which is based on a middleware software layer that intercepts all function calls made to library functions that are known to be vulnerable; such as gets, strcpy, so on.

    StackGuard is the base system of our system, it detects and defeats stack smashing attacks by protecting the return address on the stack from being altered. The ``XOR Random canary'' method places the xor value of the return address and a random number next to the return address when a function is called and check if the value is preserved before the function returns.

    StackShield copies the return address in an unoverflowable location, the beginning of the static data, when the function begins execution and check if the two values are preserved before the function returns.

    We will compare each of these techniques and our method in Section 4.5.


next up previous
Next: Stack Protection Method Up: Protecting from stack-smashing attacks Previous: Attack Scenarios and their
Etoh
2000-11-08