CWE-783: Operator Precedence Logic Error

Description

The product uses an expression in which operator precedence causes incorrect logic to be used.

While often just a bug, operator precedence logic errors can have serious consequences if they are used in security-critical code, such as making an authentication decision.

Potential Impact

Confidentiality, Integrity, Availability

Varies by Context, Unexpected State

Demonstrative Examples

In the following example, the method validateUser makes a call to another method to authenticate a username and password for a user and returns a success or failure code.

Bad

#define FAIL 0#define SUCCESS 1
                     ...
                     int validateUser(char *username, char *password) {
                        
                           int isUser = FAIL;
                           
                           // call method to authenticate username and password
                           
                           
                           // if authentication fails then return failure otherwise return success
                           if (isUser = AuthenticateUser(username, password) == FAIL) {return isUser;}else {isUser = SUCCESS;}
                           return isUser;
                     }

However, the method that authenticates the username and password is called within an if statement with incorrect operator precedence logic. Because the comparison operator "==" has a higher precedence than the assignment operator "=", the comparison operator will be evaluated first and if the method returns FAIL then the comparison will be true, the return variable will be set to true and SUCCESS will be returned. This operator precedence logic error can be easily resolved by properly using parentheses within the expression of the if statement, as shown below.

Good

...
                     if ((isUser = AuthenticateUser(username, password)) == FAIL) {
                     ...

In this example, the method calculates the return on investment for an accounting/financial application. The return on investment is calculated by subtracting the initial investment costs from the current value and then dividing by the initial investment costs.

Bad

public double calculateReturnOnInvestment(double currentValue, double initialInvestment) {
                        
                           double returnROI = 0.0;
                           
                           // calculate return on investment
                           returnROI = currentValue - initialInvestment / initialInvestment;
                           return returnROI;
                     }

However, the return on investment calculation will not produce correct results because of the incorrect operator precedence logic in the equation. The divide operator has a higher precedence than the minus operator, therefore the equation will divide the initial investment costs by the initial investment costs which will only subtract one from the current value. Again this operator precedence logic error can be resolved by the correct use of parentheses within the equation, as shown below.

Good

...
                     returnROI = (currentValue - initialInvestment) / initialInvestment;
                     ...

Note that the initialInvestment variable in this example should be validated to ensure that it is greater than zero to avoid a potential divide by zero error (CWE-369).

Mitigations & Prevention

Implementation

Regularly wrap sub-expressions in parentheses, especially in security-critical code.

Detection Methods

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 sea

Real-World CVE Examples

CVE ID	Description
CVE-2008-2516	Authentication module allows authentication bypass because it uses "(x = call(args) == SUCCESS)" instead of "((x = call(args)) == SUCCESS)".
CVE-2008-0599	Chain: Language interpreter calculates wrong buffer size (CWE-131) by using "size = ptr ? X : Y" instead of "size = (ptr ? X : Y)" expression.
CVE-2001-1155	Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.

Taxonomy Mappings

CERT C Secure Coding: EXP00-C — Use parentheses for precedence of operation
SEI CERT Perl Coding Standard: EXP04-PL — Do not mix the early-precedence logical operators with late-precedence logical operators

Frequently Asked Questions

What is CWE-783?

CWE-783 (Operator Precedence Logic Error) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product uses an expression in which operator precedence causes incorrect logic to be used.

How can CWE-783 be exploited?

Attackers can exploit CWE-783 (Operator Precedence Logic Error) to varies by context, unexpected state. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-783?

Key mitigations include: Regularly wrap sub-expressions in parentheses, especially in security-critical code.

What is the severity of CWE-783?

CWE-783 is classified as a Base-level weakness (Medium abstraction). It has been observed in 3 real-world CVEs.