cwe.mitre.org Open in urlscan Pro
198.49.146.233 Public Scan

Back to summary

URL:
https://cwe.mitre.org/data/definitions/78.html
Submission: On June 27 via api (June 27th 2022, 6:47:05 am UTC) from NL — Scanned from NL

Form analysis
1 forms found in the DOM

/cgi-bin/jumpmenu.cgi

<form action="/cgi-bin/jumpmenu.cgi" align="right" style="padding:0px; margin:0px"> ID <label for="id" style="padding-right:5px">Lookup:</label>
  <input id="id" name="id" type="text" style="width:50px; font-size:80%" maxlength="10">
  <input value="Go" style="padding: 0px; font-size:80%" type="submit">
</form>

Text Content

COMMON WEAKNESS ENUMERATION

A Community-Developed List of Software & Hardware Weakness Types

Home > CWE List > CWE- Individual Dictionary Definition (4.7)
ID Lookup:

--------------------------------------------------------------------------------

* Home
* About
Overview Board Board Meeting Minutes History Documents FAQs Glossary
* CWE List
Latest Version Downloads Reports Visualizations Archive
* Scoring
Methodologies Prioritizing Weaknesses CWSS CWRAF Top 25 Top Hardware
* Mapping Guidance
CVE → CWE Mapping Guidance CVE → CWE Mapping Quick Tips CVE → CWE Mapping
Examples Common Terms Cheatsheet
* Community
Community Members Working Groups & Special Interest Groups Compatibility
Discussion List Discussion Archives Content Suggestions
* News
Current News Twitter LinkedIn YouTube Podcast Medium News Archive
* Search

CWE Glossary Definition

CWE-78: IMPROPER NEUTRALIZATION OF SPECIAL ELEMENTS USED IN AN OS COMMAND ('OS
COMMAND INJECTION')

Weakness ID: 78
Abstraction: Base
Structure: Simple

Presentation Filter:
Basic Complete High Level Mapping-Friendly
Description
The software constructs all or part of an OS command using externally-influenced
input from an upstream component, but it does not neutralize or incorrectly
neutralizes 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 does not
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

Relationships
This table shows the weaknesses and high level categories that are related to
this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf
and give insight to similar items that may exist at higher and lower levels of
abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined
to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)

NatureTypeIDNameChildOfClass - a weakness that is described in a very abstract
fashion, typically independent of any specific language or technology. More
specific than a Pillar Weakness, but more general than a Base Weakness. Class
level weaknesses typically describe issues in terms of 1 or 2 of the following
dimensions: behavior, property, and resource.77Improper Neutralization of
Special Elements used in a Command ('Command Injection')CanAlsoBeBase - a
weakness that is still mostly independent of a resource or technology, but with
sufficient details to provide specific methods for detection and prevention.
Base level weaknesses typically describe issues in terms of 2 or 3 of the
following dimensions: behavior, property, technology, language, and
resource.88Improper Neutralization of Argument Delimiters in a Command
('Argument Injection')CanFollowBase - a weakness that is still mostly
independent of a resource or technology, but with sufficient details to provide
specific methods for detection and prevention. Base level weaknesses typically
describe issues in terms of 2 or 3 of the following dimensions: behavior,
property, technology, language, and resource.184Incomplete List of Disallowed
Inputs

This table shows the weaknesses and high level categories that are related to
this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf
and give insight to similar items that may exist at higher and lower levels of
abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined
to show similar weaknesses that the user may want to explore.
Relevant to the view "Software Development" (CWE-699)

NatureTypeIDNameMemberOfCategory - a CWE entry that contains a set of other
entries that share a common characteristic.137Data Neutralization Issues

NatureTypeIDNameMemberOfCategory - a CWE entry that contains a set of other
entries that share a common characteristic.1019Validate Inputs

Modes Of Introduction
The different Modes of Introduction provide information about how and when this
weakness may be introduced. The Phase identifies a point in the life cycle at
which introduction may occur, while the Note provides a typical scenario related
to introduction during the given phase.

