481 (Weakness Variant)

Low

Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.

Implementation: Place constants on the left. If one attempts to assign a constant with a variable, the compiler will of course produce an error.

This bug is generally as a result of a typo and usually should cause obvious problems with program execution. If the comparison is in an if statement, the if statement will always return the value of the right-hand side variable.

CLASP - Assigning instead of comparing

C

C++

Java

.NET

587 (Weakness Base)

Primary (Weakness exists independent of other weaknesses)

Implementation: Never set a pointer to a fixed address.

C Example:

Consequence: Integrity: If one executes code at a known location, one might be able to inject code there beforehand.

Consequence: Confidentiality: The data at a known pointer location can be easily read.

Most often, this issue will only result in a crash, but in circumstances where a user can influence the data at which the pointer points to, it may result in code execution. At best, using fixed addresses is not portable.

C

C++

C#

Assembly

126 (Weakness Variant)

Primary (Weakness exists independent of other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

PLOVER - Buffer over-read

C

C++

Implementation

127 (Weakness Variant)

Primary (Weakness exists independent of other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

Under-studied.

PLOVER - Buffer under-read

C

C++

Implementation

482 (Weakness Variant)

Low

Pre-design: Through Build: Many IDEs and static analysis products will detect this problem.

C/C++/Java Example:

This bug is mainly a typo and usually should cause obvious problems with program execution. The assignment will not always take place.

CLASP - Comparing instead of assigning

C

C++

396 (Weakness Base)

The following code excerpt handles three types of exceptions in an identical fashion.

At first blush, it may seem preferable to deal with these exceptions in a single catch block, as follows: try { doExchange(); } catch (Exception e) { logger.error("doExchange failed", e); } However, if doExchange() is modified to throw a new type of exception that should be handled in some different kind of way, the broad catch block will prevent the compiler from pointing out the situation. Further, the new catch block will now also handle exceptions derived from RuntimeException such as ClassCastException, and NullPointerException, which is not the programmer's intent.

Multiple catch blocks can get ugly and repetitive, but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions that deserve special treatment or that should not be caught at this point in the program. Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions, and can become particularly dangerous if the program grows and begins to throw new types of exceptions. The new exception types will not receive any attention.

7 Pernicious Kingdoms - Overly-Broad Catch Block

C

C++

Java

.NET

397 (Weakness Base)

The following method throws three types of exceptions.

While it might seem tidier to write public void doExchange() throws Exception { ... } doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Declaring a method to throw Exception or Throwable makes it difficult for callers to do good error handling and error recovery. Java's exception mechanism is set up to make it easy for callers to anticipate what can go wrong and write code to handle each specific exceptional circumstance. Declaring that a method throws a generic form of exception defeats this system.

7 Pernicious Kingdoms - Overly-Broad Throws Declaration

C

C++

Java

.NET

415 (Weakness Variant)

Double-free

Low to Medium

Memory

Access control: Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

Implementation: Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Example 1: The following code shows a simple example of a double free vulnerability.

Double free vulnerabilities have two common (and sometimes overlapping) causes: - Error conditions and other exceptional circumstances - Confusion over which part of the program is responsible for freeing the memory Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2: While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.

Also a Consequence.

When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but we're considering "Use" and "Release" to be distinct operations, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

PLOVER - DFREE - Double-Free Vulnerability

7 Pernicious Kingdoms - Double Free

CLASP - Doubly freeing memory

C

C++

243 (Weakness Variant)

High

Resultant (Weakness is typically related to the presence of some other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

File/Directory

Example: Consider the following source code from a (hypothetical) FTP server:

This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server fails to change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.

The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system. Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.

7 Pernicious Kingdoms - Directory Restriction

C

C++

Implementation

244 (Weakness Variant)

Memory

The following code calls realloc() on a buffer containing sensitive data:

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for cleartext_buffer.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

Be careful using {vfork, fork} in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.

7 Pernicious Kingdoms - Heap Inspection

C

C++

Implementation

401 (Weakness Base)

Memory management

Medium

Memory

Availability: If an attacker can determine the cause of the memory leak, then the attacker may be able to cause the application to leak quickly and therefore cause the application to crash.

Pre-design: Use a language or compiler that performs automatic bounds checking.

Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.

Pre-design through Build: The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code. This is not a complete solution as it is not 100% effective.

Example 1: The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes:

C Example:

Example 2: In C:

C Example:

Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

Terminology Note: "memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict).

Memory leaks have two common and sometimes overlapping causes: - Error conditions and other exceptional circumstances. - Confusion over which part of the program is responsible for freeing the memory Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing the program) or take advantage of other unexpected program behavior resulting from a low memory condition [30].

PLOVER - Memory leak

7 Pernicious Kingdoms - Memory Leak

CLASP - Failure to deallocate data

C

C++

A weakness where the code path has:
1.        start statement that allocates dynamically allocated memory resource
2.        end statement that loses identity of the dynamically allocated memory resource creating situation where dynamically allocated memory resource is never relinquished

Where “loses” is defined through the following scenarios:
1.        identity of the dynamic allocated memory resource never obtained
2.        identity of the dynamic allocated memory resource obtained but got re-written (missing beyond recovery)
3.        identity of the dynamic allocated memory resource obtained but never passed on to function for memory resource release
4.        the statement assigns another value to the last data element that stored the identity of the dynamically allocated memory resource (no more aliases remain)
5.        the last data element that stored the identity of the dynamically allocated resource has reached the end of its scope at the statement

478 (Weakness Variant)

Undefined: Depending on the logical circumstances involved, any consequences may result: e.g., issues of confidentiality, authentication, authorization, availability, integrity, accountability, or non-repudiation.

Implementation: Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label.

In general, a safe switch statement has this form:

This is because the assumption cannot be made that all possible cases are accounted for. A good practice is to reserve the default case for error handling.

This flaw represents a common problem in software development, in which not all possible values for a variable are considered or handled by a given process. Because of this, further decisions are made based on poor information, and cascading failure results. This cascading failure may result in any number of security issues, and constitutes a significant failure in the system. In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default cause is used simply to represent an assumed option, as opposed to working as a sanity check. This is poor practice and in some cases is as bad as omitting a default case entirely.

CLASP - Failure to account for default case in switch

C

C++

Java

.NET

122 (Weakness Variant)

High to Very High

Primary (Weakness exists independent of other weaknesses)

Explicit (This is an explicit weakness resulting from behavior of the developer)

Memory

Availability: Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Access control (memory and instruction processing): Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.

Other: When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Pre-design: Use a language or compiler that performs automatic bounds checking.

Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.

Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible, but should not be relied upon.

Operational: Use OS-level preventative functionality. Not a complete solution.

C Example:

Heap-based buffer overflows are usually just as dangerous as stack-based buffer overflows. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.

CLASP - Heap overflow

C

C++

Implementation

A buffer overflow where the buffer from the Buffer Write Operation is dynamically allocated

460 (Weakness Variant)

Medium

Implementation: The code could be left in a bad state.

Implementation: If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely.

C++/Java Example:

In this case, you may leave a thread locked accidentally.

Often, when functions or loops become complicated, some level of cleanup in the beginning to the end is needed. Often, since exceptions can disturb the flow of the code, one can leave a code block in a bad state.

CLASP - Improper cleanup on thrown exception

C

C++

Java

.NET