CWE-467 Variant Draft High likelihood

Use of sizeof() on a Pointer Type

This vulnerability occurs when a developer uses the sizeof() operator on a pointer variable instead of the data it points to, leading to incorrect size calculations and potential buffer overflows or…

Definition

What is CWE-467?

Using sizeof() on a pointer returns the size of the pointer itself (e.g., 4 or 8 bytes for the memory address), not the size of the allocated object or data structure it references. This is a common mistake when programmers intend to calculate buffer sizes, perform memory operations like memcpy, or allocate dynamic memory, resulting in calculations that are off by a factor of the pointer size. While sizeof(pointer) can be intentionally used for platform-specific code (like determining system word size), its presence usually indicates a logic bug. To avoid this, always ensure sizeof() is applied to the dereferenced pointer type (e.g., sizeof(*pointer)) or the actual data type name, especially when dealing with arrays, structs, or dynamically allocated memory blocks.

Auswirkungen in der Praxis

Real-world CVEs caused by CWE-467

Bisher sind in MITREs Katalog keine öffentlichen CVE-Referenzen mit dieser CWE verknüpft.

Wie Angreifer es ausnutzen

Angreiferpfad Schritt für Schritt

1
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.
2
In this example, sizeof(foo) returns the size of the pointer.
3
In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.
4
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.
5
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).

Verwundbares Codebeispiel

Vulnerable C

In this example, sizeof(foo) returns the size of the pointer.

Verwundbar C

double *foo;
  ...
  foo = (double *)malloc(sizeof(foo));

Angreifer-Payload

Because of the partial comparison, any of these passwords would still cause authentication to succeed for the "admin" user:

Angreifer-Payload

pass5
  passABCDEFGH
  passWORD

Sicheres Codebeispiel

Secure C

In this example, sizeof(*foo) returns the size of the data structure and not the size of the pointer.

Sicher C

double *foo;
  ...
  foo = (double *)malloc(sizeof(*foo));

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Präventions-Checkliste

How to prevent CWE-467

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.

Erkennungssignale

How to detect CWE-467

Automated Static Analysis High

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.)

Plexicus Auto-Fix

Plexicus erkennt CWE-467 automatisch und öffnet in unter 60 Sekunden einen Fix-PR.

Codex Remedium scannt jeden Commit, identifiziert genau diese Schwachstelle und liefert einen reviewer-ready Pull Request mit dem Patch. Keine Tickets. Keine Hand-offs.

Demo anfordern Plexicus kostenlos testen

Häufig gestellte Fragen

Frequently asked questions

Was ist CWE-467?

Wie gravierend ist CWE-467?

MITRE stuft die Exploit-Wahrscheinlichkeit als hoch ein — diese Schwachstelle wird aktiv in freier Wildbahn ausgenutzt und sollte priorisiert behoben werden.

Welche Sprachen oder Plattformen sind von CWE-467 betroffen?

MITRE lists the following affected platforms: C, C++.

Wie kann ich CWE-467 verhindern?

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.

Wie erkennt und behebt Plexicus CWE-467?

Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-467 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.

Wo erfahre ich mehr über CWE-467?

MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/467.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.

Verwandte Schwachstellen

Weaknesses related to CWE-467

CWE-131 Parent

Incorrect Calculation of Buffer Size

This vulnerability occurs when a program miscalculates the amount of memory needed for a buffer, potentially leading to a buffer overflow…

Ressourcen

Schluss mit dem Bezahlen pro Entwickler.
Schließ den Kreislauf.

Plexicus ist die KI-native ASPM, die scannt, filtert, fixt, pentestet und erklärt — autonom. Unbegrenzte Entwickler, unbegrenzte Repos, Fair-Use-KI-Aktionen. Echter kostenloser Tarif, €269/mo jährlich, wenn du bereit bist.

Kostenlos starten Demo buchen