Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
a cryptographic vulnerability in the SUCI decryption routines of Open5GS 5G—specifically Profile B, which uses P-256 (secp256r1) for its elliptic curve routines. If a mobile device user passes a public key within its SUCI that does not correspond to a valid point on the P-256 elliptic curve, the Open5GS UDM will not check the point before running elliptic curve operations with it and returning a response to the mobile device user. If the public key is not checked to be a valid point, an attacker can leverage this behavior to extract the Profile B private key from the UDM, as has been done in other domains (https://owasp.org/www-pdf-archive/Practical_Invalid_Curve_Attacks_on_TLS-ECDH_-_Juraj_Somorovsky.pdf). Note that Profile A is not similarly vulnerable to this, as it is impossible to construct an invalid point on a curve25519 elliptic curve. There was some work that went into developing a practical proof of concept of this kind of attack against free5gc last year; it can be found here: https://www.gsma.com/security/wp-content/uploads/2023/10/0073-invalid_curve.pdf And here is the free5gc security advisory: GHSA-cqvv-r3g3-26rf To mitigate this issue in Open5GS, the public key of the UE must be validated by the UDM prior to use. Adding a validation function such as the following should work: I designed this code based on information from https://crypto.stackexchange.com/questions/90151/verify-that-a-point-belongs-to-secp256r1.
- Loading branch information