Segmentation fault caused by malformed BGP packet
After running into trouble with bird 1.2.3 trying to display 32 bit AS numbers (show route all resulted in a segmentation fault), we decided to upgrade to 1.3.1. Unfortunately 1.3.1 crashed even sooner than 1.2.3. One of the logs looks like this: bird: UFO_4_0_bgp > added 1.0.49.0/24 via 1.82.98.2 on ppp-UFO_4-0 Segmentation fault Disabling this peer fixed the crashes, enabling the peer brought them back. After some investigation, it turned out that this BGP peer sends an ORIGIN attribute even with BGP packets that only withdraw a route; bird does not do this. Changing the peer's sourcecode to not send the ORIGIN attribute for withdrawn routes, fixed the crashes in bird. The segmentation fault suggests that there is a security issue in bird's BGP update handling. Attached is a pcap dump file containing a BGP session. 1.82.98.27 is the bird router. Frame 30 contains a withdrawl update sent by bird, frame 31 contains the first withdrawl received by bird (offset 0x0525), which also happens to be the next UPDATE after an update regarding 1.0.49.0/24, which is shown in the log just before bird crashes. -- Ivo
On Mon, May 30, 2011 at 05:45:20PM +0200, Ivo Smits wrote:
After running into trouble with bird 1.2.3 trying to display 32 bit AS numbers (show route all resulted in a segmentation fault), we decided to upgrade to 1.3.1. Unfortunately 1.3.1 crashed even sooner than 1.2.3. One of the logs looks like this: bird: UFO_4_0_bgp > added 1.0.49.0/24 via 1.82.98.2 on ppp-UFO_4-0 Segmentation fault
Disabling this peer fixed the crashes, enabling the peer brought them back. After some investigation, it turned out that this BGP peer sends an ORIGIN attribute even with BGP packets that only withdraw a route; bird does not do this. Changing the peer's sourcecode to not send the ORIGIN attribute for withdrawn routes, fixed the crashes in bird.
Thanks for the bugreport. Could you try the attached patch? (But this bug is even in 1.2.3, not sure why it didn't show before.) -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Op 31-5-2011 2:00, Ondrej Zajicek schreef:
On Mon, May 30, 2011 at 05:45:20PM +0200, Ivo Smits wrote:
... Disabling this peer fixed the crashes, enabling the peer brought them back. After some investigation, it turned out that this BGP peer sends an ORIGIN attribute even with BGP packets that only withdraw a route; bird does not do this. Changing the peer's sourcecode to not send the ORIGIN attribute for withdrawn routes, fixed the crashes in bird. Thanks for the bugreport. Could you try the attached patch? (But this bug is even in 1.2.3, not sure why it didn't show before.) Thanks for the quick fix. We have tested the patch and it appears to work - bird no longer crashes.
The 'non-standard' BGP node has been peered with at least bird 1.2.3 and 1.2.5, without any problems.
On Tue, May 31, 2011 at 01:34:15PM +0200, Ivo Smits wrote:
Op 31-5-2011 2:00, Ondrej Zajicek schreef:
On Mon, May 30, 2011 at 05:45:20PM +0200, Ivo Smits wrote:
... Disabling this peer fixed the crashes, enabling the peer brought them back. After some investigation, it turned out that this BGP peer sends an ORIGIN attribute even with BGP packets that only withdraw a route; bird does not do this. Changing the peer's sourcecode to not send the ORIGIN attribute for withdrawn routes, fixed the crashes in bird. Thanks for the bugreport. Could you try the attached patch? (But this bug is even in 1.2.3, not sure why it didn't show before.) Thanks for the quick fix. We have tested the patch and it appears to work - bird no longer crashes.
The 'non-standard' BGP node has been peered with at least bird 1.2.3 and 1.2.5, without any problems.
After a second look it is clear that the bug was introduced in 1.3.0. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Ivo Smits -
Ondrej Zajicek