CWE
CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.1)  

CWE-483: Incorrect Block Delimitation

 
Incorrect Block Delimitation
Weakness ID: 483 (Weakness Variant)Status: Draft
+ Description

Description Summary

The code does not explicitly delimit a block that is intended to contain 2 or more statements, creating a logic error.

Extended Description

In some languages, braces (or other delimiters) are optional for blocks. When the delimiter is omitted, it is possible to insert a logic error in which a statement is thought to be in a block but is not. In some cases, the logic error can have security implications.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability

Technical Impact: Alter execution logic

This is a general logic error which will often lead to obviously-incorrect behaviors that are quickly noticed and fixed. In lightly tested or untested code, this error may be introduced it into a production environment and provide additional attack vectors by creating a control flow path leading to an unexpected state in the application. The consequences will depend on the types of behaviors that are being incorrectly executed.

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(Bad Code)
 
if (condition==true)
Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

Example 2

In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

(Bad Code)
 
if (condition==true) Do_X();
Do_Y();

This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

+ Potential Mitigations

Phase: Implementation

Always use explicit block delimitation and use static-analysis technologies to enforce this practice.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class670Always-Incorrect Control Flow Implementation
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPIncorrect block delimitation
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Contributions
Contribution DateContributorOrganizationSource
2010-04-28Michael Koo and Paul BlackNISTFeedback
Correction to Demonstrative Examples
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences
2010-06-21CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
Page Last Updated: September 12, 2011