Date: Tue, 17 Jul 2018 10:16:06 -0400 From: Justin Bull <me@...tinbull.ca> To: oss-security@...ts.openwall.com, bugtraq@...urityfocus.com, fulldisclosure@...lists.org Subject: [CVE-2018-1000211] Public apps can't revoke OAuth access & refresh tokens in Doorkeeper Good morning everyone, A security bulletin for all of you. Software: -------- Doorkeeper (https://github.com/doorkeeper-gem/doorkeeper) Description: ---------- Doorkeeper is an OAuth 2 provider for Rails written in Ruby. Affected Versions: --------------- 4.2.0 - 4.3.2 5.0.0.rc1 Fixed Versions: ------------- 4.4.0 5.0.0.rc2 Problem: -------- Any OAuth application that uses public/non-confidential authentication when interacting with Doorkeeper is unable to revoke its tokens when calling the revocation endpoint. A bug in the token revocation API causes it to try to authenticate the public OAuth client as if it was a confidential app. Because of this, the token is never revoked. If Doorkeeper is used to facilitate public OAuth apps and leverage token revocation functionality (RFC 7009), upgrade to the patched versions immediately. Impact: ------- All public, non-confidential clients respecting the RFC will not have their access or refresh tokens revoked when sending a valid, well-formed & unauthenticated revocation request to doorkeeper. Any such clients relying on Doorkeeper's revocation functionality are susceptible to a session replay attack, even after the victim terminates their session via a revocation/log out. 1. Attacker gains access token via any acceptable means (MiTM, physical computer access, bug in client code, etc.) 2. Victim logs out/attempts to revoke the access token 3. Attacker is not affected, as the token is still valid for the duration of its lifespan. Furthermore, the refresh token can be used to extend the attacker's privileged access. This scenario is captured under the OWASP Top 10 (2013)'s A2: Broken Authentication and Session Management as a vulnerability. Solution: --------- Doorkeeper needed a structural update so it is able to define which OAuth client application is intended to be public or confidential. With that now available, the tokens revocation API knows to either enforce authentication (as required for confidential clients) or accept just the client ID (as is the case for a public client). See the following PRs for more info: * https://github.com/doorkeeper-gem/doorkeeper/pull/1119 * https://github.com/doorkeeper-gem/doorkeeper/pull/1031 * https://github.com/doorkeeper-gem/doorkeeper/issues/891 Credit: ------- All credit to Roberto Ostinelli for discovery. Thanks to the Distributed Weakness Filing Project for a swift assignment of a CVE identifier (CVE-2018-1000211). References: ----------- : https://tools.ietf.org/html/rfc7009 : https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management : https://github.com/ostinelli
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