FRR: BGP Session abort on bad attribute 255
A vulnerability exists in the BGP daemon of FRR where a malformed BGP UPDATE packet with an attribute 255 (reserved for experimental) can cause the BGP peering session to flap.
Jan 10, 2019
FRRouting “FRR” (bgpd) on any platforms if it is configured (during compile time) with
--enable-vnc. This includes packages released by the FRR team and FreeBSD Ports
- FRR 2.x
- FRR 3.0 - 3.0.3
- FRR 4.0
- FRR 5.0 - 5.0.1
- FRR 6.0 - 6.0.1
FRR versions above do not conform to RFC 7606 (Revised Error Handling for BGP UPDATE Messages). Additionally, the VNC code (see http://docs.frrouting.org/en/latest/vnc.html) was using BGP attribute 255 which is reserved for experimental use. The BGP attribute was never standardized and was accidently left enabled.
The Disco experiment ( https://mailman.nanog.org/pipermail/nanog/2018-December/098458.html ) which was run this early January, used attribute 255 for it’s tests. While all other routers forwarded this transitive attribute (as it was unknown to them), FRR tried to parse it as VNC but failed and as such closed the BGP session (as specified in RFC 4271 Page 74, event 28). The closing of the session in case of an invalid attribute was a requirement of the BGP standard before RFC 7606 changed the behaviour.
There is no compromise of data, but this will lead to a potential denial of service as unrelated routes will be withdrawn from the routing table.
CVSS v3 Base Score: 4.1
For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L/E:F/RL:O/RC:C
Rebuild with ‘–disable-bgp-vnc’ or upgrade to a fixed version
Public known and discovered by a research project on the Internet (‘Disco experiment’).
- FRR before 2.0.2
- FRR 3.0 before 3.0.2
- FRR 3.1 (Development git master) before 8 November 2017
- Cumulus Linux FRR (built with VNC disabled)
- Any other version built with VNC disabled. To check if your version and if it has bgp-vnc enabled, use the either the vtysh command
show version(if FRR is running) or
bgpd --versionif FRR is not running and look for “bgp-vnc” in the output (example:
--enable-bgp-vnc=yesor similar). If there is no output containing “bgp-vnc”, then vnc is disabled, and that version is not vulnerable.
On Linux with Redhat / Debian Packages:
- FRR 3.0.4 for FRR versions up to 3.0.3
- FRR 4.0.1 for FRR version 4.0
- FRR 5.0.2 for FRR version 5.0 and 5.0.1
- FRR 6.0.2 for FRR version 6.0 and 6.0.1
Update ports and upgrade FRR afterwards. Verify to be on a fixed version (3.0.4, 4.0.1, 5.0.2, 6.0.2) after upgrade
Linux with snap packages:
Upgrade Snap package
Contact your vendor or rebuild source with the new versions. As an alternative, if VNC is not used, a rebuild of the same version with `–disable-vnc’ in the configure options (during build time) can be used as well
Updated packages are available at https://github.com/FRRouting/frr/releases and as source on GIT
Document Revision History:
1.0 10 Januar 2019 – Initial version
The issue was uncovered by the ‘Disco’ experiment on the live Internet.
- Update announcement: https://lists.frrouting.org/pipermail/frog/2019-January/000404.html
- Issue tracking to implement RFC 7606: https://github.com/FRRouting/frr/issues/3583
- FRR Security Information https://frrouting.org/security
- Do you have Questions? Questions regarding this advisory should go to email@example.com