CWE-684, Incorrect Provision of Specified Functionality, is about code that does not do what its published specification says. Anyone calling it relies on the documented behavior. If the real behavior differs, the caller may end up in an exploitable state without doing anything wrong.
MITRE's extended description adds a second angle: when requirements or nuances are not documented at all, the functionality may produce unintended behavior for the caller. So the gap can be a bug or a missing sentence in the docs.
How it happens
The observed examples show how different this can look:
- CVE-2002-1446: an error checking routine in a PKCS#11 library returns an "OK" status even when an invalid signature is detected, allowing spoofed messages.
- CVE-2001-1559: a chain where a system call returns the wrong value, leading to a NULL dereference.
- CVE-2003-0187: a program uses large timeouts on unconfirmed connections, resulting from an inconsistency in linked list implementations.
- CVE-1999-1446: a UI inconsistency where the visited URLs list is not cleared when the "Clear History" option is selected.
The first is the sharpest. A verification function whose contract is "tell me if the signature is valid" returned success on failure. Every caller that trusted it was wrong.
What an attacker gains
MITRE's consequence entry is quality degradation. The security meaning comes from what the function protects. A verifier that approves everything lets spoofed messages through, and a "clear history" button that does not clear gives away what the user tried to remove.
How to find it
MITRE lists no detection methods for this weakness, which makes sense: tools cannot know the specification. What works is testing against the spec. Write tests from the documentation, not from the code, and include the failing and hostile cases. For security functions, test that bad input is rejected as loudly as good input is accepted.
How to fix it
MITRE's mitigation is one line: ensure your code strictly conforms to specifications. Make that real by keeping the specification and the code close, writing down the awkward nuances, and treating a mismatch between documentation and behavior as a defect in one or the other.
Quick check
What went wrong in the PKCS#11 example?
The error checking routine reported OK even when it detected an invalid signature, so callers accepted spoofed messages.
