| 2022-06-13 19:19:36 |
Anthony |
bug |
|
|
added bug |
| 2022-06-13 19:46:25 |
Brian Haley |
bug |
|
|
added subscriber Brian Haley |
| 2022-06-14 12:30:54 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2022-06-14 12:31:00 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2022-06-14 12:31:29 |
Jeremy Stanley |
description |
Neutron allows multiple firewall groups to be attached to ports:
MariaDB [neutron]> describe firewall_group_port_associations_v2;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| firewall_group_id | varchar(36) | YES | MUL | NULL | |
| port_id | varchar(36) | YES | UNI | NULL | |
+-------------------+-------------+------+-----+---------+-------+
2 rows in set (0.001 sec)
However, these associations are not ordered.
We have a use-case where we'd like to define a shared firewall group that tenants can apply in their environments, then add their own, private firewall group above the shared group.
For example, suppose we have an admin owned shared group that allows some RFC1918 space, denies all other RFC1918 networks, then passes all other traffic. A tenant should be able to apply this group, then put their own group above it to allow additional RFC1918 space.
Currently, the group associations will shift on association, so the private group can get popped to below the shared group, effectively blocking traffic that should be allowed.
This can also be a security vulnerability, as the shifting of firewall groups and reordering of rules could easily allow traffic that was previously denied.
Firewall group port associations should be ordered so that the combined ruleset on a port is evaluated in the desired order. |
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 2022-09-12 and will be made
public by or on that date even if no fix is identified.
Neutron allows multiple firewall groups to be attached to ports:
MariaDB [neutron]> describe firewall_group_port_associations_v2;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| firewall_group_id | varchar(36) | YES | MUL | NULL | |
| port_id | varchar(36) | YES | UNI | NULL | |
+-------------------+-------------+------+-----+---------+-------+
2 rows in set (0.001 sec)
However, these associations are not ordered.
We have a use-case where we'd like to define a shared firewall group that tenants can apply in their environments, then add their own, private firewall group above the shared group.
For example, suppose we have an admin owned shared group that allows some RFC1918 space, denies all other RFC1918 networks, then passes all other traffic. A tenant should be able to apply this group, then put their own group above it to allow additional RFC1918 space.
Currently, the group associations will shift on association, so the private group can get popped to below the shared group, effectively blocking traffic that should be allowed.
This can also be a security vulnerability, as the shifting of firewall groups and reordering of rules could easily allow traffic that was previously denied.
Firewall group port associations should be ordered so that the combined ruleset on a port is evaluated in the desired order. |
|
| 2022-06-14 12:31:53 |
Jeremy Stanley |
bug |
|
|
added subscriber Neutron Core Security reviewers |
| 2022-06-16 16:29:39 |
Miguel Lavalle |
bug |
|
|
added subscriber Lajos Katona |
| 2022-06-17 08:50:44 |
Lajos Katona |
bug |
|
|
added subscriber ZhouHeng |
| 2022-06-22 16:23:29 |
Jeremy Stanley |
description |
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 2022-09-12 and will be made
public by or on that date even if no fix is identified.
Neutron allows multiple firewall groups to be attached to ports:
MariaDB [neutron]> describe firewall_group_port_associations_v2;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| firewall_group_id | varchar(36) | YES | MUL | NULL | |
| port_id | varchar(36) | YES | UNI | NULL | |
+-------------------+-------------+------+-----+---------+-------+
2 rows in set (0.001 sec)
However, these associations are not ordered.
We have a use-case where we'd like to define a shared firewall group that tenants can apply in their environments, then add their own, private firewall group above the shared group.
For example, suppose we have an admin owned shared group that allows some RFC1918 space, denies all other RFC1918 networks, then passes all other traffic. A tenant should be able to apply this group, then put their own group above it to allow additional RFC1918 space.
Currently, the group associations will shift on association, so the private group can get popped to below the shared group, effectively blocking traffic that should be allowed.
This can also be a security vulnerability, as the shifting of firewall groups and reordering of rules could easily allow traffic that was previously denied.
Firewall group port associations should be ordered so that the combined ruleset on a port is evaluated in the desired order. |
Neutron allows multiple firewall groups to be attached to ports:
MariaDB [neutron]> describe firewall_group_port_associations_v2;
+-------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+-------+
| firewall_group_id | varchar(36) | YES | MUL | NULL | |
| port_id | varchar(36) | YES | UNI | NULL | |
+-------------------+-------------+------+-----+---------+-------+
2 rows in set (0.001 sec)
However, these associations are not ordered.
We have a use-case where we'd like to define a shared firewall group that tenants can apply in their environments, then add their own, private firewall group above the shared group.
For example, suppose we have an admin owned shared group that allows some RFC1918 space, denies all other RFC1918 networks, then passes all other traffic. A tenant should be able to apply this group, then put their own group above it to allow additional RFC1918 space.
Currently, the group associations will shift on association, so the private group can get popped to below the shared group, effectively blocking traffic that should be allowed.
This can also be a security vulnerability, as the shifting of firewall groups and reordering of rules could easily allow traffic that was previously denied.
Firewall group port associations should be ordered so that the combined ruleset on a port is evaluated in the desired order. |
|
| 2022-06-22 16:23:35 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2022-07-08 12:33:28 |
Lajos Katona |
information type |
Private Security |
Public Security |
|
