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. |
||
---|---|---|
.. | ||
openssl | ||
curve25519-donna.c | ||
ecc.c | ||
ecc.h | ||
kasumi.c | ||
kasumi.h | ||
meson.build | ||
milenage.c | ||
milenage.h | ||
ogs-aes-cmac.c | ||
ogs-aes-cmac.h | ||
ogs-aes.c | ||
ogs-aes.h | ||
ogs-base64.c | ||
ogs-base64.h | ||
ogs-crypt.h | ||
ogs-kdf.c | ||
ogs-kdf.h | ||
ogs-sha1-hmac.c | ||
ogs-sha1-hmac.h | ||
ogs-sha1.c | ||
ogs-sha1.h | ||
ogs-sha2-hmac.c | ||
ogs-sha2-hmac.h | ||
ogs-sha2.c | ||
ogs-sha2.h | ||
snow-3g.c | ||
snow-3g.h | ||
zuc.c | ||
zuc.h |