From ${URL} : Affected software: - Ruby gem (library) OmniAuth[0] - Gems that use OmniAuth, e.g. Devise[1] Type of vulnerability: Cross-Site Request Forgery Original report by: Mohamed Abdelbaset Elnoby, Senior Information Security Analyst at Seekurity.com[2] [The website Seekurity.com isn’t currently working.] Summary: OmniAuth is a library used in Ruby web applications to authenticate users using external services, for example OAuth providers. The request phase of OmniAuth is vulnerable to Cross-Site Request Forgery. This is the step that actually connects an external account (on a connected OAuth provider) to an internal account (on the web application itself). This means that when a client is signed into an account on the web application, and signed into an account on a connected OAuth provider, these two accounts can be connected without user intent, user interaction or feedback to the user. From here on out, the external account can be used to sign into the web application as the internal account. If the sign in action at a connected OAuth provider is vulnerable to CSRF, an attacker can force the victim’s client to be logged into the external service using an account beloning to the attacker, can then force this external account to be connected to the internal account, and can from here on out use their account on the external service to log into the victim’s account on the targeted application. We are aware of one large OAuth provider where the sign in action is or was vulnerable to CSRF. Issue report and patch: https://github.com/intridea/omniauth/pull/809 References: [0] https://github.com/intridea/omniauth [1] https://github.com/plataformatec/devise [2] https://twitter.com/symbiansymoh @maintainer(s): since the package or the affected version has never been marked as stable, we don't need to stabilize it. After the bump, please remove the affected versions from the tree.
The patch has not been accepted by upstream and they are actively looking for a different way to fix this. We'll wait for them to release new versions.
Upstream patch is available here: https://github.com/intridea/omniauth/pull/809/commits/561ef98f9e324da4740c8807b04bf3e367cf971b
@maintainer(s), please see previous comment with patch.
(In reply to Aaron Bauman from comment #3) > @maintainer(s), please see previous comment with patch. This patch was already mentioned in the original bug report. See comment 1 Note that upstream fixed this in omniauth-rails which is a component that we don't package. My suggestion is to close this issue as-is.
(In reply to Hans de Graaff from comment #4) > (In reply to Aaron Bauman from comment #3) > > @maintainer(s), please see previous comment with patch. > > This patch was already mentioned in the original bug report. See comment 1 > > Note that upstream fixed this in omniauth-rails which is a component that we > don't package. My suggestion is to close this issue as-is. Thanks for the update, we will leave the bug open until a fix is provided.
(In reply to Aaron Bauman from comment #5) > Thanks for the update, we will leave the bug open until a fix is provided. I'm fine with keeping the bug open, but I'm sure no bug fix will be forthcoming. Basically upstream said that, yes, it's possible to create CSRF issues with the omniauth framework, and this happens by default when using it in rails, so we fix the issue in omniauth-rails, but we cannot fix it in general because we cannot distinguish normal use from CSRF issues at the general level. It would be like masking sys-devel/gcc because it is possible to create buffer overflows with it.
(In reply to Hans de Graaff from comment #6) > (In reply to Aaron Bauman from comment #5) > > > Thanks for the update, we will leave the bug open until a fix is provided. > > I'm fine with keeping the bug open, but I'm sure no bug fix will be > forthcoming. Basically upstream said that, yes, it's possible to create CSRF > issues with the omniauth framework, and this happens by default when using > it in rails, so we fix the issue in omniauth-rails, but we cannot fix it in > general because we cannot distinguish normal use from CSRF issues at the > general level. > > It would be like masking sys-devel/gcc because it is possible to create > buffer overflows with it. Thanks for the information.
