CWE-648 covers code that calls a function needing extra privileges without meeting that function's requirements. The privileged API is not necessarily broken. The caller is. It matters most for setuid programs, system services, plugins that run with elevated rights, and any code that crosses a privilege boundary.
How it happens
A privileged API usually makes assumptions. It may expect arguments to be validated, expect to be called from a known state, or leave the process privileged when it returns. MITRE says the caller must do three things: make sure the API's assumptions hold, account for known weaknesses in the API's design or implementation, and call it from a safe context.
When a caller skips these, an attacker can feed bad input through the caller and have the privileged function act on it. Another common slip is forgetting that the privileged function does not shed its privilege on return. If the caller then hands control back to a user-controlled process, that process is now privileged.
The example CVE in the record is CVE-2003-0645: a Unix utility that displays online help files, if installed setuid, could let a local attacker gain privileges when a particular file-opening function was called.
A sketch of the pattern in C:
/* Vulnerable: runs privileged, opens a user-chosen file */
seteuid(0);
FILE *f = fopen(user_supplied_path, "r");
/* ...privilege never dropped before user-controlled work... */
What an attacker gains
MITRE lists three outcomes. Privilege escalation (gain privileges or assume identity), reading sensitive application data, and executing unauthorized code or commands, with impact on integrity, confidentiality and availability.
How to find it
The record lists no detection methods, so this is mostly review work. Audit every call to a privileged API and answer: who controls the arguments, what state is the process in, and what privilege does it hold after the call? Search for setuid binaries and services running as root, then trace user input to the privileged calls. If a dependency exposes a privileged API, check whether a known issue affects the version you use.
How to fix it
These are MITRE's mitigations in order.
- Before calling a privileged API, ensure the assumptions made by the privileged code hold true.
- Learn the architecture and implementation weaknesses of the privileged API and account for them before calling it.
- If the API assumes validity of data, context or state, validate those things in the caller first.
- If the API does not shed privilege before returning, shed it immediately and safely after the call. A privileged thread of execution must never be returned to the user or made available to user-controlled processes.
- Only call privileged APIs from a safe, consistent and expected state.
/* Safer: validate first, do the privileged step, drop at once */
if (!path_is_allowed(user_supplied_path)) return -1;
seteuid(0);
int fd = open_checked(user_supplied_path);
seteuid(getuid()); /* shed privilege before any user-influenced work */
When the privileged code lives in a library you depend on, the question changes to whether your code actually reaches the vulnerable call. Reachability analysis answers that, and the demo below walks through the idea.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Whose job is it to validate arguments to a privileged API?
The caller's. MITRE says that if the API makes assumptions about data, context or state, the calling code must validate them before the call.
Why drop privileges right after the call?
If the API does not shed its privilege, returning to user-influenced code leaves that code running privileged. Shedding immediately closes the window.