PhaseNoteArchitecture and DesignImplementationREALIZATION: This weakness is
caused during implementation of an architectural security tactic.

Applicable Platforms
This listing shows possible areas for which the given weakness could appear.
These may be for specific named Languages, Operating Systems, Architectures,
Paradigms, Technologies, or a class of such platforms. The platform is listed
along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Common Consequences
This table specifies different individual consequences associated with the
weakness. The Scope identifies the application security area that is violated,
while the Impact describes the negative technical impact that arises if an
adversary succeeds in exploiting this weakness. The Likelihood provides
information about how likely the specific consequence is expected to be seen
relative to the other consequences in the list. For example, there may be high
likelihood that a weakness will be exploited to achieve a certain impact, but a
low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihoodConfidentiality
Integrity
Availability
Non-Repudiation

Technical Impact: Execute Unauthorized Code or Commands; DoS: Crash, Exit, or
Restart; Read Files or Directories; Modify Files or Directories; Read
Application Data; Modify Application Data; Hide Activities

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.

Likelihood Of Exploit
High
Demonstrative Examples

Example 1

This example code intends to take the name of a user and list the contents of
that user's home directory. It is subject to the first variant of OS command
injection.

(bad code)
Example Language: PHP
$userName = $_POST["user"];
$command = 'ls -l /home/' . $userName;
system($command);

The $userName variable is not checked for malicious input. An attacker could set
the $userName variable to an arbitrary OS command such as:

(attack code)
;rm -rf /

Which would result in $command being:

(result)
ls -l /home/;rm -rf /

Since the semi-colon is a command separator in Unix, the OS would first execute
the ls command, then the rm command, deleting the entire file system.

Also note that this example code is vulnerable to Path Traversal (CWE-22) and
Untrusted Search Path (CWE-426) attacks.

Example 2

The following simple program accepts a filename as a command line argument and
displays the contents of the file back to the user. The program is installed
setuid root because it is intended for use as a learning tool to allow system
administrators in-training to inspect privileged system files without giving
them the ability to modify them or damage the system.

(bad code)
Example Language: C
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}

Because the program runs with root privileges, the call to system() also
executes with root privileges. If a user specifies a standard filename, the call
works as expected. However, if an attacker passes a string of the form ";rm -rf
/", then the call to system() fails to execute cat due to a lack of arguments
and then plows on to recursively delete the contents of the root partition.

Note that if argv[1] is a very long argument, then this issue might also be
subject to a buffer overflow (CWE-120).

Example 3

This example is a web application that intends to perform a DNS lookup of a
user-supplied domain name. It is subject to the first variant of OS command
injection.

(bad code)
Example Language: Perl
use CGI qw(:standard);
$name = param('name');
$nslookup = "/path/to/nslookup";
print header;
if (open($fh, "$nslookup $name|")) {
while (<$fh>) {
print escapeHTML($_);
print "<br>\n";
}
close($fh);
}

Suppose an attacker provides a domain name like this:

(attack code)
cwe.mitre.org%20%3B%20/bin/ls%20-l

The "%3B" sequence decodes to the ";" character, and the %20 decodes to a space.
The open() statement would then process a string like this:

(result)
/path/to/nslookup cwe.mitre.org ; /bin/ls -l

As a result, the attacker executes the "/bin/ls -l" command and gets a list of
all the files in the program's working directory. The input could be replaced
with much more dangerous commands, such as installing a malicious program on the
server.

Example 4

The example below reads the name of a shell script to execute from the system
properties. It is subject to the second variant of OS command injection.

(bad code)
Example Language: Java
String script = System.getProperty("SCRIPTNAME");
if (script != null)
System.exec(script);

If an attacker has control over this property, then they could modify the
property to point to a dangerous program.

Example 5

