CWE WEAKNESSES  /  CWE-829

CWE-829

Inclusion of Functionality from Untrusted Control Sphere

What it is

The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

Impact

Mitigations

• [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
• [Architecture and Design]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.For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.
• [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.
• [Architecture and Design, Operation]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. Fo
• [Architecture and Design, Operation] 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 ad
• [Implementation]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 r
• [Architecture and Design, Operation]Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the co
• [Architecture and Design, Implementation]Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly thro

Real-world CVE examples

• CVE-2010-2076 — Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause
• CVE-2004-0285 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2004-0030 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2004-0068 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2005-2157 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2005-2162 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2005-2198 — Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
• CVE-2004-0128 — Modification of assumed-immutable variable in configuration script leads to file inclusion.
• CVE-2005-1864 — PHP file inclusion.
• CVE-2005-1869 — PHP file inclusion.
• CVE-2005-1870 — PHP file inclusion.
• CVE-2005-2154 — PHP local file inclusion.

Related weaknesses

Source: MITRE CWE. View on cwe.mitre.org →