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 (a...@warpnet.nl) and
Arthur Donkers (art...@1secure.nl)
** 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 (a...@warpnet.nl) and
Arthur Donkers (art...@1secure.nl)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1901207/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
