Common Attack Pattern Enumeration and Classification
A Community of Knowledge Resource for Building Secure Software
This type of attack leverages the use of symbolic links to cause buffer overflows. An attacker can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
Attack Execution Flow
The attacker can create symbolic link on the target host.
The target host does not perform correct boundary checking while consuming data from a ressources.
The EFTP server has a buffer overflow that can be exploited if an attacker uploads a .lnk (link) file that contains more than 1,744 bytes. This is a classic example of an indirect buffer overflow. First the attacker uploads some content (the link file) and then the attacker causes the client consuming the data to be exploited. In this example, the ls command is exploited to compromise the server software.
Skill or Knowledge Level: Low
An attacker can simply overflow a buffer by inserting a long string into an attacker-modifiable injection vector. The result can be a DoS.
Skill or Knowledge Level: High
Exploiting a buffer overflow to inject malicious code into the stack of a software system or even the heap can require a higher skill level.
The attacker will look for temporary files in the world readable directories. Those temporary files are often created and read by the system.
The attacker will look for Symbolic link or link target file that she can overide.
An attacker creating or modifying Symbolic links is a potential signal of attack in progress.
An attacker deleting temporary files can also be a sign that the attacker is trying to replace legitimate resources with malicious ones.
Pay attention to the fact that the ressource you read from can be a replaced by a Symbolic link. You can do a Symlink check before reading the file and decide that this is not a legitimate way of accessing the resource.
Because Symlink can be modified by an attacker, make sure that the ones you read are located in protected directories.
Pay attention to the resource pointed to by your symlink links (See attack pattern named "Forced Symlink race"), they can be replaced by malicious resources.
Always check the size of the input data before copying to a buffer.
Use a language or compiler that performs automatic bounds checking.
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution.
Use OS-level preventative functionality. Not a complete solution.
When the function returns control to the main program, it jumps to the return address portion of the stack frame. Unfortunately that return address may have been overwritten by the overflowed buffer and the address may contain a call to a privileged command or to a malicious code.
[R.45.1] [REF-2] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.