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
Compound Element ID: 352 (Compound Element Variant: Composite)
Status: Draft
Description
Description Summary
The web application does not, or can not, sufficiently verify
whether a well-formed, valid, consistent request was intentionally provided by
the user who submitted the request.
Extended Description
When a web server is designed to receive a request from a client without
any mechanism for verifying that it was intentionally sent, then it might be
possible for an attacker to trick a client into making an unintentional
request to the web server which will be treated as an authentic request.
This can be done via a URL, image load, XMLHttpRequest, etc. and can result
in data disclosure or unintended code execution.
Alternate Terms
Session Riding
Cross Site Reference Forgery
XSRF
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Technology Classes
Web-Server
Likelihood of Exploit
High
Demonstrative Examples
Example 1
This example PHP code attempts to secure the form submission process
by validating that the user submitting the form has a valid session. A CSRF
attack would not be prevented by this countermeasure because the attacker
forges a request through the user's web browser in which a valid session
already exists.
The following HTML is intended to allow a user to update a
profile.
echo "Your profile has been successfully updated.";
}
This code may look protected since it checks for a valid session.
However, CSRF attacks can be staged from virtually any tag or HTML
construct, including image tags, links, embed or object tags, or other
attributes that load background images.
The attacker can then host code that will silently change the username
and email address of any user that visits the page while remaining
logged in to the target web application. The code might be an
innocent-looking web page such as:
Notice how the form contains hidden fields, so when it is loaded into
the browser, the user will not notice it. Because SendAttack() is
defined in the body's onload attribute, it will be automatically called
when the victim loads the web page.
Assuming that the user is already logged in to victim.example.com,
profile.php will see that a valid user session has been established,
then update the email address to the attacker's own address. At this
stage, the user's identity has been compromised, and messages sent
through this profile could be sent to the attacker's address.
Perform actions as administrator via a URL or an
img tag
Potential Mitigations
Phase
Description
Architecture and Design
Use anti-CSRF packages such as the OWASP CSRFGuard.
Implementation
Ensure that your application is free of cross-site scripting issues
(CWE-79), because most CSRF defenses can be bypassed using
attacker-controlled script.
Architecture and Design
Generate a unique nonce for each form, place the nonce into the form,
and verify the nonce upon receipt of the form. Be sure that the nonce is
not predictable (CWE-330).
Note that this can be bypassed using XSS (CWE-79).
Architecture and Design
Identify especially dangerous operations. When the user performs a
dangerous operation, send a separate confirmation request to ensure that
the user intended to perform that operation.
Note that this can be bypassed using XSS (CWE-79).
Architecture and Design
Use the "double-submitted cookie" method as described by Felten and
Zeller.
Note that this can probably be bypassed using XSS (CWE-79).
Architecture and Design
Use the ESAPI Session Management control.
This control includes a component for CSRF.
Architecture and Design
Do not use the GET method for any request that triggers a state
change.
Implementation
Check the HTTP Referer header to see if the request originated from an
expected page. This could break legitimate functionality, because users
or proxies may have disabled sending the Referer for privacy
reasons.
Note that this can be bypassed using XSS (CWE-79). An attacker could
use XSS to generate a spoofed Referer, or to generate a malicious
request from a page whose Referer would be allowed.
Testing
Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow
the tester to record and modify an active session. These may be more
effective than strictly automated techniques. This is especially the
case with weaknesses that are related to design and business
rules.
Use OWASP CSRFTester to identify potential issues.
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.
Compound Element ID: 689 (Compound Element Base: Composite)
Status: Draft
Description
Description Summary
The product, while copying or cloning a resource, does not set
the resource's permissions or access control until the copy is complete, leaving
the resource exposed to other spheres while the copy is taking
place.
database product creates files world-writable
before initializing the setuid bits, leading to modification of
executables.
Other Notes
This is a general issue, although few subtypes are currently known. The
most common examples occur in file archive extraction, in which the product
begins the extraction with insecure default permissions, then only sets the
final permissions (as specified in the archive) once the copy is complete.
The larger the archive, the larger the timing window for the race condition.
This weakness has also occurred in some operating system utilities that
perform copies of deeply nested directories containing a large number of
files.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
Under-studied. It seems likely that this weakness could occur in any
situation in which a complex or large copy operation occurs, when the
resource can be made available to other spheres as soon as it is created,
but before its initialization is complete.
Compound Element ID: 384 (Compound Element Base: Composite)
Status: Incomplete
Description
Description Summary
Authenticating a user, or otherwise establishing a new user
session, without invalidating any existing session identifier gives an attacker
the opportunity to steal authenticated sessions.
Extended Description
Such a scenario is commonly observed when: 1. A web application
authenticates a user without first invalidating the existing session,
thereby continuing to use the session already associated with the user 2. An
attacker is able to force a known session identifier on a user so that, once
the user authenticates, the attacker has access to the authenticated session
3. The application or container uses predictable session identifiers. In the
generic exploit of session fixation vulnerabilities, an attacker creates a
new session on a web application and records the associated session
identifier. The attacker then causes the victim to associate, and possibly
authenticate, against the server using that session identifier, giving the
attacker access to the user's account through the active session.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Demonstrative Examples
Example 1
The following example shows a snippet of code from a J2EE web
application where the application authenticates users with
LoginContext.login() without first calling
HttpSession.invalidate().
In order to exploit the code above, an attacker could first create a
session (perhaps by logging into the application) from a public
terminal, record the session identifier assigned by the application, and
reset the browser to the login page. Next, a victim sits down at the
same public terminal, notices the browser open to the login page of the
site, and enters credentials to authenticate against the application.
The code responsible for authenticating the victim continues to use the
pre-existing session identifier, now the attacker simply uses the
session identifier recorded earlier to access the victim's active
session, providing nearly unrestricted access to the victim's account
for the lifetime of the session. Even given a vulnerable application,
the success of the specific attack described here is dependent on
several factors working in the favor of the attacker: access to an
unmonitored public terminal, the ability to keep the compromised session
active and a victim interested in logging into the vulnerable
application on the public terminal.
In most circumstances, the first two challenges are surmountable given
a sufficient investment of time. Finding a victim who is both using a
public terminal and interested in logging into the vulnerable
application is possible as well, so long as the site is reasonably
popular. The less well known the site is, the lower the odds of an
interested victim using the public terminal and the lower the chance of
success for the attack vector described above. The biggest challenge an
attacker faces in exploiting session fixation vulnerabilities is
inducing victims to authenticate against the vulnerable application
using a session identifier known to the attacker.
In the example above, the attacker did this through a direct method
that is not subtle and does not scale suitably for attacks involving
less well-known web sites. However, do not be lulled into complacency;
attackers have many tools in their belts that help bypass the
limitations of this attack vector. The most common technique employed by
attackers involves taking advantage of cross-site scripting or HTTP
response splitting vulnerabilities in the target site [12]. By tricking
the victim into submitting a malicious request to a vulnerable
application that reflects JavaScript or other code back to the victim's
browser, an attacker can create a cookie that will cause the victim to
reuse a session identifier controlled by the attacker. It is worth
noting that cookies are often tied to the top level domain associated
with a given URL. If multiple applications reside on the same top level
domain, such as bank.example.com and recipes.example.com, a
vulnerability in one application can allow an attacker to set a cookie
with a fixed session identifier that will be used in all interactions
with any application on the domain example.com [29].
Example 2
The following example shows a snippet of code from a J2EE web
application where the application authenticates users with a direct post to
the <code>j_security_check</code>, which
typically does not invalidate the existing session before processing the
login request.
(Bad Code)
HTML
<form method="POST"
action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>
Potential Mitigations
Phase
Description
Invalidate any existing session identifiers prior to authorizing a new
user session
For platforms such as ASP that do not generate new values for
sessionid cookies, utilize a secondary cookie. In this approach, set a
secondary cookie on the user's browser to a random value and set a
session variable to the same value. If the session variable and the
cookie value ever don't match, invalidate the session, and force the
user to log on again.
Other Notes
Other attack vectors include DNS poisoning and related network based
attacks where an attacker causes the user to visit a malicious site by
redirecting a request for a valid site. Network based attacks typically
involve a physical presence on the victim's network or control of a
compromised machine on the network, which makes them harder to exploit
remotely, but their significance should not be overlooked. Less secure
session management mechanisms, such as the default implementation in Apache
Tomcat, allow session identifiers normally expected in a cookie to be
specified on the URL as well, which enables an attacker to cause a victim to
use a fixed session identifier simply by emailing a malicious URL.
Use other means of identity verification that cannot be simply
spoofed. Possibilities include a username/password or
certificate.
Other Notes
As IP addresses can be easily spoofed, they do not constitute a valid
authentication mechanism. Alternate methods should be used if significant
authentication is necessary.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Compound Element ID: 61 (Compound Element Variant: Composite)
Status: Incomplete
Description
Description Summary
The software, when opening a file or directory, does not
sufficiently account for when the file is a symbolic link that resolves to a
target outside of the intended control sphere. This could allow an attacker to
cause the software to operate on unauthorized files.
Extended Description
A software system that allows UNIX symbolic links (symlink) as part of
paths whether in internal code or through user input can allow an attacker
to spoof the symbolic link and traverse the file system to unintended
locations or access arbitrary files. The symbolic link can permit an
attacker to read/write/corrupt a file that they originally did not have
permissions to access.
Setuid product allows file reading by replacing a
file being edited with a symlink to the targeted file, leaking the result in
error messages when parsing fails.
Symbolic link attacks often occur when a program creates a tmp
directory that stores files/links. Access to the directory should be
restricted to the program as to prevent attackers from manipulating the
files.
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.
Symlink vulnerabilities are regularly found in C and shell programs, but
all programming languages can have this problem. Even shell programs are
probably under-reported.
"Second-order symlink vulnerabilities" may exist in programs that invoke
other programs that follow symlinks. They are rarely reported but are likely
to be fairly common when process invocation is used. Reference:
[Christey2005]
Determine the size and type of files that users are expected to upload
to your system. Take measures to assure that the files meet those
requirements.
Other Notes
This can have a chaining relationship with incomplete blacklist /
permissive whitelist errors when the product tries, but fails, to properly
limit which types of files are allowed.
This can also overlap multiple interpretation errors for intermediaries,
e.g. anti-virus products that do not filter attachments with certain file
extensions that can be processed by client systems.
This can be primary when there is no check at all. If is frequently
resultant when use of double extensions (e.g. ".php.gif") bypass sanity
checks. Also resultant from client-side enforcement; some products will
include web script in web clients to check the filename, without verifying
on the server side.
PHP applications are most targeted, but this likely applies to other
languages that support file upload, as well as non-web technologies. ASP
applications have also demonstrated this problem.
Compound Element ID: 426 (Compound Element Base: Composite)
Status: Draft
Description
Description Summary
The application searches for critical resources using an
externally-supplied search path that can point to resources that are not under
the application's direct control.
Extended Description
This might allow attackers to execute their own programs, access
unauthorized data files, or modify configuration in unexpected ways. If the
application uses a search path to locate critical resources such as
programs, then an attacker could modify that search path to point to a
malicious program, which the targeted application would then execute. The
problem extends to any type of critical resource that the application
trusts.
Alternate Terms
Untrusted Path
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Operating Systems
All
Common Consequences
Scope
Effect
Authorization
Integrity
There is the potential for arbitrary code execution with privileges of
the vulnerable program.
Availability
The program could be redirected to the wrong files, potentially
triggering a crash or hang when the targeted file is too large or does
not have the expected format.
Confidentiality
The program could send the output of unauthorized files to the
attacker.
Likelihood of Exploit
High
Demonstrative Examples
Example 1
This program is intended to execute a command that lists the
contents of a restricted directory, then performs other actions. Assume that
it runs with setuid privileges in order to bypass the permissions check by
the operating system.
(Bad Code)
C
#define DIR "/restricted/directory"
char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR. */
RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...
This code may look harmless at first, since both the directory and the
command are set to fixed values that the attacker can't control. The
attacker can only see the contents for DIR, which is the intended
program behavior. Finally, the programmer is also careful to limit the
code that executes with raised privileges.
However, because the program does not modify the PATH environment
variable, the following attack would work:
The user sets the PATH to reference a directory under that user's
control, such as "/my/dir/".
The user creates a malicious program called "ls", and puts that
program in /my/dir
The user executes the program.
When system() is executed, the shell consults the PATH to find the
ls program
The program finds the malicious program, "/my/dir/ls". It doesn't
find "/bin/ls" because PATH does not contain "/bin/".
The program executes the malicious program with the raised
privileges.
Server allows client to specify the search path,
which can be modified to point to a program that the client has
uploaded.
Potential Mitigations
Phase
Description
Architecture and Design
Hard-code your search path to a set of known-safe values, or allow
them to be specified by the administrator in a configuration file. Do
not allow these settings to be modified by an external party. Be careful
to avoid related weaknesses such as CWE-427 and CWE-428.
Implementation
When invoking other programs, specify those programs using
fully-qualified pathnames.
Implementation
Sanitize your environment before invoking other programs. This
includes the PATH environment variable, LD_LIBRARY_PATH and other
settings that identify the location of code libraries, and any
application-specific search paths.
Implementation
Check your search path before use and remove any elements that are
likely to be unsafe, such as the current working directory or a
temporary files directory.
Implementation
Use other functions that require explicit paths. Making use of any of
the other readily available functions that require explicit paths is a
safe way to avoid this problem. For example, system() in C does not
require a full path since the shell can take care of it, while execl()
and execv() require a full path.
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.
Testing
Use tools and techniques that require manual (human) analysis, such as
penetration testing, threat modeling, and interactive tools that allow
the tester to record and modify an active session. These may be more
effective than strictly automated techniques. This is especially the
case with weaknesses that are related to design and business
rules.
Testing
Use monitoring tools that examine the software's process as it
interacts with the operating system and the network. This technique is
useful in cases when source code is unavailable, if the software was not
developed by you, or if you want to verify that the build phase did not
introduce any new weaknesses. Examples include debuggers that directly
attach to the running process; system-call tracing utilities such as
truss (Solaris) and strace (Linux); system activity monitors such as
FileMon, RegMon, Process Monitor, and other Sysinternals utilities
(Windows); and sniffers and protocol analyzers that monitor network
traffic.
Attach the monitor to the process and look for library functions and
system calls that suggest when a search path is being used. One pattern
is when the program performs multiple accesses of the same file but in
different directories, with repeated failures until the proper filename
is found. Library calls such as getenv() or their equivalent can be
checked to see if any path-related variables are being accessed.
Description
