yahoo-eng-team team mailing list archive

[Jeremy Stanley <1901207@xxxxxxxxxxxxxxxxxx>]

I have switched this bug to public, treating it as a security hardening
opportunity pending further insights from reviewers.

** Description changed:

- This issue is being treated as a potential security risk under
- embargo. Please do not make any public mention of embargoed
- (private) security vulnerabilities before their coordinated
- publication by the OpenStack Vulnerability Management Team in the
- form of an official OpenStack Security Advisory. This includes
- discussion of the bug or associated fixes in public forums such as
- mailing lists, code review systems and bug trackers. Please also
- avoid private disclosure to other individuals not already approved
- for access to this information, and provide this same reminder to
- those who are made aware of the issue prior to publication. All
- discussion should remain confined to this private bug report, and
- any proposed fixes should be added to the bug as attachments. This
- embargo shall not extend past 2021-01-21 and will be made
- public by or on that date even if no fix is identified.
- 
  Intro
  -----
  While performing a penetration test on a new OpenStack install of version Train, we found a vulnerability that could lead to a Denial of Service condition. Using an installation of DevStack we verified that the issue is still present.
  
  Description
  -----------
  In the test situation we had two, separate, projects, each with their own user. Users were only authorised for their own project, not for the other's project.
  
  After creating an application credential for user A, we were able to
  delete that credential with user B by issuing the OpenStack application
  credential delete command with the credential ID as parameter.
  
  Apparently, there is no authorisation check on the delete (and show)
  action and anyone who knows the credential ID can remove it, potentially
  creating a Denial of Service attack on the affected project.
  
  Precondition
  ------------
  - Logged in user (user B)
  - Knowing the ID of an application credential of another user (user A)
  
  Discovered on October 8, 2020 by Arjen Zijlstra (az@xxxxxxxxxx) and
  Arthur Donkers (arthur@xxxxxxxxxx)

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Tags added: security

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1901207

Title:
  Application credentials of other users can be deleted when knowing the
  ID

Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Intro
  -----
  While performing a penetration test on a new OpenStack install of version Train, we found a vulnerability that could lead to a Denial of Service condition. Using an installation of DevStack we verified that the issue is still present.

  Description
  -----------
  In the test situation we had two, separate, projects, each with their own user. Users were only authorised for their own project, not for the other's project.

  After creating an application credential for user A, we were able to
  delete that credential with user B by issuing the OpenStack
  application credential delete command with the credential ID as
  parameter.

  Apparently, there is no authorisation check on the delete (and show)
  action and anyone who knows the credential ID can remove it,
  potentially creating a Denial of Service attack on the affected
  project.

  Precondition
  ------------
  - Logged in user (user B)
  - Knowing the ID of an application credential of another user (user A)

  Discovered on October 8, 2020 by Arjen Zijlstra (az@xxxxxxxxxx) and
  Arthur Donkers (arthur@xxxxxxxxxx)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1901207/+subscriptions