891
and look for evidence of any unexpected behavior. Insert breakpoints or delays in between
relevant code statements to artificially expand the race window so that it will be easier to detect.
Effectiveness = Moderate
Automated Static Analysis - Binary or Bytecode
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Bytecode Weakness Analysis - including disassembler + source code weakness analysis Cost
effective for partial coverage: Binary Weakness Analysis - including disassembler + source code
weakness analysis
Effectiveness = High
Dynamic Analysis with Automated Results Interpretation
According to SOAR, the following detection techniques may be useful: Cost effective for partial
coverage: Web Application Scanner Web Services Scanner Database Scanners
Effectiveness = SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Framework-based Fuzzer Cost effective for partial coverage: Fuzz Tester Monitored Virtual
Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does
anything suspicious
Effectiveness = High
Manual Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Manual Source Code Review (not inspections) Cost effective for partial coverage: Focused
Manual Spotcheck - Focused manual analysis of source
Effectiveness = High
Automated Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Effectiveness = High
Architecture or Design Review
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE
1028 standard) (can apply to requirements, design, source code, etc.)
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
In languages that support it, use synchronization primitives. Only wrap these around critical code
to minimize the impact on performance.
Phase: Architecture and Design
Use thread-safe capabilities such as the data access abstraction in Spring.
Phase: Architecture and Design
Minimize the usage of shared resources in order to remove as much complexity as possible from
the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally,
this will minimize the amount of synchronization necessary and may even help to reduce the
CWE Version 4.14
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race
Condition')
CWE-362: Concurrent Execution using Shared Resource
with Improper Synchronization ('Race Condition') 892
likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical
section (CWE-400).
Phase: Implementation
When using multithreading and operating on shared variables, only use thread-safe functions.
Phase: Implementation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x+
+". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer,
since it involves a read, followed by a computation, followed by a write.
Phase: Implementation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
Phase: Implementation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying
to avoid the overhead of synchronization.
Phase: Implementation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does
not go into a large or infinite loop.
Phase: Implementation
Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or
reordering. This does not necessarily solve the synchronization problem, but it can help.
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the software or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations.
Demonstrative Examples
Example 1:
This code could be used in an e-commerce application that supports transfers between accounts.
It takes the total amount of the transfer, sends it to the new account, and deducts the amount from
the original account.
Example Language: Perl (Bad)
$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();
if ($transfer_amount < 0) {
FatalError("Bad Transfer Amount");
}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {
FatalError("Insufficient Funds");
}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");
A race condition could occur between the calls to GetBalanceFromDatabase() and
SendNewBalanceToDatabase().
CWE Version 4.14
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race
Condition')
CWE-362: Concurrent Execution using Shared Resource
with Improper Synchronization ('Race Condition')