Description
The product does not correctly convert an object, resource, or structure from one type to a different type.
Potential Impact
Other
Other
Demonstrative Examples
In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.
Bad
unsigned int readdata () {int amount = 0;...amount = accessmainframe();...return amount;}If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.
The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.
Bad
#define NAME_TYPE 1#define ID_TYPE 2
struct MessageBuffer{int msgType;union {char *name;int nameID;};};
int main (int argc, char **argv) {
struct MessageBuffer buf;char *defaultMessage = "Hello World";
buf.msgType = NAME_TYPE;buf.name = defaultMessage;printf("Pointer of buf.name is %p\n", buf.name);
/* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */
buf.nameID = (int)(defaultMessage + 1);printf("Pointer of buf.name is now %p\n", buf.name);if (buf.msgType == NAME_TYPE) {printf("Message: %s\n", buf.name);}else {printf("Message: Use ID %d\n", buf.nameID);}
}The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.
As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string.
Execution of the program might generate output such as:
Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified.
In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes.
Detection Methods
- Fuzzing High — Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption,
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2021-43537 | Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cau |
| CVE-2022-3979 | Chain: data visualization program written in PHP uses the "!=" operator instead of the type-strict "!==" operator (CWE-480) when validating hash values, potentially leading to an incorrect type conver |
Related Weaknesses
Taxonomy Mappings
- CERT C Secure Coding: EXP05-C — Do not cast away a const qualification
- CERT C Secure Coding: EXP39-C — Do not access a variable through a pointer of an incompatible type
- CERT C Secure Coding: INT31-C — Ensure that integer conversions do not result in lost or misinterpreted data
- CERT C Secure Coding: INT36-C — Converting a pointer to integer or integer to pointer
- CERT C Secure Coding: STR34-C — Cast characters to unsigned types before converting to larger integer sizes
- CERT C Secure Coding: STR37-C — Arguments to character handling functions must be representable as an unsigned char
- Software Fault Patterns: SFP1 — Glitch in computation
- OMG ASCRM: ASCRM-CWE-704 —
Frequently Asked Questions
What is CWE-704?
CWE-704 (Incorrect Type Conversion or Cast) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product does not correctly convert an object, resource, or structure from one type to a different type.
How can CWE-704 be exploited?
Attackers can exploit CWE-704 (Incorrect Type Conversion or Cast) to other. This weakness is typically introduced during the Implementation phase of software development.
How do I prevent CWE-704?
Follow secure coding practices, conduct code reviews, and use automated security testing tools (SAST/DAST) to detect this weakness early in the development lifecycle.
What is the severity of CWE-704?
CWE-704 is classified as a Class-level weakness (High abstraction). It has been observed in 2 real-world CVEs.