CWE-673 is a product that does not prevent external actors from defining its control spheres. Normally a program defines its sphere in code or through administrator configuration. Here, an outside party can change that definition. MITRE says this is typically a resultant weakness, meaning it shows up as a consequence of another flaw.
How it happens
The record's example is CVE-2008-2613: a setuid program that allows compromise using a path that finds and loads a malicious library. The program trusts a search path that the attacker can influence, so the set of libraries it treats as its own now includes the attacker's.
Other forms are search paths set from environment variables, plugin folders writable by others, and configuration files readable and editable by unprivileged users.
What an attacker gains
The record lists the impact as "Other". In the example, loading a malicious library in a privileged program amounts to running attacker code with that program's rights.
How to find it
The record lists no detection methods. Review how your program decides where to load code, plugins and configuration from. Check environment variables, relative paths and writable directories that appear in search paths.
How to fix it
MITRE lists no formal mitigations on this entry. Practical steps:
- Load code and configuration from fixed, absolute, protected locations.
- Ignore or sanitize environment variables that change search behavior in privileged programs.
- Make sure directories in any search path are writable only by trusted accounts.
- Treat any setting an outsider can edit as input to be validated.
Quick check
Why call this a resultant weakness?
It typically follows from another flaw that lets an outsider edit paths or settings, rather than appearing alone.
