CWE-484: Omitted Break Statement in Switch
Learn about CWE-484 (Omitted Break Statement in Switch), its security impact, exploitation methods, and prevention guidelines.
What is Omitted Break Statement in Switch?
• Overview:
- CWE-484 refers to the omission of a break statement in a switch construct, which causes unintended execution of code blocks associated with multiple conditions. This typically occurs in languages like C, C++, Java, C#, and PHP, where a switch statement is used. Developers might mistakenly allow code execution to "fall through" to subsequent cases, leading to unexpected behavior.
• Exploitation Methods:
- Attackers can exploit this vulnerability by triggering the switch statement with inputs that cause undesired code execution due to the lack of break statements.
- Common attack patterns include manipulating input data to cause fall-through logic, leading to the execution of critical or sensitive code blocks inadvertently.
• Security Impact:
- Direct consequences of successful exploitation include unintended code execution, which can lead to vulnerabilities, such as unauthorized access or data manipulation.
- Potential cascading effects include triggering additional vulnerabilities, escalating privileges, or causing system crashes.
- Business impact might involve data breaches, loss of customer trust, or regulatory penalties due to unintentional data exposure or manipulation.
• Prevention Guidelines:
- Specific code-level fixes include ensuring that each case block in a switch statement has a corresponding break statement, unless a deliberate fall-through is intended and clearly documented.
- Security best practices involve conducting thorough code reviews and employing static analysis tools to detect missing break statements.
- Recommended tools and frameworks include using static analysis tools such as SonarQube or Checkmarx to automatically identify and flag missing break statements in switch constructs.
Corgea can automatically detect and fix Omitted Break Statement in Switch in your codebase. Try Corgea free today.
Technical Details
Likelihood of Exploit:
Affected Languages: C, C++, Java, C#, PHP
Affected Technologies: Not specified
Vulnerable Code Example
// Vulnerable code demonstrating omitted break statement in a switch-case construct
#include <stdio.h>
void processInput(int input) {
switch (input) {
case 1:
printf("Processing option 1\n");
// Missing break statement, leads to fall-through to case 2
case 2:
printf("Processing option 2\n");
break;
default:
printf("Invalid option\n");
break;
}
}
int main() {
processInput(1); // Expecting only "Processing option 1" but will also print "Processing option 2"
return 0;
}
Explanation
In this vulnerable code example, the absence of a break
statement after case 1
results in unintended fall-through behavior. When the input is 1
, both case 1
and case 2
code blocks are executed, leading to logical errors and unexpected behavior. This could be particularly problematic if the subsequent cases perform sensitive operations or if the logic depends on each case being mutually exclusive.
How to fix Omitted Break Statement in Switch?
To resolve this issue, ensure that each case
in a switch statement is terminated with a break
statement, or another control statement like return
or exit
, unless fall-through is explicitly intended and documented. This prevents logical errors, improves code readability, and maintains proper control flow.
Fixed Code Example
#include <stdio.h>
void processInput(int input) {
switch (input) {
case 1:
printf("Processing option 1\n");
break; // Fixed: Added break to prevent fall-through
case 2:
printf("Processing option 2\n");
break;
default:
printf("Invalid option\n");
break;
}
}
int main() {
processInput(1); // Now correctly prints only "Processing option 1"
return 0;
}
Explanation
In the fixed code example, a break
statement is added after printf("Processing option 1\n");
. This ensures that once the code for case 1
is executed, the control exits the switch statement, preventing any unintended execution of subsequent cases. This correction not only prevents logical errors but also aligns the code with best practices for writing clear and maintainable switch-case constructs.