All - On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit: https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86... We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here: https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately. At this point we are applying for a CVE and will announce that information when we have it. In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias. thanks! donald
All - We have been assigned CVE-2019-5892 for this issue. thanks! donald On Wed, Jan 9, 2019 at 8:34 PM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
All -
On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit:
https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86...
We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here:
https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2
Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately.
At this point we are applying for a CVE and will announce that information when we have it.
In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias.
thanks!
donald
Thank you! You may want to update the page https://frrouting.org/community/security.html пт, 11 Jan. 2019 г., 1:56 Donald Sharp <sharpd@cumulusnetworks.com>:
All -
We have been assigned CVE-2019-5892 for this issue.
thanks!
donald
On Wed, Jan 9, 2019 at 8:34 PM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
All -
On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit:
https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86...
We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here:
https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2
Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately.
At this point we are applying for a CVE and will announce that information when we have it.
In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias.
thanks!
donald
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
I did before I sent this email. Perhaps you should hit f5 donald On Thu, Jan 10, 2019 at 6:01 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Thank you!
You may want to update the page https://frrouting.org/community/security.html
пт, 11 Jan. 2019 г., 1:56 Donald Sharp <sharpd@cumulusnetworks.com>:
All -
We have been assigned CVE-2019-5892 for this issue.
thanks!
donald
On Wed, Jan 9, 2019 at 8:34 PM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
All -
On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit:
https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86...
We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here:
https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2
Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately.
At this point we are applying for a CVE and will announce that information when we have it.
In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias.
thanks!
donald
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
Ah, I did. Probably some caching issues somewhere. Thanks for the job! 11 Jan. 2019 г., 2:04 Donald Sharp <sharpd@cumulusnetworks.com>:
I did before I sent this email. Perhaps you should hit f5
donald
On Thu, Jan 10, 2019 at 6:01 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Thank you!
You may want to update the page
https://frrouting.org/community/security.html
пт, 11 Jan. 2019 г., 1:56 Donald Sharp <sharpd@cumulusnetworks.com>:
All -
We have been assigned CVE-2019-5892 for this issue.
thanks!
donald
On Wed, Jan 9, 2019 at 8:34 PM Donald Sharp <sharpd@cumulusnetworks.com>
wrote:
All -
On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit:
https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a86...
We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here:
https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2
Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately.
At this point we are applying for a CVE and will announce that information when we have it.
In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias.
thanks!
donald
_______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (2)
-
Donald Sharp -
Töma Gavrichenkov