This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Race condition in switch"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
 +
 
 +
 
 +
==Description==
  
 
If the variable which is switched on is changed while the switch statement is still in progress, undefined activity may occur.
 
If the variable which is switched on is changed while the switch statement is still in progress, undefined activity may occur.
  
==Consequences ==
+
'''Consequences'''
  
* Undefined: This flaw will result in the system state going out of sync.
+
* Undefined: This flaw will result in the system state going out of sync.
  
==Exposure period ==
+
'''Exposure period'''
  
* Implementation: Variable locking is the purview of implementers.
+
* Implementation: Variable locking is the purview of implementers.
  
==Platform ==
+
'''Platform'''
  
* Languages: All that allow for multi-threaded activity
+
* Languages: All that allow for multi-threaded activity
 +
* Operating platforms: All
  
* Operating platforms: All
+
'''Required resources'''
 
 
==Required resources ==
 
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
Medium
 
Medium
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
This issue is particularly important in the case of switch statements that involve fall-through style case statements - i.e., those which do not end with break.
  
* Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements.
+
If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption.  
  
==Discussion ==
+
For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends.
  
This issue is particularly important in the case of switch statements that involve fall-through style case statements - i.e., those which do not end with break.
 
  
If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption.
 
  
For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends.
+
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
==Examples==
  
==Examples ==
 
  
 
In C/C++:
 
In C/C++:
Line 69: Line 79:
 
</pre>
 
</pre>
  
==Related problems ==
+
 
 +
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
  
 
* [[Race condition in signal handler]]
 
* [[Race condition in signal handler]]
 +
* [[Race condition within a thread]]
 +
 +
 +
==Related [[Controls]]==
 +
 +
* Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements.
 +
 +
 +
==Related [[Technical Impacts]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
  
* [[Race condition within a thread]]
+
 
 +
==References==
 +
 
 +
TBD
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
 +
 
 +
Error Handling Vulnerability
 +
 
 +
Input Validation Vulnerability
 +
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
 +
 
 +
__NOTOC__
  
  
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]
 
[[Category:Synchronization and Timing Vulnerability]]
 
[[Category:Synchronization and Timing Vulnerability]]

Revision as of 13:35, 30 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

Last revision (mm/dd/yy): 09/30/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


Description

If the variable which is switched on is changed while the switch statement is still in progress, undefined activity may occur.

Consequences

  • Undefined: This flaw will result in the system state going out of sync.

Exposure period

  • Implementation: Variable locking is the purview of implementers.

Platform

  • Languages: All that allow for multi-threaded activity
  • Operating platforms: All

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

This issue is particularly important in the case of switch statements that involve fall-through style case statements - i.e., those which do not end with break.

If the variable which we are switching on change in the course of execution, the actions carried out may place the state of the process in a contradictory state or even result in memory corruption.

For this reason, it is important to ensure that all variables involved in switch statements are locked before the statement starts and are unlocked when the statement ends.


Risk Factors

TBD

Examples

In C/C++:

#include <sys/types.h>
#include <sys/stat.h>

int main(argc,argv){
        struct stat *sb;
        time_t timer;

        lstat("bar.sh",sb);

        printf("%d\n",sb->st_ctime);
        switch(sb->st_ctime % 2){
                case 0: printf("One option\n");break;
                case 1: printf("another option\n");break;
                default: printf("huh\n");break;
        }

        return 0;
}


Related Attacks


Related Vulnerabilities


Related Controls

  • Implementation: Variables that may be subject to race conditions should be locked for the duration of any switch statements.


Related Technical Impacts


References

TBD