While testing the free5gc AMF for some NAS basic security features and fuzzing, I could trigger several crashes, while sending malformed NAS message. This means those issues are relatively exposed as they can be trigger by any 5G subscriber, in the principle.
Here, all memory issues due to mishandled NAS messages and IE structures are caught by the GO memory runtime, which protects the binary for potential exploitable cases.
To Reproduce
No easy way to reproduce with available open-source tools. A modification of a gNB / UE emulator can be done to send malformed NAS messages.
Expected behavior
An attacker could leverage this to cause excessive downtime and resource consumption against a pool of AMF. As much as possible, crashing the binary should be avoided when decoding subscriber's provided NAS signaling message. During the decoding process, verifications should be made to ensure the messages are valid ; in case of invalid or malformed messages, it should be dropped and the corresponding UE context should be deleted.
Environment (please complete the following information):
free5GC Version: v3.0.5
OS: Ubuntu 20.04
Kernel version: 5.4.0-62-generic
go version: go1.14.4 linux/amd64
Trace File
Configuration File
No specific configuration is required.
PCAP File
No specific pcap file is provided. If required, pcap corresponding some specific crashes can be provided.
Log File
The following part lists some GOLANG stacktraces and corresponding malformed NAS and IE cases.
When a IE with TLV structure (type 4 or 6) is provided, but without the expected length, free5gc crashes, e.g. with an empty 5GSID:
Finally, it seems using any kind of LADN Indicator within the 5G Registration Request message leads to the AMF getting stuck, consuming CPU and memory forever, and not responding on the SCTP socket anymore. The process gets finally killed by the Linux kernel.
For instance sending a NAS Registration Request with the following LADN Indicator structure:
[4410188.716481] Out of memory: Killed process 1955374 (amf) total-vm:19664848kB, anon-rss:7375620kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:22604kB oom_score_adj:0
[4410189.087583] oom_reaper: reaped process 1955374 (amf), now anon-rss:40kB, file-rss:0kB, shmem-rss:0kB
The text was updated successfully, but these errors were encountered:
Describe the bug
While testing the free5gc AMF for some NAS basic security features and fuzzing, I could trigger several crashes, while sending malformed NAS message. This means those issues are relatively exposed as they can be trigger by any 5G subscriber, in the principle.
Here, all memory issues due to mishandled NAS messages and IE structures are caught by the GO memory runtime, which protects the binary for potential exploitable cases.
To Reproduce
No easy way to reproduce with available open-source tools. A modification of a gNB / UE emulator can be done to send malformed NAS messages.
Expected behavior
An attacker could leverage this to cause excessive downtime and resource consumption against a pool of AMF. As much as possible, crashing the binary should be avoided when decoding subscriber's provided NAS signaling message. During the decoding process, verifications should be made to ensure the messages are valid ; in case of invalid or malformed messages, it should be dropped and the corresponding UE context should be deleted.
Environment (please complete the following information):
Trace File
Configuration File
No specific configuration is required.
PCAP File
No specific pcap file is provided. If required, pcap corresponding some specific crashes can be provided.
Log File
The following part lists some GOLANG stacktraces and corresponding malformed NAS and IE cases.
When a IE with TLV structure (type 4 or 6) is provided, but without the expected length, free5gc crashes, e.g. with an empty 5GSID:
Or a UE Security Capabilities:
This happens also with an oversized IE value, e.g. with 5G MM Capabilities:
Providing malformed 5GSID can trigger several additional crashes in the `GutiToString` or `SuciToString` functions:
or
or
Finally, it seems using any kind of LADN Indicator within the 5G Registration Request message leads to the AMF getting stuck, consuming CPU and memory forever, and not responding on the SCTP socket anymore. The process gets finally killed by the Linux kernel.
For instance sending a NAS Registration Request with the following LADN Indicator structure:
Leads to this situation:
The text was updated successfully, but these errors were encountered: