External Influence of Sphere Definition

Description

The application allows external parties to modify its security boundaries or trusted zones, which should be defined and controlled internally.

Extended Description

A secure application defines its trusted operational zones—often called control spheres—within its own code or through secure administrator configuration. These zones determine what resources, data, and functions are considered internal and protected. The vulnerability occurs when an outside actor, such as an attacker or an unprivileged user, can alter these boundaries, effectively redrawing the security map of the application. This weakness is often a consequence of other flaws, like insecure configuration storage, missing access controls on critical settings, or excessive trust in user-supplied data that defines system behavior. When external influence is possible, attackers can shrink or expand these trust zones to bypass security checks, access restricted data, or escalate privileges, fundamentally undermining the application's intended security model.

Common Consequences 1

Scope: Other

Impact: Other

Demonstrative Examples 2

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.

In Untrusted Search Path (Untrusted Search Path), 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.

Observed Examples 1

CVE-2008-2613setuid program allows compromise using path that finds and loads a malicious library.

Modes of Introduction

Architecture and Design

Implementation

Related Weaknesses

ChildOf:

Improper Control of a Resource Through its Lifetime (CWE-664)

Notes

TheoreticalA "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.