Incorrect Short Circuit Evaluation
Weakness ID: 768 (Weakness Variant)Status: Incomplete
+ Description

Description Summary

The software contains conditionals with multiple logical expressions where one or more of the non-leading logical expressions produces side effects that may not be executed due to short circuiting logic. This may lead to an unexpected state in the program after the execution of the conditional.

Extended Description

Usage of short circuit evaluation, though well-defined in the C standard, may alter control flow in a way that introduces logic errors that are difficult to detect, leading to error-prone conditions later in the software's life cycle. If an attacker can discover such an inconsistency, it may be exploitable to gain arbitrary control over a system. If the first condition of an "or" statement is assumed to be true under normal circumstances, or if the first condition of an "and" statement is assumed to be false, then any subsequent conditional may contain its own logic errors that are not detected during code review or testing. Finally, the usage of short circuit evaluation may decrease the maintainability of the code.

+ Time of Introduction
  • Implementation
+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability

Widely varied consequences are possible if an attacker is aware of an unexpected state in the software after a conditional. It may lead to information exposure, a system crash, or even complete attacker control of the system.

+ Likelihood of Exploit

Very Low

+ Demonstrative Examples

Example 1

The following function attempts to take a size value from a user and allocate an array of that size (we ignore bounds checking for simplicity). The function tries to initialize each spot with the value of its index, that is, A[len-1] = len - 1; A[len-2] = len - 2; ... A[1] = 1; A[0] = 0; However, since the programmer uses the prefix decrement operator, when the conditional is evaluated with i == 1, the decrement will result in a 0 value for the first part of the predicate, causing the second portion to be bypassed via short-circuit evaluation. This means we cannot be sure of what value will be in A[0] when we return the array to the user.

(Bad Code)
Example Language: C 
#define PRIV_ADMIN 0
#define PRIV_REGULAR 1
typedef struct{
int privileges;
int id;
} user_t;
user_t *Add_Regular_Users(int num_users){
user_t* users = (user_t*)calloc(num_users, sizeof(user_t));
int i = num_users;
while( --i && (users[i].privileges = PRIV_REGULAR) ){
users[i].id = i;
}
return users;
}
int main(){
user_t* test;
int i;
test = Add_Regular_Users(25);
for(i = 0; i < 25; i++) printf("user %d has privilege level %d\n", test[i].id, test[i].privileges);
}

When compiled and run, the above code will output a privilege level of 1, or PRIV_REGULAR for every user but the user with id 0 since the prefix increment operator used in the if statement will reach zero and short circuit before setting the 0th user's privilege level. Since we used calloc, this privilege will be set to 0, or PRIV_ADMIN.

+ Potential Mitigations

Phase: Implementation

Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class691Insufficient Control Flow Management
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to protect stored data from modification
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-03-03Internal CWE Team
Back to top