CAPEC-45 Buffer Overflow via Symbolic Links

This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary 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.

1. [Explore] [Identify target application] The adversary identifies a target application or program that might load in certain files to memory. 2. [Experiment] [Find injection vector] The adversary identifies an injection vector to deliver the excessive content to the targeted application's buffer. 3. [Experiment] [Craft overflow file content] The adversary crafts the content to be injected. If the intent is to simply cause the software to crash, the content need only consist of an excessive quantity of random data. If the intent is to leverage the overflow for execution of arbitrary code, the adversary crafts the payload in such a way that the overwritten return address is replaced with one of the adversary's choosing. 4. [Exploit] [Overflow the buffer] Using the specially crafted file content, the adversary creates a symbolic link from the identified resource to the malicious file, causing a targeted buffer overflow attack.

• The adversary can create symbolic link on the target host. • The target host does not perform correct boundary checking while consuming data from a resources.

• [Low] An adversary can simply overflow a buffer by inserting a long string into an adversary-modifiable injection vector. The result can be a DoS. • [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.

• Availability: Unreliable Execution • Confidentiality, Integrity, Availability: Execute Unauthorized Commands • Confidentiality: Read Data • Integrity: Modify Data

• Pay attention to the fact that the resource 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 adversary, 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.