Thanks for checking. Since we didn't treat bug 1842749 as a
vulnerability, and the risks for this are the same or a subset of that
report, we should proceed in a similar fashion with this report as well.
I'll switch it to public now.
** Description changed:
- This issue is being treated as a
Looks like my comment raced Slawek's second. If there is no change
planned to the default policy nor specific recommendations for operators
to adjust their own, then an OSSN wouldn't be appropriate either.
It's possible this is merely a case that needs to be more clearly
explained in Neutron's
Thanks for the analysis everyone! In addition to the points made, the
VMT generally considers exploits requiring someone to know or guess the
UUID associated with another tenant or another tenant's resources as a
fairly low risk on its own, and bugs which leak the UUIDs of things to
users who
Since the fix provided for the upcoming 2024.1 coordinated release
requires additional actions on the part of the operator to apply to
existing deployments affected by the former behavior, it won't qualify
for a security advisory (OSSA) but may still warrant a security note
(OSSN) if anyone feels
Thanks for flagging the potential security impact of this. Can someone
provide a succinct exploit scenario for how an attacker might cause this
to occur and then take advantage of it? Or is it merely one of those
situations where someone could take advantage of the issue if they
happen to find an
Note that you've changed the information type of this bug to Public
Security, indicating it represents a possible security vulnerability.
Since the OpenStack Vulnerability Management Team (VMT) does not
officially oversee[*] the neutron-vpnaas deliverable, I'm adding a
security advisory task with
As annoying and disturbing as this bug is, we still years later lack
sufficient information to be able to reproduce and study the behavior in
order to even attempt to identify a root cause. Unless that situation
changes, it seems impractical to exploit at the very least. In
discussion between VMT
Based on discussion between members of the VMT and others in the
OpenStack Security SIG during the 2023.1 PTG, it appears that any fixes
will depend on non-backportable default behavior or configuration
changes. An OSSN might be warranted, but we wouldn't likely issue a
security advisory about
Based on discussion between VMT members and others in the OpenStack
Security SIG during the 2023.1 PTG, it's presumed that all maintained
branches of affected projects are no longer subject to this problem.
Since it was fixed in master and then the affected branches eventually
aged out of
The lack of priority on this over the past 6 years seems to indicate
it's not a severe enough risk to warrant a widely published advisory
even if a fix ever does merge. The VMT and other OpenStack Security SIG
members agreed during the 2023.1 cycle that this should be considered
class B2 per our
*** This bug is a duplicate of bug 1700501 ***
https://bugs.launchpad.net/bugs/1700501
Thanks Dan. I've switched the bug report to public and set the security
advisory task to "won't fix" (indicating there are no plans to issue a
security advisory covering this topic).
I'll also set it as a
** Changed in: ossn
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2004555
Title:
[OSSA-2023-003] Unauthorized volume access
to contact me.
** Information type changed from Private Security to Public Security
** Also affects: ossn
Importance: Undecided
Status: New
** Changed in: ossn
Importance: Undecided => High
** Changed in: ossn
Status: New => In Progress
** Changed in: ossn
Assignee: (un
I've set the VMT's advisory tab to Won't Fix and switched the bug from
Public Security to normal Public state, consistent with a hardening
opportunity. We normally also add the "security" tag but it's already
present.
** Changed in: ossa
Status: New => Won't Fix
** Information type
I missed setting the security advisory task to won't fix state when we
decided on this as a security hardening opportunity, so have done so now
(as it won't have any advisory issued).
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you
** Also affects: ossa
Importance: Undecided
Status: New
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1988026
Title:
*** This bug is a duplicate of bug 1927677 ***
https://bugs.launchpad.net/bugs/1927677
That would be a question for the Ubuntu package maintainers, but we did
publish backports to the stable/train branch for that advisory and its
errata.
Thanks for confirming this is the same issue, I'll
I caught up with Sean in IRC and he confirmed the situation is basically
as I inferred above (exploitable by any normal authenticated user, not
just limited to operator level accounts).
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New =>
Is there a preferred place in the Keystone documentation to point users
about this potential pitfall, and can we do anything to make it more
clear?
** Changed in: ossa
Status: Incomplete => Invalid
** Description changed:
- This issue is being treated as a potential security risk under
-
*** This bug is a duplicate of bug 196 ***
https://bugs.launchpad.net/bugs/196
** Information type changed from Private Security to Public
** This bug has been marked a duplicate of bug 196
Javascript libraries with vulnerabilities
--
You received this bug notification
Thanks for confirming. I've switched the report to a normal public bug
and marked our security advisory task as inapplicable, since this
doesn't represent any exploitable vulnerability in the project. At
worst, a developer could cherry-pick a malicious proposed change for the
source and consume
Given this has been over a year and a half the reporter acknowledged
they were fixing the configuration error in their environment, and they
haven't responded further to a request for update in that time, I'm
switching the report to public now.
** Information type changed from Private Security to
Thanks Bence! Based on your findings, the OpenStack VMT will consider
this a class C2 report (vulnerability in a dependency) per our taxonomy:
https://security.openstack.org/vmt-process.html#report-taxonomy
If new information comes to light, please update this bug and we'll
revisit the
ecided
** Changed in: ossa
Assignee: Jeremy Stanley (fungi) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1927677
Title:
[OSSA-2021-002] Open
Rodolfo: Thanks for working on this one, and for the details. Based on
your analysis, I'll also suggest that this probably does not meet the
risk level necessary to warrant publishing a security advisory. I
propose that we consider it class C1 (an impractical vulnerability) per
our report
After discussing, the Vulnerability Management Team members have
concluded that the in-progress but incomplete RBAC implementation in
various projects does not rise to the level of requiring a published
security advisory, particularly as this work is likely to take place
primarily in development
After discussing, the Vulnerability Management Team members have
concluded that the in-progress but incomplete RBAC implementation in
various projects does not rise to the level of requiring a published
security advisory, particularly as this work is likely to take place
primarily in development
Actually, when starting to mark this as a duplicate, I noticed that
there was another report set as a duplicate of this one in Private
Security state. Because it was set as a duplicate it didn't show up in
our usual queries and so we missed switching it to Public Security when
its embargo was set
This report seems very similar to
https://security.openstack.org/ossa/OSSA-2014-023.html (CVE-2014-3474),
which was fixed in Horizon's Juno release (2014.2) and backported to
Icehouse (in 2014.1.2), and Havana (in 2013.2.4). Without a clear
statement of which version the reporter found this in and
The indicated fix merged during the Ussuri development cycle, so in
theory this bug should be valid only for stable/train and older
branches. Given stable/train is scheduled to enter extended maintenance
phase tomorrow, there is no opportunity to backport the fix to it and
issue a point release at
Yes, since this bug is only valid for branches which are no longer in a
maintained state, there is little point in issuing an advisory.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Thanks for following up on this longstanding report. Given the fix is
unlikely to be backported to supported stable branches, the VMT
considers such reports class B1 ( https://security.openstack.org/vmt-
process.html#incident-report-taxonomy ) so there's no call for issuing
an advisory.
**
We discussed this at some length earlier today in the #openstack-nova
IRC channel:
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-
nova.2021-03-16.log.html#t2021-03-16T14:31:57
Given that the information is already public, and the bug in this case
is incomplete
** Summary changed:
- Images v2 api metadef vulnerability
+ [OSSN-0088] Images v2 api metadef vulnerability
** Also affects: ossn
Importance: Undecided
Status: New
** Changed in: ossn
Status: New => Fix Released
** Changed in: ossn
Importance: Undecided => Critical
**
We'll be switching this bug public shortly along with bug 1916926 under
a single publication (OSSN-0088).
** 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
** 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
Thanks for digging into the report. Based on your analysis, the VMT has
no plans to issue an advisory, since none of our supported releases is
considered vulnerable to this any longer. If new information is brought
to light which indicates there is still a means to exploit this flaw in
more recent
This report came up in another discussion today, so for clarity I just
wanted to state that the VMT is considering it a security hardening
opportunity for now. If this is an avenue for filling up a reasonably
provisioned database before an operator's typical database resource
monitoring solution
Given nobody has objected to the proposed classifications in my comment
#2 from October, I'll go ahead and mark our security advisory task Won't
Fix for this. We can revisit the decision if anyone disagrees.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Information type changed
Since nobody has disputed Sean's assertions in the nearly half a year
since his comment #8 above, I'm going to assume the VMT no longer needs
to track this and is unlikely to issue any security advisory about it,
so am marking our advisory task Won't Fix.
** Changed in: ossa
Status:
As nobody has disagreed with my proposal a year ago to treat this as a
class C1 report, I'm marking our security advisory task for it Won't
Fix.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Information type changed from Public Security to Public
** Tags added: security
--
You
I've set our security advisory task for this to Won't Fix as it's a
class C2 report per our taxonomy (A vulnerability, but not in OpenStack
supported code, e.g., in a dependency): https://security.openstack.org
/vmt-process.html#incident-report-taxonomy
** Changed in: ossa
Status:
Fixes merged so long ago that no vulnerable branches are still
supported, so I've marked our security advisory task Won't Fix
indicating publication of any advisory at this point is highly unlikely.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification
The vulnerable branches are no longer officially supported, so I'm going
to set our security advisory task to Won't Fix indicating we won't be
publishing one about this.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of
Thanks, I've switched this to a normal public bug and set our security
advisory task to Won't Fix indicating there shouldn't be any advisory
publication required. The OpenStack VMT is treating this as a class E
report (neither a vulnerability nor hardening opportunity) per our
taxonomy:
At least from an upstream openstack/neutron source code perspective, the
fix was included in the 16.3.0 tag on the stable/ussuri branch two weeks
ago.
** No longer affects: ossn
** Information type changed from Public Security to Public
** Tags added: security
--
You received this bug
** No longer affects: ossa
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1693670
Title:
Fix doc generation for Python3
Status in Barbican:
Fix Released
Status in Cue:
In Progress
Thanks, given the circumstances with fixes already being discussed in
public and the low risk of this being directly exploited, I've gone
ahead and made the report public now and tagged it as security-related.
I've also set our coordinated advisory task to "won't fix" indicating
that I think there
OSSA-2020-008 has been published to relevant mailing lists and the
https://security.openstack.org/ site.
** Changed in: ossa
Assignee: (unassigned) => Gage Hugo (gagehugo)
** Changed in: ossa
Status: Incomplete => Fix Released
** Changed in: ossa
Importance: Undecided => Medium
I've switched this bug to Public and marked it as security affecting. It
sounds like a serious defect with security implications, and might
warrant a security note if it turns out to be unfixable in supported
branches for some reason, but I don't think we would issue an advisory
about it (class D
As there have been no objections to my proposal to treat this as
security hardening, I'm switching our advisory task to won't fix status
indicating we won't publish any formal security advisory about it. This
decision can of course be reversed if people feel differently about the
relative severity
None of the branches which ever carried this bug are in a maintained
state (the release in which the fix first appeared in under extended
maintenance already), so there is little point in entertaining an
advisory now. Switching the OSSA task to invalid.
** Changed in: ossa
Status: Triaged
Treating this as a security hardening opportunity, no advisory needed.
** Changed in: ossa
Status: New => Won't Fix
** Information type changed from Public Security to Public
** Tags added: security
--
You received this bug notification because you are a member of Yahoo!
Engineering
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
I'm inclined to classify this as a security hardening opportunity, since
there are likely countless ways a server instance can hammer the
metadata API and connecting networks, and the offending system can be
readily identified and disabled by operators. The security impact also
obviously only
Also, the duplicate (bug 1899228) is still public anyway.
** Information type changed from Private Security to Public
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Won't Fix
--
You received this bug notification because you are a
I've made this report public. For now the OpenStack VMT is considering
it a security hardening opportunity (class D report), so no
corresponding advisory publication is planned but fixing is still
encouraged of course: https://security.openstack.org/vmt-process.html
#incident-report-taxonomy
**
*** This bug is a duplicate of bug 1865026 ***
https://bugs.launchpad.net/bugs/1865026
Turns out any URL provided in the next value will be followed
automatically, so this is an open redirect (duplicate of bug 1865026).
** No longer affects: ossa
** Information type changed from Public to
Also, after more carefully re-reading what Mark put in the bug
description, I retract what I said in comment #2. This isn't a CWE-601
case as it doesn't allow to perform an actual redirect (or even support
markup, so no embedded clickable link). Sounds like the most it can do
is provide
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1669482
Title:
fwaas: firewall rules not applied on L3 agents reboot in case of
I've switched this to a regular Public bug and removed our security
advisory task, but marked it with the security tag as a possible
hardening opportunity.
** Information type changed from Public Security to Public
** No longer affects: ossa
** Tags added: security
--
You received this bug
** Changed in: ossa
Assignee: (unassigned) => Jeremy Stanley (fungi)
** Changed in: ossa
Importance: Undecided => High
** Changed in: ossa
Status: In Progress => Fix Released
** Summary changed:
- Soft reboot after live-migration reverts instance to original source do
** Changed in: ossa
Status: In Progress => Fix Released
--
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/1872737
Title:
[OSSA-2020-003] Keystone doesn't check
** 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
Thanks for confirming, Brian. I've ended the embargo and switched this
to public. No advisory expected, class B3 report.
** 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
Because this report only describes well-known behaviors of the software,
I've switched it to public now. The OpenStack Vulnerability Management
Team is not tracking this any longer since it does not seem to represent
any vulnerability or hardening opportunity (hence the "invalid" advisory
status),
** Changed in: ossa
Status: Incomplete => Invalid
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1736920
I've set our advisory task to Won't Fix on this one, as no advisory is
required with the fix for bug 1872735 effectively preventing the path to
exploitation.
** Tags added: security
** Information type changed from Public Security to Public
** Changed in: ossa
Status: Incomplete => Won't
** Also affects: ossn
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1875630
Title:
issue OSSN when glance no longer requires an md5
As there seems to be some consensus, I've gone ahead and switched this
bug to public, marking our security advisory task Won't Fix. I'll leave
it to the Keystone maintainers to do the same with theirs.
** Description changed:
- This issue is being treated as a potential security risk under
-
Given this is only being fixed in master, and is also not in itself a
vulnerability, I don't think we'll need a formal security advisory and
CVE assignment. This is probably most accurately classified as a
security hardening opportunity (report class D in the VMT's taxonomy):
Per Tristan's suggestion, the VMT will treat this as a security
hardening opportunity, no advisory needed.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Information type changed from Public Security to Public
** Tags added: security
--
You received this bug notification
** 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
*** This bug is a duplicate of bug 1501206 ***
https://bugs.launchpad.net/bugs/1501206
Thanks! I've switched this to public and marked it as a duplicate.
** Description changed:
- This issue is being treated as a potential security risk under
- embargo. Please do not make any public mention
If mitigating this on some supported stable branches is going to require
the operator to make configuration changes, then this is probably better
handled as a security note than an advisory.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Also affects: ossn
Importance: Undecided
Per bug 1837877 this can be treated as a hardening opportunity, but no
further advisory should be needed.
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Won't Fix
** Information type changed from Public Security to Public
--
You
Thanks for the feedback everyone. We'll classify it as a security
hardening opportunity in that case, no advisory needed.
** Changed in: ossa
Status: Incomplete => Won't Fix
** Information type changed from Public Security to Public
** Tags added: security
--
You received this bug
** Changed in: ossa
Status: Incomplete => Won't Fix
** 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
Reviewing our taxonomy, this probably fits closest as a class C1 report
due to depending on the existence of other exploitable bugs to leverage.
https://security.openstack.org/vmt-process.html#incident-report-taxonomy
** Information type changed from Private Security to Public
** Changed in:
Since there's been no objection, I'm switching this bug report to public
and assessing as class D (security hardening opportunity) per the
OpenStack VMT's report taxonomy: https://security.openstack.org/vmt-
process.html#incident-report-taxonomy
** Information type changed from Private Security
** Changed in: ossa
Status: In Progress => Fix Released
** Changed in: ossa
Importance: Undecided => High
** Changed in: ossa
Assignee: (unassigned) => Jeremy Stanley (fungi)
--
You received this bug notification because you are a member of Yahoo!
Engineering Te
For a while I've been meaning to raise the topic of dropping requirement
#5 from
https://governance.openstack.org/tc/reference/tags/vulnerability_managed.html#requirements
since it was a high bar to clear and even projects which were previously
under vulnerability management before the tag existed
I concur with the class C1 suggestion here. Generally OpenStack's VMT
has considered any theoretical vulnerability which depends on direct
brute-forcing or guessing the UUID space as impractical, but still
possibly a security hardening opportunity.
** Information type changed from Public Security
The extended maintenance branch patches are still up for review, but
since all the stable maintenance branch patches have now merged I'm
closing the security advisory task.
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
I see there's a series bugtask confirmed for Stein. Does this affect
other branches presently under stable maintenance?
Also, as openstack/os-vif is not tagged vulnerability:managed in
governance and the Nova bugtask was invalidated, I'm marking our
Advisory task Won't Fix but am still happy to
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
** Also affects: ossa
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
(The duplicate bug 1813439 was
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
** Information type changed
Since this definitely will benefit from a broader discussion and there's
no benefit to keeping the report private, I've switched it to public
security for now.
I feel like this doesn't actually describe a vulnerability which would
get fixes backported to old releases, but rather a security
Thanks Sam, I don't expect the Nova security reviewers to object as
they're unable to reproduce this and consider the bug apparently fixed
in the Queens release anyway. Setting the security advisory task to
won't fix state, but can be revisited if any new information comes to
light.
**
Seems there's support for switching this to public and no real
disagreement with my suggestion a month ago to treat this as a security
hardening opportunity rather than a vulnerability, so I'll triage it
publicly as such now and we can continue to debate/fix without any
further embargo.
Treating
** Changed in: ossa
Importance: Undecided => Critical
** Changed in: ossa
Assignee: (unassigned) => Jeremy Stanley (fungi)
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Te
** Changed in: ossa
Status: Confirmed => Fix Released
** Summary changed:
- [SRU] Unable to install new flows on compute nodes when having broken
security group rules (CVE-2019-10876)
+ [SRU] [OSSA-2019-002] Unable to install new flows on compute nodes when
having broken security group
Unless there's a way for a malicious actor to trigger and take advantage
of this condition, this is probably a class D (security hardening
opportunity) report: https://security.openstack.org/vmt-process.html
#incident-report-taxonomy
** Also affects: ossa
Importance: Undecided
Status:
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1818385
Title:
[OSSA-2019-001] It's possible to add a security group rule
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
** Also affects: ossa
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
** Information type changed
Thanks, I've gone ahead and triaged this as a hardening opportunity for
now.
** 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!
Based on consensus above, I've switched the bug to public and triaged it
as a class D report, tagging it as a potential hardening opportunity or
security-related improvement.
** Information type changed from Private Security to Public
** Description changed:
- This issue is being treated as a
Thanks everyone for the prompt analysis. I've triaged this as a class B2
port per the OpenStack VMT taxonomy: https://security.openstack.org/vmt-
process.html#incident-report-taxonomy
** Information type changed from Private Security to Public
** Changed in: ossa
Status: Incomplete =>
1 - 100 of 255 matches
Mail list logo
