| 2024-02-14 08:17:01 |
Frode Nordahl |
bug |
|
|
added bug |
| 2024-02-14 08:17:01 |
Frode Nordahl |
attachment added |
|
0001-ovn-controller-Set-check_tnl_key-on-BFD-tunnel-inter.patch https://bugs.launchpad.net/bugs/2053113/+attachment/5746280/+files/0001-ovn-controller-Set-check_tnl_key-on-BFD-tunnel-inter.patch |
|
| 2024-02-14 08:17:46 |
Frode Nordahl |
bug |
|
|
added subscriber Ubuntu OVN Engineering Team |
| 2024-02-20 06:53:02 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic).
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet received on the tunnel port as being from a privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is non-trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider BFD packets with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is non-trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
|
| 2024-02-20 06:53:19 |
Frode Nordahl |
summary |
Potential DoS vulnerability transmitting BFD packets from VIF |
DoS vulnerability transmitting BFD packets from VIF |
|
| 2024-02-20 07:03:22 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider BFD packets with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is non-trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is non-trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
|
| 2024-02-20 07:03:49 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is non-trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
|
| 2024-02-20 07:05:40 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Investigations so far suggest that setting the `check_tnl_key` option to 'true' would mitigate the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
|
| 2024-02-20 07:06:27 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, as only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
|
| 2024-02-20 07:13:33 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a potential security issue in OVN.
We have initiated conversations with the upstream following their security process on how to handle this issue. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
|
| 2024-02-20 07:16:32 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key.
There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key. There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
|
| 2024-02-20 07:19:01 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key. There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets from a container or virtual machine that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key. There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
|
| 2024-02-20 07:26:12 |
Frode Nordahl |
description |
As part of implementing a overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor health of tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enbale` to 'true' in the `bfd` column.
The tunnel BFD status is also used to select the active chassis for distributed gateway ports for traffic going in and out of the deployment (North/South traffic) among other things.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets from a container or virtual machine that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key. There exists a OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
As part of implementing an overlay network, OVN configures tunnel ports in Open vSwitch (OVS). To monitor the health of the tunnel and remote hypervisor the OVS Bidirectional Forwarding Detection (BFD) functionality is enabled by setting `enable` to 'true' in the `bfd` column.
In addition to monitoring the health of the tunnel, the tunnel BFD status is used to make forwarding decisions that may impact multiple nodes and users of a cluster.
The BFD packets are transmitted in-band in the tunnel, along with other traffic, and in its default configuration, OVS will consider any BFD packet with TTL 255 received on the tunnel as originating from the privileged peer on the other side of the tunnel.
Traffic from unprivileged users connected to a VIF are also transmitted in these tunnels, and it is trivial for a end user of a system using OVS/OVN to transmit BFD packets from a container or virtual machine that will be tunneled through the system with TTL 255.
Fortunately, traffic originating from or destined to a VIF is labeled with a VNI aka. tunnel key. There exists an OVS BFD option called `check_tnl_key`, which makes OVS only consider BFD packets that have a tunnel key of zero.
Setting the `check_tnl_key` option to 'true' mitigates the issue, because the OVN pipeline design ensures only the OVS generated BFD packets would have a tunnel key of zero.
The options on the tunnel ports are however managed by OVN, and any attempt of manually setting them will immediately be reverted, consequently this becomes a security issue in OVN. |
|
| 2024-02-22 09:35:14 |
Frode Nordahl |
attachment removed |
main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5746280/+files/0001-ovn-controller-Set-check_tnl_key-on-BFD-tunnel-inter.patch |
|
|
| 2024-02-22 09:35:47 |
Frode Nordahl |
attachment added |
|
main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5748474/+files/main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch |
|
| 2024-02-22 09:44:12 |
Frode Nordahl |
summary |
DoS vulnerability transmitting BFD packets from VIF |
insufficient validation of incoming BFD |
|
| 2024-02-23 06:47:55 |
Frode Nordahl |
summary |
insufficient validation of incoming BFD |
Insufficient validation of incoming BFD packets. |
|
| 2024-03-05 18:33:58 |
Frode Nordahl |
attachment removed |
main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5748474/+files/main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch |
|
|
| 2024-03-05 18:34:34 |
Frode Nordahl |
attachment added |
|
main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5752936/+files/main-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch |
|
| 2024-03-05 18:35:53 |
Frode Nordahl |
attachment added |
|
branch-22.09-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5752937/+files/branch-22.09-controller-Set-check_tnl_key-for-BFD-on-tunnel-iface.patch |
|
| 2024-03-05 19:25:38 |
Seth Arnold |
cve linked |
|
2024-2182 |
|
| 2024-03-11 13:48:59 |
Marc Deslauriers |
ovn (Ubuntu): assignee |
|
Marc Deslauriers (mdeslaur) |
|
| 2024-03-12 10:39:14 |
Frode Nordahl |
attachment added |
|
zed-lp-2053113.debdiff https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5755247/+files/zed-lp-2053113.debdiff |
|
| 2024-03-12 10:43:13 |
Frode Nordahl |
attachment added |
|
antelope-lp-2053113.debdiff https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2053113/+attachment/5755248/+files/antelope-lp-2053113.debdiff |
|
| 2024-03-12 10:44:51 |
Frode Nordahl |
bug |
|
|
added subscriber James Page |
| 2024-03-12 11:00:21 |
James Page |
bug task added |
|
cloud-archive |
|
| 2024-03-12 11:01:10 |
James Page |
nominated for series |
|
cloud-archive/zed |
|
| 2024-03-12 11:01:10 |
James Page |
bug task added |
|
cloud-archive/zed |
|
| 2024-03-12 11:01:10 |
James Page |
nominated for series |
|
cloud-archive/antelope |
|
| 2024-03-12 11:01:10 |
James Page |
bug task added |
|
cloud-archive/antelope |
|
| 2024-03-12 11:01:23 |
James Page |
cloud-archive: status |
New |
Invalid |
|
| 2024-03-12 11:01:25 |
James Page |
cloud-archive/antelope: importance |
Undecided |
High |
|
| 2024-03-12 11:01:26 |
James Page |
cloud-archive/zed: importance |
Undecided |
High |
|
| 2024-03-12 11:01:29 |
James Page |
cloud-archive/antelope: status |
New |
Triaged |
|
| 2024-03-12 11:01:31 |
James Page |
cloud-archive/zed: status |
New |
Triaged |
|
| 2024-03-13 12:58:58 |
Marc Deslauriers |
ovn (Ubuntu): assignee |
Marc Deslauriers (mdeslaur) |
|
|
| 2024-03-14 16:36:04 |
James Page |
information type |
Private Security |
Public Security |
|
| 2024-03-14 16:39:56 |
James Page |
ovn (Ubuntu): status |
Triaged |
Fix Released |
|
| 2024-03-18 09:25:15 |
James Page |
cloud-archive/zed: status |
Triaged |
Fix Committed |
|
| 2024-03-18 09:25:16 |
James Page |
tags |
|
verification-zed-needed |
|
| 2024-03-18 09:25:51 |
James Page |
cloud-archive/antelope: status |
Triaged |
Fix Committed |
|
| 2024-03-18 09:25:52 |
James Page |
tags |
verification-zed-needed |
verification-antelope-needed verification-zed-needed |
|
| 2024-03-21 07:30:25 |
Chris Valean |
bug |
|
|
added subscriber Chris Valean |
| 2024-03-21 07:48:18 |
James Page |
cloud-archive: status |
Invalid |
Fix Committed |
|
| 2024-03-21 11:23:58 |
James Page |
nominated for series |
|
cloud-archive/ovn-22.03 |
|
| 2024-03-21 11:23:58 |
James Page |
bug task added |
|
cloud-archive/ovn-22.03 |
|
| 2024-03-21 11:24:03 |
James Page |
cloud-archive/ovn-22.03: status |
New |
Fix Committed |
|
| 2024-03-21 11:24:06 |
James Page |
cloud-archive/ovn-22.03: importance |
Undecided |
High |
|
| 2024-03-22 09:19:21 |
James Page |
cloud-archive: status |
Fix Committed |
Fix Released |
|
