CWE-467: Use of sizeof() on a Pointer Type | Glexia
CWE-467 (Use of sizeof() on a Pointer Type) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-467: Use of sizeof() on a Pointer Type
Use of sizeof() on a Pointer Type represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Integrity Confidentiality: Modify Memory Read Memory: This error can often cause one to allocate a buffer that is much smaller than what is needed, leading to resultant weaknesses such as buffer overflows.
Developer Pattern
CWE-467 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-467, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-467: Use of sizeof() on a Pointer Type
The code calls sizeof() on a pointer type, which can be an incorrect calculation if the programmer intended to determine the size of the data that is being pointed to.
The use of sizeof() on a pointer can sometimes generate useful information. An obvious case is to find out the wordsize on a platform. More often than not, the appearance of sizeof(pointer) indicates a bug.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- Care should be taken to ensure sizeof returns the size of the data structure itself, and not the size of the pointer to the data structure. In this example, sizeof(foo) returns the size of the pointer. In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.
- This example defines a fixed username and password. The AuthenticateUser() function is intended to accept a username and a password from an untrusted user, and check to ensure that it matches the username and password. If the username and password match, AuthenticateUser() is intended to indicate that authentication succeeded. In AuthenticateUser(), because sizeof() is applied to a parameter with an array type, the sizeof() call might return 4 on many modern architectures. As a result, the strncmp() call only checks the first four characters of the input password, resulting in a partial comparison (CWE-187), leading to improper authentication (CWE-287). Because of the partial comparison, any of these passwords would still cause authentication to succeed for the "admin" user: Because only 4 characters are checked, this significantly reduces the search space for an attacker, making brute force attacks more feasible. The same problem also applies to the username, so values such as "adminXYZ" and "administrator" will succeed for the username.
Remediation
- Implementation: Use expressions such as "sizeof(*pointer)" instead of "sizeof(pointer)", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack.
Detection
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
No related CWE relationships are published yet.
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.