Devise is an authentication solution for Rails based on Warden. Prior to version 5.0.3, a race condition in Devises Confirmable module allows an attacker to confirm an email address they do not own. This affects any Devise application using the reconfirmable option (the default when using Confirmable with email changes). By sending two concurrent email change requests, an attacker can desynchronize the confirmation_token and unconfirmed_email fields. The confirmation token is sent to an email the attacker controls, but the unconfirmed_email in the database points to a victims email address. When the attacker uses the token, the victims email is confirmed on the attackers account. This is patched in Devise v5.0.3. Users should upgrade as soon as possible. As a workaround, applications can override a specific method from Devise models to force unconfirmed_email to be persisted when unchanged. Note that Mongoid does not seem to respect that will_change! should force the attribute to be persisted, even if it did not really change, so the user might have to implement a workaround similar to Devise by setting changed_attributes[unconfirmed_email] = nil as well.
Weakness
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Extended Description
A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:
A race condition exists when an “interfering code sequence” can still access the shared resource, violating exclusivity. The interfering code sequence could be “trusted” or “untrusted.” A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.
Potential Mitigations
- 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 likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).