CVE Vulnerabilities

CVE-2023-40021

Observable Discrepancy

Published: Aug 16, 2023 | Modified: Aug 25, 2023
CVSS 3.x
5.3
MEDIUM
Source:
NVD
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
CVSS 2.x
RedHat/V2
RedHat/V3
Ubuntu

Oppia is an online learning platform. When comparing a received CSRF token against the expected token, Oppia uses the string equality operator (==), which is not safe against timing attacks. By repeatedly submitting invalid tokens, an attacker can brute-force the expected CSRF token character by character. Once they have recovered the token, they can then submit a forged request on behalf of a logged-in user and execute privileged actions on that users behalf. In particular the function to validate received CSRF tokens is at oppia.core.controllers.base.CsrfTokenManager.is_csrf_token_valid. An attacker who can lure a logged-in Oppia user to a malicious website can perform any change on Oppia that the user is authorized to do, including changing profile information; creating, deleting, and changing explorations; etc. Note that the attacker cannot change a users login credentials. An attack would need to complete within 1 second because every second, the time used in computing the token changes. This issue has been addressed in commit b89bf80837 which has been included in release 3.3.2-hotfix-2. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Weakness

The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.

Affected Software

Name Vendor Start Version End Version
Oppia Oppia 1.1.0 (including) 3.3.2 (excluding)
Oppia Oppia 3.3.2 (including) 3.3.2 (including)

Potential Mitigations

  • Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

References