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
FRR users, We are the research team running the experiment that triggered this issue (a description of the experiment is available [A]). We have postponed our experiment schedule until Jan. 23rd to allow for a two-week upgrade window [B]. Please let us know if you have any feedback. [A] https://goo.gl/AFR1Cn [B] https://goo.gl/nJhmx1 -- Amir Herzberg, University of Connecticut Ethan Katz-Bassett, Columbia University Haya Shulman, Fraunhofer SIT Ítalo Cunha, Universidade Federal de Minas Gerais Michael Schapira, Hebrew University of Jerusalem Tomas Hlavacek, Fraunhofer SIT Yossi Gilad, MIT On Wed, Jan 9, 2019 at 8:36 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
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Hi all,This is a reminder that this experiment is scheduled for tomorrow (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a BGP attribute of type 0xff (reserved for development) between 14:00 and 14:15 GMT. On Thu, Jan 10, 2019 at 12:08 PM Italo Cunha <cunha@dcc.ufmg.br> wrote:
FRR users,
We are the research team running the experiment that triggered this issue (a description of the experiment is available [A]). We have postponed our experiment schedule until Jan. 23rd to allow for a two-week upgrade window [B]. Please let us know if you have any feedback.
[A] https://goo.gl/AFR1Cn [B] https://goo.gl/nJhmx1
-- Amir Herzberg, University of Connecticut Ethan Katz-Bassett, Columbia University Haya Shulman, Fraunhofer SIT Ítalo Cunha, Universidade Federal de Minas Gerais Michael Schapira, Hebrew University of Jerusalem Tomas Hlavacek, Fraunhofer SIT Yossi Gilad, MIT
On Wed, Jan 9, 2019 at 8:36 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
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Due to new incident reports, these experiments have been canceled permanently. On Tue, Jan 22, 2019 at 9:19 AM Italo Cunha <cunha@dcc.ufmg.br> wrote:
Hi all,This is a reminder that this experiment is scheduled for tomorrow (Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a BGP attribute of type 0xff (reserved for development) between 14:00 and 14:15 GMT. On Thu, Jan 10, 2019 at 12:08 PM Italo Cunha <cunha@dcc.ufmg.br> wrote:
FRR users,
We are the research team running the experiment that triggered this issue (a description of the experiment is available [A]). We have postponed our experiment schedule until Jan. 23rd to allow for a two-week upgrade window [B]. Please let us know if you have any feedback.
[A] https://goo.gl/AFR1Cn [B] https://goo.gl/nJhmx1
-- Amir Herzberg, University of Connecticut Ethan Katz-Bassett, Columbia University Haya Shulman, Fraunhofer SIT Ítalo Cunha, Universidade Federal de Minas Gerais Michael Schapira, Hebrew University of Jerusalem Tomas Hlavacek, Fraunhofer SIT Yossi Gilad, MIT
On Wed, Jan 9, 2019 at 8:36 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
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
On 23/01/2019 17:21, Italo Cunha wrote:
Due to new incident reports, these experiments have been canceled permanently.
Related to FRR or something different? -- Tim Bray Technology Director, ProVu Communications Ltd, Huddersfield, UK. http://www.provu.co.uk/ Phone: +44 1484 840048 IP Telephones, Drop shipping, pre-configuration, XML orders ***** If it is important, just phone *****
On 23/01/2019 18:36, Tim Bray wrote:
On 23/01/2019 17:21, Italo Cunha wrote:
Due to new incident reports, these experiments have been canceled permanently.
Related to FRR or something different?
*is a few of the 'new incident reports' posted publicly available anywhere? -Christoffer
On 23 January 2019 18:02:01 GMT, Christoffer Hansen <christoffer@netravnen.de> wrote:
On 23/01/2019 18:36, Tim Bray wrote:
On 23/01/2019 17:21, Italo Cunha wrote:
Due to new incident reports, these experiments have been canceled permanently.
Related to FRR or something different?
*is a few of the 'new incident reports' posted publicly available anywhere?
-Christoffer
Hi Christoffer, Its not detailed but there is at least one operator moaning on NANOG (presumably not FRR related): https://mailman.nanog.org/pipermail/nanog/2019-January/099142.html Cheers, James.
On 23/01/2019 19:31, James Bensley wrote:
Its not detailed but there is at least one operator moaning on NANOG (presumably not FRR related): https://mailman.nanog.org/pipermail/nanog/2019-January/099142.html
Sadly $person reporting back is not very enlightening about details. -Christoffer
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 (6)
-
Christoffer Hansen -
Donald Sharp -
Italo Cunha -
James Bensley -
Tim Bray -
Töma Gavrichenkov