By Jonathan Knudsen
The Synopsys Cybersecurity Research Center (CyRC) recently published a vulnerability advisory related to Open5GS, which is full of dense technical details. But what does all this mean for organizations? What is the potential impact? To answer this, let’s take a step back.
Learn a little more about 5G
Let’s start by talking about the software itself. Open5GS is an open source implementation of 5G, which is the current generation of network technology used by mobile phones. It encompasses all the internal elements of the networks that carry voice and data around the world.
5G is complicated. If you’ve ever seen a diagram of a 5G network, there’s a wealth of boxes and lines connecting them. Each box has a specific purpose, some for authorization, some for billing, some for controlling what data goes where. The enclosures communicate with each other using protocols. A network protocol is simply a set of rules about what data will be exchanged and how, much like the rules of a conversation between two pieces of software.
As with any complex software, it feels like a small miracle just to get it to work. But safety is just as important. You want the system to work, but you also want it to be hard to attack. Implementing security testing during development helps locate vulnerabilities which can then be patched before release.
Now, what is Open5GS?
Open5GS is an open source implementation of the 5G specifications. It is used as a connectivity test tool by some companies related to mobile telecommunications. For example, ng-voice is a sponsor of Open5GS. As described in the Open5GS documentation, it can be used to build a private network. The support page says it’s under AGPL-3.0 and commercially licensed, which means it could be deployed commercially as a 5G core network.
Fuzzing and its impact on delivery
Fuzz, or fuzzing, testing is particularly well suited to network protocol testing. Fuzzing means providing deliberately malformed and unexpected inputs to software and checking to see if something is wrong. Attackers often use fuzzing because it is a very effective method of locating vulnerabilities in software.
A generational fuzzer, like Defensics, already knows all the rules of protocol. He knows which messages will be exchanged and what their content should be. Because it knows what everything should look like, it’s very good at generating entries that are mostly correct but wrong in a specific way.
About Denial of Service
Synopsys CyRC researcher Qiang Li used Defensics to locate a vulnerability in one of the components (UPF) of Open5GS. As the advisory states, a malformed protocol message can cause a process to hang, disrupting a component of the 5G network. When something is no longer available, we call it a denial of service, but really it just means that something has broken.
What are the consequences?
If the UPF component of the network is disabled, end users (people) cannot use the network with their phones. Neither data nor calls will work. While the attack is simple to launch, the real challenge for an attacker would be finding a suitable insertion point, i.e. being able to access the core of a 5G network in the first place. Security should always be implemented in layers, so we expect 5G network components to be deployed in a way that is difficult for an attacker to access.
About the vulnerability
Open5GS is written in the C programming language. The vulnerability we discovered is a classic buffer overflow vulnerability, in which too much data is written to too little memory. An attacker might be able to exploit this vulnerability to run their own code on the 5G network, possibly pivoting to compromise other network components, eavesdrop on data, steal sensitive information, or cause other types of problems.
Vulnerabilities like this can be a serious problem if they lie dormant in released software. By incorporating fuzzing and other security testing tools into a secure software development lifecycle, development teams can find and fix vulnerabilities before releasing software. This reduces risk for development teams and their downstream customers.
What does all this mean?
Software security continues to be of critical importance. In a world where software itself is the critical infrastructure for all other critical infrastructure, security must be built into software, infused into every development phase. Just as no one would consider designing and building an aircraft without thinking about safety at every phase, no one should design and build software without thinking about safety at every phase.
(About the Author: Jonathan Knudsen is the Head of Global Research at Synopsys Cybersecurity Research Center and the views expressed here are his own, with the publisher in no way responsible for them)