In the example below, a method is used to transform geographic coordinates from
latitude and longitude format to UTM format. The method gets the input
coordinates from a user through a HTTP request and executes a program local to
the application server that performs the transformation. The method passes the
latitude and longitude coordinates as a command-line option to the external
program and will perform some processing to retrieve the results of the
transformation and return the resulting UTM coordinates.

(bad code)
Example Language: Java
public String coordinateTransformLatLonToUTM(String coordinates)
{
String utmCoords = null;
try {
String latlonCoords = coordinates;
Runtime rt = Runtime.getRuntime();
Process exec = rt.exec("cmd.exe /C latlon2utm.exe -" + latlonCoords);
// process results of coordinate transform

// ...

}
catch(Exception e) {...}
return utmCoords;
}

However, the method does not verify that the contents of the coordinates input
parameter includes only correctly-formatted latitude and longitude coordinates.
If the input coordinates were not validated prior to the call to this method, a
malicious user could execute another program local to the application server by
appending '&' followed by the command for another program to the end of the
coordinate string. The '&' instructs the Windows operating system to execute
another program.

Example 6

The following code is from an administrative web application designed to allow
users to kick off a backup of an Oracle database using a batch-file wrapper
around the rman utility and then run a cleanup.bat script to delete some
temporary files. The script rmanDB.bat accepts a single command line parameter,
which specifies what type of backup to perform. Because access to the database
is restricted, the application runs the backup as a privileged user.

(bad code)
Example Language: Java
...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K \"
c:\\util\\rmanDB.bat "
+btype+
"&&c:\\utl\\cleanup.bat\"")

System.Runtime.getRuntime().exec(cmd);
...

The problem here is that the program does not do any validation on the
backuptype parameter read from the user. Typically the Runtime.exec() function
will not execute multiple commands, but in this case the program first runs the
cmd.exe shell in order to run multiple commands with a single call to
Runtime.exec(). Once the shell is invoked, it will happily execute multiple
commands separated by two ampersands. If an attacker passes a string of the form
"& del c:\\dbms\\*.*", then the application will execute this command along with
the others specified by the program. Because of the nature of the application,
it runs with the privileges necessary to interact with the database, which means
whatever command the attacker injects will run with those privileges as well.

Observed Examples

ReferenceDescription
CVE-1999-0067
Canonical example of OS command injection. CGI program does not neutralize "|"
metacharacter when invoking a phonebook program.
CVE-2001-1246
Language interpreter's mail function accepts another argument that is
concatenated to a string used in a dangerous popen() call. Since there is no
neutralization of this argument, both OS Command Injection (CWE-78) and Argument
Injection (CWE-88) are possible.
CVE-2002-0061
Web server allows command execution using "|" (pipe) character.
CVE-2003-0041
FTP client does not filter "|" from filenames returned by the server, allowing
for OS command injection.
CVE-2008-2575
Shell metacharacters in a filename in a ZIP archive
CVE-2002-1898
Shell metacharacters in a telnet:// link are not properly handled when the
launching application processes the link.
CVE-2008-4304
OS command injection through environment variable.
CVE-2008-4796
OS command injection through https:// URLs
CVE-2007-3572
Chain: incomplete denylist for OS command injection
CVE-2012-1988
Product allows remote users to execute arbitrary commands by creating a file
whose pathname contains shell metacharacters.

Potential Mitigations

Phase: Architecture and Design

If at all possible, use library calls rather than external processes to recreate
the desired functionality.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict
boundaries between the process and the operating system. This may effectively
restrict which files can be accessed in a particular directory or which commands
can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In
general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows the software to
specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the
operating system; the rest of the application may still be subject to
compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention
capabilities of the specific sandbox or jail being used and might only help to
reduce the scope of an attack, such as restricting the attacker to certain
system calls or limiting the portion of the file system that can be accessed.

Phase: Architecture and Design

Strategy: Attack Surface Reduction

