GHSA-qxmr-qxh6-2cc9

Impact

Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like a.a..

Before the patch, it can be reproduced in the console like this:

irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the type attribute for that field from email to text. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.

Patches

Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

bin/rails solidus:check_orders_with_invalid_email

The above will print information for every affected order if any.

Workarounds

If a prompt upgrade is not an option, please, add the following to config/application.rb:

config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end

References

• https://en.wikipedia.org/wiki/ReDoS
• https://snyk.io/blog/redos-and-catastrophic-backtracking/

For more information

If you have any questions or comments about this advisory: * Open an issue or a discussion in Solidus. * Email us at security@solidus.io * Contact the core team on Slack