Everyone,
Summary: The CWE Team wishes to consult with software security experts about possible deprecation for "CWE-365: Race Condition in Switch" due to no documented cases where it can occur. Feedback is welcome to c...@mitre.org by March 31. CWE-365 was based on The CLASP Application Security Process section 5.4.6, (c) 2005 Secure Software, Inc. (see https://cwe.mitre.org/about/sources.html). This section of the manual covers the state of a switch statement going stale and therefore out of sync. This can only occur if the switch's conditional expression is evaluated more than once. After community feedback and review, we have been unable to find an instance where the switch statement is evaluated more than once. Therefore, the state of the switch statement can only become stale is when multiple threads are operating and one interferes with the expression evaluated by the switch. If we are talking about the evaluation being done incorrectly due to multiple threads, this would be better characterized as CWE-366: Race Condition within a Thread. Details: CWE-365's demonstrative example is based on C code taken from CLASP. Each case statement must be a constant, and it can't be re-evaluated. In the ANSI standards we researched (e.g., ISO/IEC 9899:TC3 http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1256.pdf), the specific standard does not clearly state that the switch is evaluated once. In practicality, the evaluation of the switch statement has been proven to only be evaluated once across gcc 3.4.1 through 13.0.1 and clang 4.8.1 through 11.2. Analysis of the assembly code for this example confirms it is only evaluated once, and thus this weakness cannot occur. We examined the documentation for several languages including Assembler, Ada, ALGOL, COBOL, C++, C#, Erlang, Fortran, F#, Go, Haskell, JavaScript, Lisp, PHP, Python, Ruby, Rust, and VB.net. This showed that switch statements and their equivalent (e.g., match, case, EVALUATE, select case) specify that the evaluation is done only once. Some of them say this and then state that it is the equivalent to a series of 'if statements' (which would cause the evaluation to be completed multiple times). Despite the ambiguity in the documentation for some languages, in practice they all evaluate the Boolean statement once. If future languages state that this code explicitly evaluates the Boolean for each value, this would not be a weakness but the language performing as designed. Because CWE-365 is not known to identify any real-world issue, we plan to deprecate this weakness in CWE 4.7, which is planned to be released in early April. If anybody knows of real-world examples in which a switch conditional is evaluated more than once, please notify c...@mitre.org by March 31. Acknowledgements: We thank the following people who have reported concerns with CWE-365 and helped us conduct the analysis, including representatives from code analysis vendors, a co-author of the original CLASP document, members of standards groups, and others. Yongchool Ryu, MathWorks Roberto Bagnara, BUGSENG Guido Persch, Imagix John Blattner, Imagix Paul Anderson, GrammaTech Fulvio Baccaglini John Viega Members of the CWE-Research mailing list, including Jonathan Hood and Steve Grubb Thank you Steve Battista 703 634-9228
