forked from acouzens/open5gs
7c14073533
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: https://github.com/advisories/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. |
||
|---|---|---|
| .. | ||
| app | ||
| asn1c | ||
| core | ||
| crypt | ||
| dbi | ||
| diameter | ||
| gtp | ||
| ipfw | ||
| metrics | ||
| nas | ||
| ngap | ||
| pfcp | ||
| proto | ||
| s1ap | ||
| sbi | ||
| sctp | ||
| tun | ||
| meson.build | ||