For any data that will be used to generate a command to be executed, keep as
much of that data out of external control as possible. For example, in web
applications, this may require storing the data locally in the session's state
instead of sending it out to the client in a hidden form field.

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these
checks are duplicated on the server side, in order to avoid CWE-602. Attackers
can bypass the client-side checks by modifying values after the checks have been
performed, or by changing the client to remove the client-side checks entirely.
Then, these modified values would be submitted to the server.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or
provides constructs that make this weakness easier to avoid.

For example, consider using the ESAPI Encoding control [REF-45] or a similar
tool, library, or framework. These will help the programmer encode outputs in a
manner less prone to error.

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands
that mix control and data together, sometimes it may be unavoidable. Properly
quote arguments and escape any special characters within those arguments. The
most conservative approach is to escape or filter all characters that do not
pass an extremely strict allowlist (such as everything that is not alphanumeric
or white space). If some special characters are still needed, such as white
space, wrap each argument in quotes after the escaping/filtering step. Be
careful of argument injection (CWE-88).

Phase: Implementation

If the program to be executed allows arguments to be specified within an input
file or from standard input, then consider using that mode to pass arguments
instead of the command line.

Phase: Architecture and Design

Strategy: Parameterization

If available, use structured mechanisms that automatically enforce the
separation between data and code. These mechanisms may be able to provide the
relevant quoting, encoding, and validation automatically, instead of relying on
the developer to provide this capability at every point where output is
generated.

Some languages offer multiple functions that can be used to invoke commands.
Where possible, identify any function that invokes a command shell using a
single string, and replace it with a function that requires individual
arguments. These functions typically perform appropriate quoting and filtering
of arguments. For example, in C, the system() function accepts a string that
contains the entire command to be executed, whereas execl(), execve(), and
others require an array of strings, one for each argument. In Windows,
CreateProcess() only accepts one command at a time. In Perl, if system() is
provided with an array of arguments, then it will quote each of the arguments.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation
strategy, i.e., use a list of acceptable inputs that strictly conform to
specifications. Reject any input that does not strictly conform to
specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties,
including length, type of input, the full range of acceptable values, missing or
extra inputs, syntax, consistency across related fields, and conformance to
business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is
not valid if the input is only expected to contain colors such as "red" or
"blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is
likely to miss at least one undesirable input, especially if the code's
environment changes. This can give attackers enough room to bypass the intended
validation. However, denylists can be useful for detecting potential attacks or
determining which inputs are so malformed that they should be rejected outright.

When constructing OS command strings, use stringent allowlists that limit the
character set based on the expected value of the parameter in the request. This
will indirectly limit the scope of an attack, but this technique is less
important than proper output encoding and escaping.

Note that proper output encoding, escaping, and quoting is the most effective
solution for preventing OS command injection, although input validation may
provide some defense-in-depth. This is because it effectively limits what will
appear in output. Input validation will not always prevent OS command injection,
especially if you are required to support free-form text fields that could
contain arbitrary characters. For example, when invoking a mail program, you
might need to allow the subject field to contain otherwise-dangerous inputs like
";" and ">" characters, which would need to be escaped or otherwise handled. In
this case, stripping the character might reduce the risk of OS command
injection, but it would produce incorrect behavior because the subject field
would not be recorded as the user intended. This might seem to be a minor
inconvenience, but it could be more important when the program relies on
well-structured subject lines in order to pass messages to other components.

Even if you make a mistake in your validation (such as forgetting one out of 100
input fields), appropriate encoding is still likely to protect you from
injection-based attacks. As long as it is not done in isolation, input
validation is still a useful technique, since it may significantly reduce your
attack surface, allow you to detect some attacks, and provide other security
benefits that proper encoding does not address.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or
known, create a mapping from a set of fixed input values (such as numeric IDs)
to the actual filenames or URLs, and reject all other inputs.

Phase: Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and
prevents any command execution that uses tainted variables, such as Perl's "-T"
switch. This will force the program to perform validation steps that remove the
taint, although you must be careful to correctly validate your inputs so that
you do not accidentally mark dangerous inputs as untainted (see CWE-183 and
CWE-184).

