CVE-2024-8796
ADVISORY - githubSummary
Summary
Under the default configuration, Devise-Two-Factor versions 1.0.0 or >= 4.0.0 & < 6.0.0 generate TOTP shared secrets that are 120 bits instead of the 128-bit minimum defined by RFC 4226. Using a shared secret shorter than the minimum to generate a multi-factor authentication code could make it easier for an attacker to guess the shared secret and generate valid TOTP codes.
Remediation
Devise-Two-Factor should be upgraded to version v6.0.0 as soon as possible. After upgrading, the length of shared secrets and TOTP URLs generated by the library will increase since the new shared secrets will be longer.
If upgrading is not possible, you can override the default otp_secret_length attribute in the model when configuring two_factor_authenticable and set it to a value of at least 26 to ensure newly generated shared secrets are at least 128-bits long.
After upgrading or implementing the workaround, applications using Devise-Two-Factor may wish to migrate users to the new OTP length to provide increased protection for those accounts. Turning off OTP for users by setting otp_required_for_login to false is not recommended since it would leave accounts unprotected. However, you may wish to implement application logic that checks the length of a user's shared secret and prompts users to re-enroll in OTP.
Background
Devise-Two-Factor uses ROTP to generate shared secrets for TOTP. In ROTP < 5.0.0, the first argument to the ROTP::Base32#random_base32 function represented the number of bytes to read from SecureRandom which were then returned as a base32-encoded string. In ROTP 5.1.0, this function was changed so that the first argument now represents the length of the base32-encoded string returned by the function instead of the number of bytes to read from SecureRandom resulting in a shorter key being generated for the same input value. (https://github.com/mdp/rotp/commit/15d5104e3cb99f97d36c772f8f09cf7e2e77de20).
Common Weakness Enumeration (CWE)
Insufficient Entropy
Insufficient Entropy
GitHub
1.6
CVSS SCORE
6medium| Package | Type | OS Name | OS Version | Affected Ranges | Fix Versions |
|---|---|---|---|---|---|
| devise-two-factor | gem | - | - | >=4.0.0,<6.0.0 | 6.0.0 |
CVSS:4 Severity and metrics
The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.
The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).
A successful attack depends on conditions beyond the attacker's control, requiring investing a measurable amount of effort in research, preparation, or execution against the vulnerable component before a successful attack.
The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection. The attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker).
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges.
There is a total loss of confidentiality, resulting in all information within the Vulnerable System being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
There is no loss of integrity within the Vulnerable System.
There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
There is no impact to availability within the Vulnerable System.
There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
NIST
1.6
CVSS SCORE
6mediumDebian
-
Ubuntu
1.6
CVSS SCORE
5.3mediumChainguard
CGA-3fvw-rrp6-2v49
-