The product does not prevent the definition of control spheres from external actors.
Extended Description
Typically, a product defines its control sphere within the code itself, or through configuration by the product's administrator. In some cases, an external party can change the definition of the control sphere. This is typically a resultant weakness.
Time of Introduction
Architecture and Design
Implementation
Common Consequences
Scope
Effect
Other
Technical Impact: Other
Demonstrative Examples
Example 1
Consider a blog publishing tool, which might have three explicit
control spheres: the creation of articles, only accessible to a "publisher;"
commenting on articles, only accessible to a "commenter" who is a registered
user; and reading articles, only accessible to an anonymous reader. Suppose
that the application is deployed on a web server that is shared with
untrusted parties. If a local user can modify the data files that define who
a publisher is, then this user has modified the control sphere. In this
case, the issue would be resultant from another weakness such as
insufficient permissions.
Example 2
In Untrusted Search Path (CWE-426), a user might be able to define the PATH environment variable to cause the product to search in the wrong directory for a library to load. The product's intended sphere of control would include "resources that are only modifiable by the person who installed the product." The PATH effectively changes the definition of this sphere so that it overlaps the attacker's sphere of control.
A "control sphere" is a set of resources and behaviors that are accessible
to a single actor, or a group of actors. A product's security model will
typically define multiple spheres, possibly implicitly. For example, a
server might define one sphere for "administrators" who can create new user
accounts with subdirectories under /home/server/, and a second sphere might
cover the set of users who can create or delete files within their own
subdirectories. A third sphere might be "users who are authenticated to the
operating system on which the product is installed." Each sphere has
different sets of actors and allowable behaviors.
Relevant Properties
Mutability
Content History
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Time_of_Introduction
2008-09-08
CWE Content Team
MITRE
Internal
updated Description, Relationships,
Other_Notes
2009-10-29
CWE Content Team
MITRE
Internal
updated Other_Notes,
Theoretical_Notes
2011-06-01
CWE Content Team
MITRE
Internal
updated Common_Consequences
2012-05-11
CWE Content Team
MITRE
Internal
updated Relationships
2013-02-21
CWE Content Team
MITRE
Internal
updated Relationships
2014-07-30
CWE Content Team
MITRE
Internal
updated Relationships
More information is available — Please select a different filter.
Page Last Updated:
May 05, 2017
Use of the Common Weakness Enumeration and the associated references from this website are subject to the
Terms of Use. For more information, please email
cwe@mitre.org.
Description