Phase: Operation

Strategy: Environment Hardening

Phase: Implementation

Ensure that error messages only contain minimal details that are useful to the
intended audience and no one else. The messages need to strike the balance
between being too cryptic (which can confuse users) or being too detailed (which
may reveal more than intended). The messages should not reveal the methods that
were used to determine the error. Attackers can use detailed information to
refine or optimize their original attack, thereby increasing their chances of
success.

If errors must be captured in some detail, record them in log messages, but
consider what could occur if the log messages can be viewed by attackers. Highly
sensitive information such as passwords should never be saved to log files.

Avoid inconsistent messaging that might accidentally tip off an attacker about
internal state, such as whether a user account exists or not.

In the context of OS Command Injection, error information passed back to the
user might reveal whether an OS command is being executed and possibly which
command is being used.

Phase: Operation

Strategy: Sandbox or Jail

Use runtime policy enforcement to create an allowlist of allowable commands,
then prevent use of any command that does not appear in the allowlist.
Technologies such as AppArmor are available to do this.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It
can be beneficial in cases in which the code cannot be fixed (because it is
controlled by a third party), as an emergency prevention measure while more
comprehensive software assurance measures are applied, or to provide defense in
depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In
addition, attack techniques might be available to bypass the protection
mechanism, such as using malformed inputs that can still be processed by the
component that receives those inputs. Depending on functionality, an application
firewall might inadvertently reject or modify legitimate requests. Finally, some
manual effort may be required for customization.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the
necessary tasks [REF-76]. If possible, create isolated accounts with limited
privileges that are only used for a single task. That way, a successful attack
will not immediately give the attacker access to the rest of the software or its
environment. For example, database applications rarely need to run as the
database administrator, especially in day-to-day operations.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use
register_globals. During implementation, develop the application so that it does
not rely on this feature, but be wary of implementing a register_globals
emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar
issues.

Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many
modern tools use data flow analysis or constraint-based techniques to minimize
the number of false positives.

Automated static analysis might not be able to recognize when proper input
validation is being performed, leading to false positives - i.e., warnings that
do not have any security consequences or require any code changes.

Automated static analysis might not be able to detect the usage of custom API
functions or third-party libraries that indirectly invoke OS commands, leading
to false negatives - especially if the API/library code is not available for
analysis.

Note: This is not a perfect solution, since 100% accuracy and coverage are not
feasible.

Automated Dynamic Analysis

This weakness can be detected using 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.

Effectiveness: Moderate

Manual Static Analysis

Since this weakness does not typically appear frequently within a single
software package, manual white box techniques may be able to provide sufficient
code coverage and reduction of false positives if all potentially-vulnerable
operations can be assessed within limited time constraints.

Effectiveness: High

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

* Bytecode Weakness Analysis - including disassembler + source code weakness
analysis

* Binary Weakness Analysis - including disassembler + source code weakness
analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

* Web Application Scanner

* Web Services Scanner

* Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

* Fuzz Tester

* Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

* Manual Source Code Review (not inspections)

Cost effective for partial coverage:

* Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

* Source code Weakness Analyzer

* Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

* Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

* Inspection (IEEE 1028 standard) (can apply to requirements, design, source
code, etc.)

Effectiveness: High

Functional Areas
* Program Invocation

Affected Resources
* System Process

Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in
understanding where a weakness fits within the context of external information
sources.

