CWE-708 describes a simple mistake with serious reach: the product assigns an owner to a resource, but the owner sits outside the intended control sphere. Whoever holds that ownership can usually change the resource, its permissions, or both.
It shows up wherever software creates files, directories, services or sockets on behalf of someone else. Installers, package managers, file systems and session managers are the usual suspects.
How it happens
Ownership goes wrong in a few ordinary ways. An installer runs as root but leaves binaries owned by an unprivileged account. A file system sets the wrong user or group when it creates a file. A resource manager hands out a reusable object and then fails to reset its owner when the user logs out.
The MITRE record lists real examples. CVE-2024-43199 covers a product that installs binaries with potentially insecure user and group ownership. CVE-2007-4238 describes an operating system that installed a program with a bin owner and group, allowing modification. CVE-2007-1716 describes a manager that did not restore ownership of a reusable resource at logout, which allowed privilege escalation.
What an attacker gains
The recorded consequences are confidentiality and integrity. An attacker can read and modify application data they could not touch directly. If the resource is an executable that a privileged process later runs, modifying it becomes a path to privilege escalation.
How to find it
MITRE suggests automated tools that check privilege settings. In practice that means walking the install tree after a build and listing every file and directory with its owner, group and mode. Anything owned by a user other than root or the service account deserves a question.
Also test the lifecycle. Create a resource as one user, release it, and check who owns it when the next user receives it.
How to fix it
- Decide which account should own each resource and write it down.
- Set ownership explicitly at creation or install time instead of inheriting it from whoever ran the process.
- Reset ownership whenever a reusable resource is returned to a pool.
- Review privileges and their owners on a schedule. MITRE lists this periodic review as its mitigation.
Quick check
Why is a root-installed binary owned by a regular user dangerous?
That user can replace the binary. The next time a privileged process runs it, the attacker's code runs with those privileges.
Does fixing ownership at install time cover reusable resources?
No. Pooled or reusable resources need their ownership reset every time they change hands, not only once at setup.
