Improper administration of the permissions to the users of a
system can result in unintended access to sensitive files.
Alternate Terms
Authorization:
The terms "authorization" and "access control" seem to be used
interchangeably.
Time of Introduction
Architecture and Design
Implementation
Operation
Potential Mitigations
ID
Phase
Description
1
Very carefully manage the setting, management and handling of
privileges. Explicitly manage trust zones in the software.
Architecture and Design
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
Background Details
An access control list (ACL) represents who/what has permissions to a
given object. Different operating systems implement (ACLs) in different
ways. In UNIX, there are three types of permissions: read, write, and
execute. Users are divided into three classes for file access: owner, group
owner, and all other users where each class has a separate set of rights. In
Windows NT, there are four basic types of permissions for files: "No
access", "Read access", "Change access", and "Full control". Windows NT
extends the concept of three types of users in UNIX to include a list of
users and groups along with their associated permissions. A user can create
an object (file) and assign specified permissions to that object.
The name of this item implies that it is a category for general access
control / authorization issues, although the description is limited to
permissions.
This item needs more work. Possible sub-categories include:
Software operating in a MAC OS environment, where .DS_Store is
in effect, must carefully manage hard links, otherwise an attacker may be able
to leverage a hard link from .DS_Store to overwrite arbitrary files and gain
privileges.
The Finder in Mac OS X and earlier allows local
users to overwrite arbitrary files and gain privileges by creating a hard
link from the .DS Store file to an arbitrary
file.
This entry, which originated from PLOVER, probably stems from a common
manipulation that is used to exploit symlink and hard link following
weaknesses, like /etc/passwd is often used for UNIX-based exploits. As such,
it is probably too low-level for inclusion in CWE.
The software does not sufficiently delimit the arguments being
passed to a component in another control sphere, allowing alternate arguments to
be provided, leading to potentially security-relevant
changes.
Argument injection vulnerability in TellMe 1.2 and
earlier allows remote attackers to modify command line arguments for the
Whois program and obtain sensitive information via "--" style options in the
q Host parameter.
Beagle before 0.2.5 can produce certain insecure
command lines to launch external helper applications while indexing, which
allows attackers to execute arbitrary commands. NOTE: it is not immediately
clear whether this issue involves argument injection, shell metacharacters,
or other issues.
Argument injection vulnerability in Internet
Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to
modify command line arguments to an invoked mail client via " (double quote)
characters in a mailto: scheme handler, as demonstrated by launching
Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is
not clear whether this issue is implementation-specific or a problem in the
Microsoft API.
Argument injection vulnerability in Mozilla
Firefox 1.0.6 allows user-assisted remote attackers to modify command line
arguments to an invoked mail client via " (double quote) characters in a
mailto: scheme handler, as demonstrated by launching Microsoft Outlook with
an arbitrary filename as an attachment. NOTE: it is not clear whether this
issue is implementation-specific or a problem in the Microsoft
API.
Argument injection vulnerability in Avant Browser
10.1 Build 17 allows user-assisted remote attackers to modify command line
arguments to an invoked mail client via " (double quote) characters in a
mailto: scheme handler, as demonstrated by launching Microsoft Outlook with
an arbitrary filename as an attachment. NOTE: it is not clear whether this
issue is implementation-specific or a problem in the Microsoft
API.
Argument injection vulnerability in the URI
handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows
remote authorized attackers to download arbitrary files via a URL that
contains certain command-line switches.
Argument injection vulnerability in WinSCP 3.8.1
build 328 allows remote attackers to upload or download arbitrary files via
encoded spaces and double-quote characters in a scp or sftp
URI.
Argument injection vulnerability in the Windows
Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and
Server 2003 SP1 and earlier allows remote user-assisted attackers to execute
arbitrary commands via a crafted file with a "/" (slash) character in the
filename of the Command Line property, followed by a valid file extension,
which causes the command before the slash to be executed, aka "Object
Packager Dialogue Spoofing Vulnerability."
Argument injection vulnerability in HyperAccess
8.4 allows user-assisted remote attackers to execute arbitrary vbscript and
commands via the /r option in a telnet:// URI, which is configured to use
hawin32.exe.
Argument injection vulnerability in the telnet
daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets
certain client "-f" sequences as valid requests for the login program to
skip authentication, which allows remote attackers to log into certain
accounts, as demonstrated by the bin account.
Language interpreter's mail function accepts
another argument that is concatenated to a string used in a dangerous
popen() call. Since there is no sanitization against this argument, both OS
Command Injection (CWE-78) and Argument Injection (CWE-88) are
possible.
Potential Mitigations
Phase
Description
Avoid using user-controlled input in command arguments.
Assume all input is malicious. Use an appropriate combination of black
lists and white lists to ensure only valid and expected input is
processed by the system.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
At one layer of abstraction, this can overlap other weaknesses that have
whitespace problems, e.g. injection of javascript into attributes of HTML
tags.
Affected Resources
System Process
Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Argument Injection or Modification
CERT C Secure Coding
ENV03-C
Sanitize the environment when invoking external
programs
CERT C Secure Coding
ENV04-C
Do not call system() if you do not need a command
processor
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Definition in a New Window
Compound Element ID: 120 (Compound Element Base: Composite)
Status: Incomplete
Description
Description Summary
The program copies an input buffer to an output buffer without
verifying that the size of the input buffer is less than the size of the output
buffer, leading to a buffer overflow.
Extended Description
A buffer overflow condition exists when a program attempts to put more
data in a buffer than it can hold, or when a program attempts to put data in
a memory area outside of the boundaries of a buffer. The simplest type of
error, and the most common cause of buffer overflows, is the "classic" case
in which the program copies the buffer without checking its length at all.
Other variants exist, but the existence of a classic overflow strongly
suggests that the programmer is not considering even the most basic of
security protections.
Alternate Terms
buffer overrun:
Some prominent vendors and researchers use the term "buffer overrun,"
but most people use "buffer overflow."
Unbounded Transfer
Terminology Notes
Many issues that are now called "buffer overflows" are substantively
different than the "classic" overflow, including entirely different bug
types that rely on overflow exploit techniques, such as integer signedness
errors, integer overflows, and format string bugs. This imprecise
terminology can make it difficult to determine which variant is being
reported.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Common Consequences
Scope
Effect
Availability
Buffer overflows generally lead to crashes. Other attacks leading to
lack of availability are possible, including putting the program into an
infinite loop.
Integrity
Buffer overflows often can be used to execute arbitrary code, which is
usually outside the scope of a program's implicit security
policy.
Integrity
When the consequence is arbitrary code execution, this can often be
used to subvert any other security service.
By replacing a valid cookie value with an
extremely long string of characters, an attacker may overflow the
application's buffers.
Potential Mitigations
Phase
Description
Architecture and Design
Use an abstraction library to abstract away risky APIs. Examples
include the Safe C String Library (SafeStr) by Viega, and the Strsafe.h
library from Microsoft. This is not a complete solution, since many
buffer overflows are not related to strings.
Architecture and Design
Use the <strsafe.h> library. This library has buffer
overflow safe functions that will help with the detection of buffer
overflows.
Build and Compilation
Use automatic buffer overflow detection mechanisms that are offered by
certain compilers or compiler extensions. Examples include StackGuard,
ProPolice and the Microsoft Visual Studio /GS flag. This is not
necessarily a complete solution, since these canary-based mechanisms
only detect certain types of overflows. In addition, the result is still
a denial of service, since the typical response is to exit the
application.
Implementation
Programmers should adhere to the following rules when allocating and
managing their applications memory: Double check that your buffer is as
large as you specify. When using functions that accept a number of bytes
to copy, such as strncpy(), be aware that if the destination buffer size
is equal to the source buffer size, it may not NULL-terminate the
string. Check buffer boundaries if calling this function in a loop and
make sure you are not in danger of writing past the allocated space.
Truncate all input strings to a reasonable length before passing them to
the copy and concatenation functions
Operation
Use a feature like Address Space Layout Randomization (ASLR). This is
not a complete solution. However, it forces the attacker to guess an
unknown value that changes every program execution.
Operation
Use a CPU and operating system that offers Data Execution Protection
(NX) or its equivalent. This is not a complete solution, since buffer
overflows could be used to overwrite nearby variables to modify the
software's state in dangerous ways.
Build and Compilation
Operation
Most mitigating technologies at the compiler or OS level to date
address only a subset of buffer overflow problems and rarely provide
complete protection against even that subset. It is good practice to
implement strategies to increase the workload of an attacker, such as
leaving the attacker to guess an unknown value that changes every
program execution.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Primary
(where the
weakness exists independent of other weaknesses)
At the code level, stack-based and heap-based overflows do not differ
significantly, so there usually is not a need to distinguish them. From the
attacker perspective, they can be quite different, since different
techniques are required to exploit them.
Affected Resources
Memory
Functional Areas
Memory Management
Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Unbounded Transfer ('classic overflow')
7 Pernicious Kingdoms
Buffer Overflow
CLASP
Buffer overflow
OWASP Top Ten 2004
A1
CWE More Specific
Unvalidated Input
OWASP Top Ten 2004
A5
CWE More Specific
Buffer Overflows
CERT C Secure Coding
STR35-C
Do not copy data from an unbounded source to a fixed-length
array
A weakness where the code path includes a Buffer Write Operation such
that:
1. the expected size of the buffer is greater than the actual size of
the buffer where expected size is equal to the sum of the size of the
data item and the position in the buffer
Where Buffer Write Operation is a statement that writes a data item of a
certain size into a buffer at a certain position and at a certain
index
The program calls a thread's run() method instead of calling
start(), which causes the code to run in the thread of the caller instead of the
callee.
Extended Description
In most cases a direct call to a Thread object's run() method is a bug.
The programmer intended to begin a new thread of control, but accidentally
called run() instead of start(), so the run() method will execute in the
caller's thread of control.
Time of Introduction
Implementation
Applicable Platforms
Languages
Java
Demonstrative Examples
Example 1
The following excerpt from a Java program mistakenly calls run()
instead of start().
(Bad Code)
Java
Thread thr = new Thread() {
public void run() {
...
}
};
thr.run();
Potential Mitigations
Phase
Description
Use the start() method instead of the run() method.
Sensitive memory is cleared according to the source code, but
compiler optimizations leave the memory untouched when it is not read from
again, aka "dead store removal."
Extended Description
This compiler optimization error occurs when:
1. Secret data are stored in memory.
2. The secret data are scrubbed from memory by overwriting its
contents.
3. The source code is compiled using an optimizing compiler, which
identifies and removes the function that overwrites the contents as a
dead store because the memory is not used subsequently.
Time of Introduction
Implementation
Build and Compilation
Applicable Platforms
Languages
C
C++
Detection Factors
Black Box:
This specific weakness is impossible to detect using black box
methods. While an analyst could examine memory to see that it has not
been scrubbed, an analysis of the executable would not be successful.
This is because the compiler has already removed the relevant code. Only
the source code shows whether the programmer intended to clear the
memory or not, so this weakness is indistinguishable from others.
White Box:
This weakness is only detectable using white box methods (see black
box detection factor). Careful analysis is required to determine if the
code is likely to be removed by the compiler.
Demonstrative Examples
Example 1
The following code reads a password from the user, uses the password
to connect to a back-end mainframe and then attempts to scrub the password
from memory using memset().
(Bad Code)
C
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {
if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}
The code in the example will behave correctly if it is executed
verbatim, but if the code is compiled using an optimizing compiler, such
as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will
be removed as a dead store because the buffer pwd is not used after its
value is overwritten [18]. Because the buffer pwd contains a sensitive
value, the application may be vulnerable to attack if the data are left
memory resident. If attackers are able to access the correct region of
memory, they may use the recovered password to gain control of the
system. It is common practice to overwrite sensitive data manipulated in
memory, such as passwords or cryptographic keys, in order to prevent
attackers from learning system secrets. However, with the advent of
optimizing compilers, programs do not always behave as their source code
alone would suggest. In the example, the compiler interprets the call to
memset() as dead code because the memory being written to is not
subsequently used, despite the fact that there is clearly a security
motivation for the operation to occur. The problem here is that many
compilers, and in fact many programming languages, do not take this and
other security concerns into consideration in their efforts to improve
efficiency. Attackers typically exploit this type of vulnerability by
using a core dump or runtime mechanism to access the memory used by a
particular application and recover the secret information. Once an
attacker has access to the secret information, it is relatively
straightforward to further exploit the system and possibly compromise
other resources with which the application interacts.
Potential Mitigations
Phase
Description
Implementation
Store the sensitive data in a "volatile" memory location if
available.
Build and Compilation
If possible, configure your compiler so that it does not remove dead
stores.
Architecture and Design
Where possible, encrypt sensitive data that are used by a software
system.
The product calls free() twice on the same memory address,
potentially leading to modification of unexpected memory
locations.
Extended Description
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.
Alternate Terms
Double-free
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Common Consequences
Scope
Effect
Access Control
Doubly freeing memory may result in a write-what-where condition,
allowing an attacker to execute arbitrary code.
Likelihood of Exploit
Low to Medium
Demonstrative Examples
Example 1
The following code shows a simple example of a double free
vulnerability.
(Bad Code)
C
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);
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.
Choose a language that provides automatic memory management.
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.
Implementation
Use a static analysis tool to find double free instances.
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.
Affected Resources
Memory
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
DFREE - Double-Free Vulnerability
7 Pernicious Kingdoms
Double Free
CLASP
Doubly freeing memory
CERT C Secure Coding
MEM00-C
Allocate and free memory in the same module, at the same level
of abstraction
CERT C Secure Coding
MEM01-C
Store a new value in pointers immediately after
free()
CERT C Secure Coding
MEM31-C
Free dynamically allocated memory exactly
once
White Box Definitions
A weakness where code path has:
1. start statement that relinquishes a dynamically allocated memory
resource
2. end statement that relinquishes the dynamically allocated memory
resource
Maintenance Notes
It could be argued that Double Free would be most appropriately located as
a child of "Use after Free", but "Use" and "Release" are considered to be
distinct operations within vulnerability theory, therefore this is more
accurately "Release of a Resource after Expiration or Release", which
doesn't exist yet.
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Potential Mitigations,
Time of Introduction
2008-08-01
KDM Analytics
External
added/updated white box definitions
2008-09-08
CWE Content Team
MITRE
Internal
updated Applicable Platforms, Common Consequences,
Description, Maintenance Notes, Relationships, Other Notes,
Relationship Notes, Taxonomy Mappings
Failure to Change Working Directory in chroot Jail
Definition in a New Window
Weakness ID: 243 (Weakness Variant)
Status: Draft
Description
Description Summary
The program uses the chroot() system call to create a jail, but
does not change the working directory afterward. This does not prevent access to
files outside of the jail.
Extended Description
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.
Time of Introduction
Implementation
Applicable Platforms
Languages
C
C++
Operating Systems
UNIX
Likelihood of Exploit
High
Demonstrative Examples
Example 1
Consider the following source code from a (hypothetical) FTP
server:
(Bad Code)
C
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF)
{
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);
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.
Background Details
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.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Failure to Clear Heap Memory Before Release ('Heap Inspection')
Definition in a New Window
Weakness ID: 244 (Weakness Variant)
Status: Draft
Description
Description Summary
Using realloc() to resize buffers that store sensitive
information can leave the sensitive information exposed to attack, because it is
not removed from memory.
Extended Description
When sensitive data such as a password or an encryption key is not removed
from memory, it could be exposed to an attacker using a "heap inspection"
attack that reads the sensitive data using memory dumps or other methods.
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.
Time of Introduction
Implementation
Applicable Platforms
Languages
C
C++
Common Consequences
Scope
Effect
Confidentiality
Be careful using vfork() and fork() in security sensitive code. The
process state will not be cleaned up and will contain traces of data
from past use.
Demonstrative Examples
Example 1
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.
Failure to Constrain Operations within the Bounds of a Memory Buffer
Definition in a New Window
Weakness ID: 119 (Weakness Class)
Status: Usable
Description
Description Summary
The software performs operations on a memory buffer, but it can
read from or write to a memory location that is outside of the intended boundary
of the buffer.
Extended Description
Certain languages allow direct addressing of memory locations and do not
automatically ensure that these locations are valid for the memory buffer
that is being referenced. This can cause read or write operations to be
performed on memory locations that may be associated with other variables,
data structures, or internal program data.
As a result, an attacker may be able to execute arbitrary code, alter the
intended control flow, read sensitive information, or cause the system to
crash.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
C: (Often)
C++: (Often)
All
Platform Notes
It is possible in many programming languages to attempt an operation
outside of the bounds of a memory buffer, but the consequences will vary
widely depending on the language, platform, and chip architecture.
Common Consequences
Scope
Effect
Integrity
If the memory accessible by the attacker can be effectively
controlled, it may be possible to execute arbitrary code, as with a
standard buffer overflow.
If the attacker can overwrite a pointer's worth of memory (usually 32
or 64 bits), he can redirect a function pointer to his own malicious
code. Even when the attacker can only modify a single byte arbitrary
code execution can be possible. Sometimes this is because the same
problem can be exploited repeatedly to the same effect. Other times it
is because the attacker can overwrite security-critical
application-specific data -- such as a flag indicating whether the user
is an administrator.
Availability
Out of bounds memory access will very likely result in the corruption
of relevant memory, and perhaps instructions, possibly leading to a
crash. Other attacks leading to lack of availability are possible,
including putting the program into an infinite loop.
Confidentiality
In the case of an out-of-bounds read, the attacker may have access to
sensitive information. If the sensitive information contains system
details, such as the current buffers position in memory, this knowledge
can be used to craft further attacks, possibly with more severe
consequences.
Likelihood of Exploit
High
Demonstrative Examples
Example 1
This example takes an IP address from a user, verifies that it is
well formed and then looks up the hostname and copies it into a
buffer.
(Bad Code)
C
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);
/*routine that ensures user_supply_addr is in the right format
for conversion */
validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr),
AF_INET);
strcpy(&hostname, hp->h_name);
}
This function allocates a buffer of 64 bytes to store the hostname,
however there is no guarantee that the hostname will not be larger than
64 bytes. If an attacker specifies an address which resolves to a very
large hostname, then we may overwrite sensitive data or even relinquish
control flow to the attacker.
Example 2
This example applies an encoding procedure to an input string and
stores it into a buffer.
The programmer attempts to encode the ampersand character in the
user-controlled string, however the length of the string is validated
before the encoding procedure is applied. Furthermore, the programmer
assumes encoding expansion will only expand a given character by a
factor of 4, while the encoding of the ampersand expands by 5. As a
result, when the encoding procedure expands the string it is possible to
overflow the destination buffer if the attacker provides a string of
many ampersands.
Example 3
The following example asks a user for an offset into an array to
select an item.
The programmer allows the user to specify which element in the list to
select, however an attacker can provide an out-of-bounds offset,
resulting in a buffer over-read (CWE-126).
OS kernel trusts userland-supplied length value,
allowing reading of sensitive information
Potential Mitigations
Phase
Description
Requirements
Use a language with features that can automatically mitigate or
eliminate buffer overflows.
For example, many languages that perform their own memory management,
such as Java and Perl, are not subject to buffer overflows. Other
languages, such as Ada and C#, typically provide overflow protection,
but the protection can be disabled by the programmer.
Be wary that a language's interface to native code may still be
subject to overflows, even if the language itself is theoretically safe.
Architecture and Design
Use languages, libraries, or frameworks that make it easier to manage
buffers without exceeding their boundaries.
Examples include the Safe C String Library (SafeStr) by Messier and
Viega, and the Strsafe.h library from Microsoft. These libraries provide
safer versions of overflow-prone string-handling functions. This is not
a complete solution, since many buffer overflows are not related to
strings.
Build and Compilation
Run or compile your software using features or extensions that
automatically provide a protection mechanism that mitigates or
eliminates buffer overflows.
For example, certain compilers and extensions provide automatic buffer
overflow detection mechanisms that are built into the compiled code.
Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat
FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.
This is not necessarily a complete solution, since these mechanisms
can only detect certain types of overflows. In addition, a buffer
overflow attack can still cause a denial of service, since the typical
response is to exit the application.
Implementation
Programmers should adhere to the following rules when allocating and
managing their application's memory:
Double check that your buffer is as large as you specify.
When using functions that accept a number of bytes to copy, such
as strncpy(), be aware that if the destination buffer size is equal
to the source buffer size, it may not NULL-terminate the
string.
Check buffer boundaries if calling this function in a loop and
make sure you are not in danger of writing past the allocated
space.
If necessary, truncate all input strings to a reasonable length
before passing them to the copy and concatenation functions.
Testing
Use automated static analysis tools that target this type of weakness.
Many modern techniques use data flow analysis to minimize the number of
false positives. This is not a perfect solution, since 100% accuracy and
coverage are not feasible.
Testing
Use dynamic tools and techniques that interact with the software using
large test suites with many diverse inputs, such as fuzz testing
(fuzzing), robustness testing, and fault injection. The software's
operation may slow down, but it should not become unstable, crash, or
generate incorrect results.
Operation
Use a feature like Address Space Layout Randomization (ASLR). This is
not a complete solution. However, it forces the attacker to guess an
unknown value that changes every program execution.
Operation
Use a CPU and operating system that offers Data Execution Protection
(NX) or its equivalent. This is not a complete solution, since buffer
overflows could be used to overwrite nearby variables to modify the
software's state in dangerous ways. In addition, it cannot be used in
cases in which self-modifying code is required.
Failure to Handle Windows ::DATA Alternate Data Stream
Definition in a New Window
Weakness ID: 69 (Weakness Variant)
Status: Incomplete
Description
Description Summary
The software does not properly prevent access to, or detect
usage of, alternate data streams (ADS).
Extended Description
An attacker can use an ADS to hide information about a file (e.g. size,
the name of the process) from a system or file browser tools such as Windows
Explorer and 'dir' at the command line utility. Alternately, the attacker
might be able to bypass intended access restrictions for the associated data
fork.
Software tools are capable of finding ADSs on your system.
Ensure that the source code correctly parses the filename to read or
write to the correct stream.
Background Details
Alternate data streams (ADS) were first implemented in the Windows NT
operating system to provide compatibility between NTFS and the Macintosh
Hierarchical File System (HFS). In HFS, data and resource forks are used to
store information about a file. The data fork provides information about the
contents of the file while the resource fork stores metadata such as file
type.
Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Definition in a New Window
Weakness ID: 401 (Weakness Base)
Status: Draft
Description
Description Summary
The software does not sufficiently track and release allocated
memory after it has been used, which slowly consumes remaining
memory.
Extended Description
This is often triggered by improper handling of malformed data or
unexpectedly interrupted sessions.
Terminology Notes
"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).
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Modes of Introduction
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
Common Consequences
Scope
Effect
Availability
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 or
hanging the program) or take advantage of other unexpected program
behavior resulting from a low memory condition.
Likelihood of Exploit
Medium
Demonstrative Examples
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:
(Bad Code)
C
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
Example 2
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.
Pre-design: Use a language or compiler that performs automatic bounds
checking.
Architecture and 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.
This is often a resultant weakness due to improper handling of malformed
data or early termination of sessions.
Affected Resources
Memory
Functional Areas
Memory management
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Memory leak
7 Pernicious Kingdoms
Memory Leak
CLASP
Failure to deallocate data
OWASP Top Ten 2004
A9
CWE More Specific
Denial of Service
White Box Definitions
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. the statement assigns another value to the data element that stored
the identity of the dynamically allocated memory resource and there are
no aliases of that data element
3. identity of the dynamic allocated memory resource obtained but
never passed on to function for memory resource release
4. the data element that stored the identity of the dynamically
allocated resource has reached the end of its scope at the statement and
there are no aliases of that data element
References
J. Whittaker and
H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Time of Introduction
2008-08-01
KDM Analytics
External
added/updated white box definitions
2008-08-15
Veracode
External
Suggested OWASP Top Ten 2004
mapping
2008-09-08
CWE Content Team
MITRE
Internal
updated Applicable Platforms, Common Consequences,
Relationships, Other Notes, References, Relationship Notes,
Taxonomy Mappings, Terminology Notes
The software does not properly account for differences in case
sensitivity when accessing or determining the properties of a resource, leading
to inconsistent results.
Extended Description
Improperly handled case sensitive data can lead to several possible
consequences, including:
case-insensitive passwords reducing the size of the key space, making
brute force attacks easier
bypassing filters or access controls using alternate names
multiple interpretation errors using alternate names.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Demonstrative Examples
Example 1
In the following example, an XSS sanitization routine only checks
for the lower-case "script" string, which can be easily defeated using tags
such as SCRIPT or ScRiPt.
(Bad Code)
Java
public String sanitize(String input, String mask) {
The server is case sensitive, so filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
The server is case sensitive, so filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
A URL that contains some characters whose case is
not matched by the server's filters may bypass access restrictions because
the case-insensitive file system will then handle the request after it
bypasses the case sensitive filter.
chain: Code was ported from a case-sensitive Unix
platform to a case-insensitive Windows platform where filetype handlers
treat .jsp and .JSP as different extensions. JSP source code may be read
because .JSP defaults to the filetype "text".
Chain: uppercase file extensions causes web server
to return script source code instead of executing the
script.
Potential Mitigations
Phase
Description
Avoid making decisions based on names of resources (e.g. files) if
those resources can have alternate names.
Architecture and Design
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be displayed or stored. Use an
"accept known good" validation strategy.
Use and specify a strong output encoding (such as ISO 8859-1 or UTF
8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist schemes by introducing dangerous inputs
after they have been checked.
These are probably under-studied in Windows and Mac environments, where
file names are case-insensitive and thus are subject to equivalence
manipulations involving case.
Affected Resources
File/Directory
Functional Areas
File Processing, Credentials
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Case Sensitivity (lowercase, uppercase, mixed
case)
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Sean Eidemiller
Cigital
External
added/updated demonstrative
examples
2008-07-01
Eric Dalci
Cigital
External
updated Potential Mitigations,
Time of Introduction
2008-09-08
CWE Content Team
MITRE
Internal
updated Description, Relationships, Observed Example,
Taxonomy Mappings
A heap overflow condition is a buffer overflow, where the
buffer that can be overwritten is allocated in the heap portion of memory,
generally meaning that the buffer was allocated using a routine such as
malloc().
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Common Consequences
Scope
Effect
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
Buffer overflows often can be used to execute arbitrary code, which is
usually outside the scope of a program's implicit security
policy.
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.
Other
When the consequence is arbitrary code execution, this can often be
used to subvert any other security service.
Chain: integer signedness passes signed
comparison, leads to heap overflow
Potential Mitigations
Phase
Description
Pre-design: Use a language or compiler that performs automatic bounds
checking.
Architecture and 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.
Implement and perform bounds checking on input.
Do not use dangerous functions such as gets. Look for their safe
equivalent, which checks for the boundary.
Operational: Use OS-level preventative functionality. This is not a
complete solution, but it provides some defense in depth.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
The software attempts to drop privileges but does not check or
incorrectly checks to see if the drop succeeded.
Extended Description
If the drop fails, the software will continue to run with the raised
privileges, which might provide additional access to unprivileged
users.
Time of Introduction
Architecture and Design
Implementation
Operation
Applicable Platforms
Languages
All
Modes of Introduction
This issue is likely to occur in restrictive environments in which the
operating system or application provides fine-grained control over privilege
management.
Common Consequences
Scope
Effect
Authorization
If privileges are not dropped, neither are access rights of the user.
Often these rights can be prevented from being dropped.
Authentication
If privileges are not dropped, in some cases the system may record
actions as the user which is being impersonated rather than the
impersonator.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
(Bad Code)
C and C++
bool DoSecureStuff(HANDLE hPipe) {
bool fDataWritten = false;
ImpersonateNamedPipeClient(hPipe);
HANDLE hFile = CreateFile(...);
/../
RevertToSelf()
/../
}
Since we did not check the return value of ImpersonateNamedPipeClient,
we do not know if the call succeeded.
Potential Mitigations
Phase
Description
Architecture and Design
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
Implementation
In Windows make sure that the process token has the
SeImpersonatePrivilege(Microsoft Server 2003).
Implementation
Always check all of your return values.
Other Notes
In Microsoft Operating environments that have access control,
impersonation is used so that access checks can be performed on a client
identity by a server with higher privileges. By impersonating the client,
the server is restricted to client-level security -- although in different
threads it may have much higher privileges. Code which relies on this for
security must ensure that the impersonation succeeded-- i.e., that a proper
privilege demotion happened.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')
Definition in a New Window
Compound Element ID: 98 (Compound Element Base: Composite)
Status: Draft
Description
Description Summary
The PHP application receives input from an upstream component,
but it does not restrict or incorrectly restricts the input before its usage in
"require," "include," or similar functions.
Extended Description
In certain versions and configurations of PHP, this can allow an attacker
to specify a URL to a remote location from which the software will obtain
the code to execute. In other cases in association with path traversal, the
attacker can specify a local file that may contain executable statements
that can be parsed by PHP.
PHP file inclusion issue, both remote and local;
local include uses ".." and "%00" characters as a manipulation, but many
remote file inclusion issues probably have this
vector.
Potential Mitigations
Phase
Description
Assume all input is malicious. Use an appropriate combination of black
lists and white lists to ensure only valid and expected input is
processed by the system.
This is frequently a functional consequence of other weaknesses. It is
usually multi-factor with other factors (e.g. MAID), although not all
inclusion bugs involve assumed-immutable data. Direct request weaknesses
frequently play a role.
Can overlap directory traversal in local inclusion problems.
Research Gaps
Under-researched and under-reported. Other interpreted languages with
"require" and "include" functionality could also product vulnerable
applications, but as of 2007, PHP has been the focus. Any web-accessible
language that uses executable file extensions is likely to have this type of
issue, such as ASP, since .asp extensions are typically executable.
Languages such as Perl are less likely to exhibit these problems because the
.pl extension isn't always configured to be executable by the web
server.
Improper Handling of Apple HFS+ Alternate Data Stream Path
Definition in a New Window
Weakness ID: 72 (Weakness Variant)
Status: Incomplete
Description
Description Summary
The software does not properly handle special paths that may
identify the data or resource fork of a file on the HFS+ file
system.
Extended Description
If the software chooses actions to take based on the file name, then if an
attacker provides the data or resource fork, the software may take
unexpected actions. Further, if the software intends to restrict access to a
file, then an attacker might still be able to bypass intended access
restrictions by requesting the data or resource fork for that file.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Operating Systems
Mac OS
Demonstrative Examples
Example 1
A web server that interprets FILE.cgi as processing instructions
could disclose the source code for FILE.cgi by requesting
FILE.cgi/..namedfork/data. This might occur because the web server invokes
the default handler which may return the contents of the file.
The Apple HFS+ file system permits files to have multiple data input
streams, accessible through special paths. The Mac OS X operating system
provides a way to access the different data input streams through special
paths and as an extended attribute:
- Data fork: file/..namedfork/data (only versions prior to Mac OS X
v10.5)
Additionally, on filesystems that lack native support for multiple
streams, the resource fork and file metadata may be stored in a file with
"._" prepended to the name.
Forks can also be accessed through non-portable APIs.
Forks inherit the file system access controls of the file they belong
to.
Programs need to control access to these paths, if the processing of a
file system object is dependent on the structure of its path.
The software constructs pathnames from user input, but it does
not handle or incorrectly handles a pathname containing a Windows device name
such as AUX or CON. This typically leads to denial of service or an information
leak when the application attempts to process the pathname as a regular
file.
Extended Description
Failing to properly handle virtual filenames (e.g. AUX, CON, PRN, COM1,
LPT1) can result in different types of vulnerabilities. In some cases an
attacker can request a device via injection of a virtual filename in a URL,
which may cause an error that leads to a denial of service or an error page
that reveals sensitive information. A software system that allows device
names to bypass filtering runs the risk of an attacker injecting malicious
code in a file with the name of a device.
Be familiar with the device names in the operating system where your
system is deployed. Check input for these device names.
Background Details
Historically, there was a bug in the Windows operating system that caused
a blue screen of death. Even after that issue was fixed DOS device names
continue to be a factor.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Improper Link Resolution Before File Access ('Link Following')
Definition in a New Window
Weakness ID: 59 (Weakness Base)
Status: Draft
Description
Description Summary
The software attempts to access a file based on the filename,
but it does not properly prevent that filename from identifying a link or
shortcut that resolves to an unintended resource.
Alternate Terms
insecure temporary file:
Some people use the phrase "insecure temporary file" when referring to
a link following weakness, but other weaknesses can produce insecure
temporary files without any symlink involvement at all.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Operating Systems
Windows: (Sometimes)
UNIX: (Often)
Likelihood of Exploit
Low to Medium
Potential Mitigations
Phase
Description
Follow the principle of least privilege when assigning access rights
to files. Denying access to a file can prevent an attacker from
replacing that file with a link to a sensitive file. Ensure good
compartmentalization in the system to provide protected areas that can
be trusted.
Background Details
: Soft links are a UNIX term that is synonymous with simple shortcuts on
windows based platforms.
Other Notes
Windows simple shortcuts, sometimes referred to as soft links, can be
exploited remotely since an ".LNK" file can be uploaded like a normal
file.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Link following vulnerabilities are Multi-factor Vulnerabilities (MFV).
They are the combination of multiple elements: file or directory
permissions, filename predictability, race conditions, and in some cases, a
design limitation in which there is no mechanism for performing atomic file
creation operations.
Some potential factors are race conditions, permissions, and
predictability.
Research Gaps
UNIX hard links, and Windows hard/soft links are under-studied and
under-reported.
Affected Resources
File/Directory
Functional Areas
File processing, temporary files
Causal Nature
Explicit
Taxonomy Mappings
Mapped Taxonomy Name
Node ID
Fit
Mapped Node Name
PLOVER
Link Following
CERT C Secure Coding
FIO02-C
Canonicalize path names originating from untrusted
sources
CERT C Secure Coding
POS01-C
Check for the existence of links when dealing with
files
The relationships between privileges, permissions, and actors (e.g. users
and groups) need further refinement within the Research view. One
complication is that these concepts apply to two different pillars, related
to control of resources (CWE-664) and protection mechanism failures
(CWE-396).
The system or application is vulnerable to file system contents
disclosure through path equivalence. Path equivalence involves the use of
special characters in file and directory names. The associated manipulations are
intended to generate multiple names for the same object.
Extended Description
Path equivalence is usually employed in order to circumvent access
controls expressed using an incomplete set of file name or file path
representations. This is different from path traversal, wherein the
manipulations are performed to generate a name for a different
object.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Potential Mitigations
Phase
Description
Architecture and Design
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be displayed or stored. Use an
"accept known good" validation strategy. Input (specifically, unexpected
CRLFs) that is not appropriate should not be processed into HTTP
headers.
Use and specify a strong output encoding (such as ISO 8859-1 or UTF
8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist schemes by introducing dangerous inputs
after they have been checked.
Other Notes
Some of these manipulations could be effective in path traversal issues,
too.
Improper Sanitization of Directives in Statically Saved Code ('Static Code Injection')
Definition in a New Window
Weakness ID: 96 (Weakness Base)
Status: Draft
Description
Description Summary
The software receives input from an upstream component, but it
does not sanitize or incorrectly sanitizes code syntax before inserting the
input into an executable resource, such as a library, configuration file, or
template.
PHP code from User-Agent HTTP header directly
inserted into log file implemented as PHP
script.
Potential Mitigations
Phase
Description
Assume all input is malicious. Use an appropriate combination of black
lists and white lists to filter code syntax from user-controlled
input.
Avoid writing user-controlled input to code files.
Perform output validation to filter all code syntax from data written
to non-code files.
Other Notes
"HTML injection" (see XSS) could be thought of as an example of this, but
it is executed on the client side, not the server side. Server-Side Includes
(SSI) are an example of direct static code injection.
This issue is most frequently found in PHP applications that allow users
to set configuration variables that are stored within executable php files.
Technically, this could also be performed in some compiled code (e.g. by
byte-patching an executable), although it is highly unlikely.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
Improper Sanitization of Special Elements used in an OS Command ('OS Command Injection')
Definition in a New Window
Weakness ID: 78 (Weakness Base)
Status: Draft
Description
Description Summary
The software constructs all or part of an OS command using
externally-influenced input from an upstream component, but it does not sanitize
or incorrectly sanitizes special elements that could modify the intended OS
command when it is sent to a downstream component.
Extended Description
This could allow attackers to execute unexpected, dangerous commands
directly on the operating system. This weakness can lead to a vulnerability
in environments in which the attacker does not have direct access to the
operating system, such as in web applications. Alternately, if the weakness
occurs in a privileged program, it could allow the attacker to specify
commands that normally would not be accessible, or to call alternate
commands with privileges that the attacker does not have. The problem is
exacerbated if the compromised process fails to follow the principle of
least privilege, because the attacker-controlled commands may run with
special system privileges that increases the amount of damage.
There are at least two subtypes of OS command injection:
1) The application intends to execute a single, fixed program that is
under its own control. It intends to use externally-supplied inputs as
arguments to that program. For example, the program might use
system("nslookup [HOSTNAME]") to run nslookup and allow the user to
supply a HOSTNAME, which is used as an argument. Attackers cannot
prevent nslookup from executing. However, if the program does not remove
command separators from the HOSTNAME argument, attackers could place the
separators into the arguments, which allows them to execute their own
program after nslookup has finished executing.
2) The application accepts an input that it uses to fully select which
program to run, as well as which commands to use. The application simply
redirects this entire command to the operating system. For example, the
program might use "exec([COMMAND])" to execute the [COMMAND] that was
supplied by the user. If the COMMAND is under attacker control, then the
attacker can execute arbitrary commands or programs. If the command is
being executed using functions like exec() and CreateProcess(), the
attacker might not be able to combine multiple commands together in the
same line.
From a weakness standpoint, these variants represent distinct programmer
errors. In the first variant, the programmer clearly intends that input from
untrusted parties will be part of the arguments in the command to be
executed. In the second variant, the programmer does not intend for the
command to be accessible to any untrusted party, but the programmer probably
has not accounted for alternate ways in which malicious attackers can
provide input.
Alternate Terms
Shell injection
Shell metacharacters
Terminology Notes
The "OS command injection" phrase carries different meanings to different
people. For some, it refers to any type of attack that can allow the
attacker to execute OS commands of his or her choosing. This usage could
include untrusted search path weaknesses (CWE-426) that cause the
application to find and execute an attacker-controlled program. For others,
it only refers to the first variant, in which the attacker injects command
separators into arguments for an application-controlled program that is
being invoked. Further complicating the issue is the case when argument
injection (CWE-88) allows alternate command-line switches or options to be
inserted into the command line, such as an "-exec" switch whose purpose may
be to execute the subsequent argument as a command (this -exec switch exists
in the UNIX "find" command, for example). In this latter case, however,
CWE-88 could be regarded as the primary weakness in a chain with
CWE-78.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Confidentiality
Integrity
Availability
Non-Repudiation
Attackers could execute unauthorized commands, which could then be
used to disable the software, or read and modify data for which the
attacker does not have permissions to access directly. Since the
targeted application is directly executing the commands instead of the
attacker, any malicious activities may appear to come from the
application or the application's owner.
View Data 