NatureTypeIDNameMemberOfView - a subset of CWE entries that provides a way of
examining CWE content. The two main view structures are Slices (flat lists) and
Graphs (containing relationships between entries).635Weaknesses Originally Used
by NVD from 2008 to 2016MemberOfCategory - a CWE entry that contains a set of
other entries that share a common characteristic.714OWASP Top Ten 2007 Category
A3 - Malicious File ExecutionMemberOfCategory - a CWE entry that contains a set
of other entries that share a common characteristic.727OWASP Top Ten 2004
Category A6 - Injection FlawsMemberOfCategory - a CWE entry that contains a set
of other entries that share a common characteristic.741CERT C Secure Coding
Standard (2008) Chapter 8 - Characters and Strings (STR)MemberOfCategory - a CWE
entry that contains a set of other entries that share a common
characteristic.744CERT C Secure Coding Standard (2008) Chapter 11 - Environment
(ENV)MemberOfCategory - a CWE entry that contains a set of other entries that
share a common characteristic.7512009 Top 25 - Insecure Interaction Between
ComponentsMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.8012010 Top 25 - Insecure Interaction Between
ComponentsMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.810OWASP Top Ten 2010 Category A1 -
InjectionMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.845The CERT Oracle Secure Coding Standard for
Java (2011) Chapter 2 - Input Validation and Data Sanitization
(IDS)MemberOfCategory - a CWE entry that contains a set of other entries that
share a common characteristic.8642011 Top 25 - Insecure Interaction Between
ComponentsMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.875CERT C++ Secure Coding Section 07 -
Characters and Strings (STR)MemberOfCategory - a CWE entry that contains a set
of other entries that share a common characteristic.878CERT C++ Secure Coding
Section 10 - Environment (ENV)MemberOfView - a subset of CWE entries that
provides a way of examining CWE content. The two main view structures are Slices
(flat lists) and Graphs (containing relationships between entries).884CWE
Cross-sectionMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.929OWASP Top Ten 2013 Category A1 -
InjectionMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.990SFP Secondary Cluster: Tainted Input to
CommandMemberOfCategory - a CWE entry that contains a set of other entries that
share a common characteristic.1027OWASP Top Ten 2017 Category A1 -
InjectionMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.1131CISQ Quality Measures (2016) -
SecurityMemberOfCategory - a CWE entry that contains a set of other entries that
share a common characteristic.1134SEI CERT Oracle Secure Coding Standard for
Java - Guidelines 00. Input Validation and Data Sanitization
(IDS)MemberOfCategory - a CWE entry that contains a set of other entries that
share a common characteristic.1165SEI CERT C Coding Standard - Guidelines 10.
Environment (ENV)MemberOfView - a subset of CWE entries that provides a way of
examining CWE content. The two main view structures are Slices (flat lists) and
Graphs (containing relationships between entries).1200Weaknesses in the 2019 CWE
Top 25 Most Dangerous Software ErrorsMemberOfView - a subset of CWE entries that
provides a way of examining CWE content. The two main view structures are Slices
(flat lists) and Graphs (containing relationships between
entries).1337Weaknesses in the 2021 CWE Top 25 Most Dangerous Software
WeaknessesMemberOfCategory - a CWE entry that contains a set of other entries
that share a common characteristic.1347OWASP Top Ten 2021 Category A03:2021 -
InjectionMemberOfView - a subset of CWE entries that provides a way of examining
CWE content. The two main view structures are Slices (flat lists) and Graphs
(containing relationships between entries).1350Weaknesses in the 2020 CWE Top 25
Most Dangerous Software Weaknesses

Notes

Research Gap

More investigation is needed into the distinction between the OS command
injection variants, including the role with argument injection (CWE-88).
Equivalent distinctions may exist in other injection-related problems such as
SQL injection.

Terminology

The "OS command injection" phrase carries different meanings to different
people. For some people, it only refers to cases in which the attacker injects
command separators into arguments for an application-controlled program that is
being invoked. For some people, it refers to any type of attack that can allow
the attacker to execute OS commands of their own choosing. This usage could
include untrusted search path weaknesses (CWE-426) that cause the application to
find and execute an attacker-controlled program. 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.
Taxonomy Mappings

