BGP Under Pressure

Protocol Fuzzing in action

When it comes to keeping the internet running smoothly, the Border Gateway Protocol (BGP) is absolutely essential. BGP is the backbone of how routers share the best paths for data across different networks. Given its importance, even small bugs can cause big headaches. That’s why we’ve been busy using protocol fuzzing—a technique where we throw all kinds of unexpected, malformed data at the system—to make sure everything is rock solid.

The Internet’s smart routing system

BGP uses TCP to maintain reliable communication between routers. It continuously updates its routing tables based on policy rules and network conditions, making adjustments when links go down or traffic patterns shift. This dynamic process means that even a small misconfiguration or bug in BGP can lead to widespread routing issues, underscoring its critical role in our digital infrastructure.

In essence, BGP is like a highly specialized traffic director that keeps our internet running smoothly, balancing efficiency with resilience, and adapting in real time to ensure that every data packet finds its way home.

Why Protocol Fuzzing matters

Think of protocol fuzzing as a rigorous workout for your code. By stressing the system with a variety of unpredictable inputs, you expose vulnerabilities and edge cases that might otherwise remain hidden. This process is key to uncovering those subtle bugs that only show up under unusual circumstances. While working on our new protocol fuzzer, we discovered two noteworthy bugs in the Holo BGP library. Although this library isn’t one of ours, our collaboration with its main developer has led to a transparent discussion about these issues—even if it means not assigning a CVE or issuing a security advisory, for fear of impacting the library’s reputation.

A Chat with the main developer

We had a productive conversation with the main developer of the Holo BGP library regarding our findings. We suggested that assigning a CVE ID and issuing a security advisory could benefit the community by highlighting the importance of rigorous testing and helping others avoid similar pitfalls. However, the decision was made to hold off on that route, as there was concern that a public security advisory might give a bad reputation to the library. This experience underscores the often delicate balance between transparency, community benefit, and the perception of a project.

The bugs

Bug #1: Missing validation in Message decoding

Our first bug came from an unexpected place. In the normal operation of the library, the function Message::get_message_len() makes sure that the incoming data forms a complete BGP message before it’s processed. However, the unit tests didn’t include this crucial validation, which meant that sometimes, malformed messages were slipping through. This was problematic because the decoding function assumed everything was perfectly sized and formatted.

Bug #2: Handling NLRI in UPDATE Messages

The second bug was all about handling UPDATE messages correctly. UPDATE messages are used in BGP to update routing information, and sometimes they include an NLRI field with network prefixes. According to BGP standards, if an UPDATE message has an NLRI field but is missing the NEXT_HOP attribute (which tells the router where to send traffic), the NLRI prefixes should be ignored.

Impact

These bugs aren’t just minor glitches—they could have serious implications, like paving the way for Denial-of-Service (DoS) attacks. If a malformed BGP message slips through due to insufficient checks, it might force the system into unstable states, causing crashes or performance degradation. In the worst-case scenario, this vulnerability could be exploited to overwhelm routers, leading to widespread network disruptions. By using fuzzing to expose these edge cases, we’re not only refining the code but also bolstering the network’s defenses against potential, critical DoS attacks.

What we learned

Working through these bugs was an eye-opening experience, and it taught us several valuable lessons:

  • Embrace Fuzzing: Fuzzing is an invaluable technique for uncovering those hard-to-find edge cases. By bombarding your protocol with unexpected and varied inputs, fuzzing exposes vulnerabilities that standard testing might miss, ensuring that even the rarest scenarios are handled gracefully.
  • Stick to the Specs: Adhering closely to protocol specifications is essential. Deviations, even if minor, can lead to unexpected behavior.
  • Open Communication: Collaborating with the maintainers of external libraries can lead to valuable insights, even when tough decisions are made regarding public disclosures.

Even though the Holo BGP library isn’t our project, we believe that sharing these insights will help improve the overall quality and security of network protocol implementations. Our hope is that our work encourages others to keep testing rigorously and to engage in open discussions about how to make our digital infrastructure more robust.

For more details, check out the Holo repository and the specific issues:


Nabih Benazzouz / @Raefko

About Us

Founded in 2021 and headquartered in Paris, FuzzingLabs is a cybersecurity startup specializing in vulnerability research, fuzzing, and blockchain security. We combine cutting-edge research with hands-on expertise to secure some of the most critical components in the blockchain ecosystem.

Contact us for an audit or long term partnership!

Get Your Free Security Quote!

Let’s work together to ensure your peace of mind.

Keep in touch with us !

email

contact@fuzzinglabs.com

X (Twitter)

@FuzzingLabs

Github

FuzzingLabs

LinkedIn

FuzzingLabs

email

contact@fuzzinglabs.com

X (Twitter)

@FuzzingLabs

Github

FuzzingLabs

LinkedIn

FuzzingLabs