Common Attack Pattern Enumeration and Classification

Common Attack Pattern Enumeration and Classification

100

Very High

Targeted software performs buffer operations.

Targeted software inadequately performs bounds-checking on buffer operations.

Attacker has the capability to influence the input to buffer operations.

High

• Injection
• Analysis

Low: In most cases, overflowing a buffer does not require advanced skills beyond the ability to notice an overflow and stuff an input variable with content. High: In cases of directed overflows, where the motive is to divert the flow of the program or application as per the attacker's bidding, high level skills are required. This may involve detailed knowledge of the target system architecture and kernel.

None: Detecting and exploiting a buffer overflow does not require any resources beyond knowledge of and access to the target system.

The attacker sends in overtly long input in variables under his control. If the target system or application handles it gracefully, the attack becomes difficult. However, an error condition or a system crash point to a high likelihood of successful exploitation.

In cases where the attack is directed at a particular system or application, such as an operating system or a web server, the attacker can refer to system architecture and design documentation to figure out the exact point of injection and exploitation.

An attack designed to leverage a buffer overflow and redirect execution as per the attacker's bidding is fairly difficult to detect. An attack aimed solely at bringing the system down is usually preceded by a barrage of long inputs that make no sense. In either case, it is likely that the attacker would have resorted to a few hit-or-miss attempts that will be recorded in the system event logs, if they exist.

A buffer overflow attack itself is pretty difficult to obfuscate. There, however, exist fairly advanced techniques to ofuscate the payload, in order to bypass an intrusion detection system or filtering, either in the application or by means of an application firewall of some sorts.

Use a language or compiler that performs automatic bounds checking.

Use secure functions not vulnerable to buffer overflow.

If you have to use dangerous functions, make sure that you do boundary checking.

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.

Utilize static source code analysis tools to identify potential buffer overflow weaknesses in the software.

• Denial of Service
• Run Arbitrary Code
• Privilege Escalation

Every program or application is designed to process some inputs received from the user or another system. Buffer overflows abound because programs trust user-controlled input.
A buffer is a region of memory allocated for the purposes of storing certain data values. These can be environment variables, user-suppplied input or temporary scratch space. These regions are allocated on a stack (static allocation) or a heap (dynamic allocation). Although the exact payload used to exploit an overflow in buffers allocated on the stack or heap differ, the general technique is to stuff an input variable with more data than expected.
Managed environments, such as the Java language or the .NET platform enforce strict type and bounds checking. This means that an attempt at a buffer overflow results in a system error. Note that this protection does not make application secure; it makes exploitation of overflow conditions more difficult than in application written in umanaged languages, such as C and C++. For example, the Structured Exception Handling mechanism technically allows an application to perform certain actions before the process is shut down. In case of a buffer overflow, this can be used to close sensitive files or disable certain functionality. However, it is possible to abuse the SEH mechanism as well and execute a successful buffer overflow exploit; only the effort and technical knowledge required are far greater than average. Therefore, it still remains the developer's and designer's prerogative to design a system in such a way that no overflow conditions exist.

User-controllable input. Usually, any input that a user can control is prone to exploitation by overflow.

Malicious content, such as an overtly long input string, system shellcode or commands, intended to cause a system crash and denial of service, or to escalate privilege or execute code that results in information disclosure or system compromise.

Buffer allocated in memory for the input that carried the payload.

Denial of service, escalated privileges, execution of arbitrary code, including system commands and low-level assembly code.

All user-controllable input must be strictly validated for enforcement of length and semantic checks

All exception conditions (such as ArrayIndexOutOfBounds) in applications must be gracefully handled through use of available exception handling mechanisms.

All applications and processes must be run with minimum privileges necessary so as to avoid an escalation of privilege in case of a successful exploit.

• Reluctance To Trust
• Defense in Depth
• Failing Securely

• Ensure that the Bounds of No Memory Region Are Violated
• Never Use Unvalidated Input as Part of a Directive to any Internal Component

Penetration

Exploitation