CWE-208: Observable Timing Discrepancy | Glexia
CWE-208 (Observable Timing Discrepancy) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-208: Observable Timing Discrepancy
Observable Timing Discrepancy represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Confidentiality,Access Control: Read Application Data,Bypass Protection Mechanism
Developer Pattern
CWE-208 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-208, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-208: Observable Timing Discrepancy
Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.
In security-relevant contexts, even small variations in timing can be exploited by attackers to indirectly infer certain details about the product's internal operations. For example, in some cryptographic algorithms, attackers can use timing differences to infer certain properties about a private key, making the key easier to guess. Timing discrepancies effectively form a timing side channel.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- Consider an example hardware module that checks a user-provided password to grant access to a user. The user-provided password is compared against a golden value in a byte-by-byte manner. Since the code breaks on an incorrect entry of password, an attacker can guess the correct password for that byte-check iteration with few repeat attempts.,To fix this weakness, either the comparison of the entire string should be done all at once, or the attacker is not given an indication whether pass or fail happened by allowing the comparison to run through all bits before the grant_access signal is set.
- In this example, the attacker observes how long an authentication takes when the user types in the correct password. When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.,Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.
Remediation
- Use safe APIs
- Centralize the control
- Add regression tests
- Review logs and telemetry for attempted abuse
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.