Mapped Taxonomy NameNode IDFitMapped Node Name PLOVEROS Command Injection OWASP
Top Ten 2007A3CWE More SpecificMalicious File Execution OWASP Top Ten 2004A6CWE
More SpecificInjection Flaws CERT C Secure CodingENV03-CSanitize the environment
when invoking external programs CERT C Secure CodingENV33-CCWE More SpecificDo
not call system() CERT C Secure CodingSTR02-CSanitize data passed to complex
subsystems WASC31OS Commanding The CERT Oracle Secure Coding Standard for Java
(2011)IDS07-JDo not pass untrusted, unsanitized data to the Runtime.exec()
method Software Fault PatternsSFP24Tainted input to command OMG
ASCSMASCSM-CWE-78

Related Attack Patterns

CAPEC-IDAttack Pattern Name CAPEC-108Command Line Execution through SQL
Injection CAPEC-15Command Delimiters CAPEC-43Exploiting Multiple Input
Interpretation Layers CAPEC-6Argument Injection CAPEC-88OS Command Injection

References
[REF-140] Greg Hoglund and Gary McGraw. "Exploiting Software: How to Break
Code". Addison-Wesley. 2004-02-27.
<https://www.amazon.com/Exploiting-Software-How-Break-Code/dp/0201786958>.
[REF-685] Pascal Meunier. "Meta-Character Vulnerabilities". 2008-02-20.
<http://www.cs.purdue.edu/homes/cs390s/slides/week09.pdf>.
[REF-686] Robert Auger. "OS Commanding". 2009-06.
<http://projects.webappsec.org/OS-Commanding>.
[REF-687] Lincoln Stein and John Stewart. "The World Wide Web Security FAQ".
chapter: "CGI Scripts". 2002-02-04.
<http://www.w3.org/Security/Faq/wwwsf4.html>.
[REF-688] Jordan Dimov, Cigital. "Security Issues in Perl Scripts".
<http://www.cgisecurity.com/lib/sips.html>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of
Software Security". "Sin 10: Command Injection." Page 171. McGraw-Hill. 2010.
[REF-690] Frank Kim. "Top 25 Series - Rank 9 - OS Command Injection". SANS
Software Security Institute. 2010-02-24.
<http://blogs.sans.org/appsecstreetfighter/2010/02/24/top-25-series-rank-9-os-command-injection/>.
[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project".
<http://www.owasp.org/index.php/ESAPI>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14.
<https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software
Security Assessment". Chapter 8, "Shell Metacharacters", Page 425. 1st Edition.
Addison Wesley. 2006.
[REF-962] Object Management Group (OMG). "Automated Source Code Security Measure
(ASCSM)". ASCSM-CWE-78. 2016-01. <http://www.omg.org/spec/ASCSM/1.0/>.

Content History

SubmissionsSubmission DateSubmitterOrganization2006-07-19PLOVER
ModificationsModification DateModifierOrganization2008-07-01Sean
EidemillerCigitaladded/updated demonstrative examples2008-07-01Eric
DalciCigitalupdated Time_of_Introduction2008-08-01KDM Analyticsadded/updated
white box definitions2008-08-15VeracodeSuggested OWASP Top Ten 2004
mapping2008-09-08CWE Content TeamMITREupdated Relationships, Other_Notes,
Taxonomy_Mappings2008-10-14CWE Content TeamMITREupdated Description2008-11-24CWE
Content TeamMITREupdated Observed_Examples, Relationships,
Taxonomy_Mappings2009-01-12CWE Content TeamMITREupdated Common_Consequences,
Demonstrative_Examples, Description, Likelihood_of_Exploit, Name,
Observed_Examples, Other_Notes, Potential_Mitigations, Relationships,
Research_Gaps, Terminology_Notes2009-03-10CWE Content TeamMITREupdated
Potential_Mitigations2009-05-27CWE Content TeamMITREupdated Name,
Related_Attack_Patterns2009-07-17KDM AnalyticsImproved the
White_Box_Definition2009-07-27CWE Content TeamMITREupdated Description, Name,
White_Box_Definitions2009-10-29CWE Content TeamMITREupdated Observed_Examples,
References2009-12-28CWE Content TeamMITREupdated Detection_Factors2010-02-16CWE
Content TeamMITREupdated Detection_Factors, Potential_Mitigations, References,
Relationships, Taxonomy_Mappings2010-04-05CWE Content TeamMITREupdated
Potential_Mitigations2010-06-21CWE Content TeamMITREupdated Common_Consequences,
Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations,
References, Relationships2010-09-27CWE Content TeamMITREupdated
Potential_Mitigations2010-12-13CWE Content TeamMITREupdated Description,
Potential_Mitigations2011-03-29CWE Content TeamMITREupdated
Demonstrative_Examples, Description2011-06-01CWE Content TeamMITREupdated
Common_Consequences, Relationships, Taxonomy_Mappings2011-06-27CWE Content
TeamMITREupdated Relationships2011-09-13CWE Content TeamMITREupdated
Potential_Mitigations, References, Relationships, Taxonomy_Mappings2012-05-11CWE
Content TeamMITREupdated Demonstrative_Examples, References, Relationships,
Taxonomy_Mappings2012-10-30CWE Content TeamMITREupdated Observed_Examples,
Potential_Mitigations2014-02-18CWE Content TeamMITREupdated
Applicable_Platforms, Demonstrative_Examples, Terminology_Notes2014-06-23CWE
Content TeamMITREupdated Relationships2014-07-30CWE Content TeamMITREupdated
Detection_Factors, Relationships, Taxonomy_Mappings2015-12-07CWE Content
TeamMITREupdated Relationships2017-11-08CWE Content TeamMITREupdated
Modes_of_Introduction, References, Relationships, Taxonomy_Mappings,
White_Box_Definitions2018-03-27CWE Content TeamMITREupdated
Relationships2019-01-03CWE Content TeamMITREupdated References, Relationships,
Taxonomy_Mappings2019-06-20CWE Content TeamMITREupdated
Relationships2019-09-19CWE Content TeamMITREupdated Relationships2020-02-24CWE
Content TeamMITREupdated Potential_Mitigations, Relationships2020-06-25CWE
Content TeamMITREupdated Observed_Examples, Potential_Mitigations2020-08-20CWE
Content TeamMITREupdated Relationships2020-12-10CWE Content TeamMITREupdated
Potential_Mitigations, Relationships2021-07-20CWE Content TeamMITREupdated
Observed_Examples, Relationships2021-10-28CWE Content TeamMITREupdated
Relationships2022-04-28CWE Content TeamMITREupdated Demonstrative_Examples
Previous Entry NamesChange DatePrevious Entry Name2008-04-11OS Command
Injection2009-01-12Failure to Sanitize Data into an OS Command (aka 'OS Command
Injection')2009-05-27Failure to Preserve OS Command Structure (aka 'OS Command
Injection')2009-07-27Failure to Preserve OS Command Structure ('OS Command
Injection')2010-06-21Improper Sanitization of Special Elements used in an OS
Command ('OS Command Injection')

More information is available — Please select a different filter.

Page Last Updated: April 28, 2022

Site Map | Terms of Use | Privacy Policy | Contact Us |

Use of the Common Weakness Enumeration (CWE) and the associated references from
this website are subject to the Terms of Use. CWE is sponsored by the U.S.
Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security
Agency (CISA) and managed by the Homeland Security Systems Engineering and
Development Institute (HSSEDI) which is operated by The MITRE Corporation
(MITRE). Copyright © 2006–2022, The MITRE Corporation. CWE, CWSS, CWRAF, and the
CWE logo are trademarks of The MITRE Corporation.

cwe.mitre.org Open in urlscan Pro 198.49.146.233 Public Scan

Form analysis 1 forms found in the DOM

/cgi-bin/jumpmenu.cgi

Text Content

cwe.mitre.org Open in urlscan Pro
198.49.146.233 Public Scan

Form analysis
1 forms found in the DOM