Compliance Impact

The vulnerability in free5GC's UDR component causes a denial-of-service (DoS) condition by allowing repeated panics and crashes through a nil-pointer dereference in an authenticated DELETE endpoint. However, it does not affect confidentiality or persistent integrity of data.

Since the primary impact is reduced availability without compromising data confidentiality or integrity, the vulnerability mainly poses a risk to service availability rather than data protection requirements under standards like GDPR or HIPAA.

Therefore, while the vulnerability could lead to service disruptions, it does not directly cause violations related to data privacy or protection mandates in these regulations.

Useful 0 Not Useful 0

Executive Summary

The vulnerability exists in free5GC's UDR component in the DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions endpoint. When a request is made with a missing or invalid subscription ID (subsId), the handler checks for the subscription's existence and sets a 404 response if not found, but it fails to return immediately. Instead, it continues and dereferences the missing subscription entry, causing a nil-pointer dereference and a panic. This panic is converted into an HTTP 500 error by the Gin recovery mechanism, but the endpoint remains vulnerable to repeated panics.

The issue requires a valid authenticated request with a proper OAuth2 token and a preparatory EE-subscription create. The root cause is improper error handling where the code does not return after detecting a missing subscription ID before accessing its properties.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to denial-of-service (DoS) conditions on the free5GC UDR service. An attacker with a valid OAuth2 token can repeatedly trigger the panic by sending malicious DELETE requests with invalid subscription IDs, causing the service to crash or return HTTP 500 errors.

The impact is primarily on availability, as the repeated panics consume CPU and logging resources, potentially degrading service performance or causing outages. There is no impact on confidentiality or persistent integrity.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring the UDR service for repeated HTTP 500 errors on the DELETE endpoint /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions after authenticated requests.

Specifically, if you observe repeated panics or crashes in the UDR logs triggered by DELETE requests with invalid or missing subscription IDs (subsId), it indicates the presence of this vulnerability.

Since the vulnerability requires an authenticated request with a valid OAuth2 token (nudr-dr scope), you can attempt to reproduce the issue in a controlled environment by sending authenticated DELETE requests with non-existent subsId values after creating an EE-subscription.

Suggested commands to detect the vulnerability include using curl or similar HTTP clients to send authenticated DELETE requests and monitoring logs for HTTP 500 responses and panic stack traces.

• Example curl command to test the vulnerable endpoint (replace placeholders accordingly):
• curl -X DELETE "https://<free5gc-udr-host>/subscription-data/<ueId>/<servingPlmnId>/ee-subscriptions/<invalid-subsId>/amf-subscriptions" -H "Authorization: Bearer <valid_oauth2_token>" -v
• Monitor the UDR logs for panic or crash messages following such requests.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade the free5GC UDR component to version 4.2.2 or later, where this vulnerability has been fixed.

The fix includes proper error handling in the DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions handler to prevent nil-pointer dereferences and panics.

Until the upgrade can be applied, you should restrict access to the vulnerable endpoint by limiting authenticated users who can send DELETE requests with the nudr-dr scope.

Additionally, monitor the UDR service for repeated panics or crashes and consider implementing rate limiting or alerting on suspicious DELETE requests to reduce the risk of denial-of-service.

Useful 0 Not Useful 0