The clang scan-build procedure
```
Assume Ubuntu docker container with open5gs mounted to /src.
Assume these tools are installed to docker container:
sudo apt install -y clang-tools clang
For easy reference to clang scan-build tool:
Put normal open5gs build procedure into a file called /src/build
=======================
Inside docker container:
=======================
export CLANG_OUT_DIR=/src/scan_build_results
scan-build -disable-checker deadcode.DeadStores --override-compiler --keep-going
--exclude subprojects --exclude tests --exclude lib/asn1c -maxloop 200 -o $CLANG_OUT_DIR -plist-html /src/build 2>&1 | tee /src/logclang.txt
=======================
Results:
=======================
Results are in html format in $CLANG_OUT_DIR - top level index.html
```
Note that in this analysis the following suppressions were assumed:
- no deadcode.DeadStores analysis since those are not functional findings
- exclude lib/asn1c for reason that is outside of open5gs control
- exclude tests for reason that those are not functional findings
- exclude subprojects since those are outside of open5gs control
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.
o Generate the private key as below.
$ openssl genpkey -algorithm X25519 -out /etc/open5gs/hnet/curve25519-1.key
$ openssl ecparam -name prime256v1 -genkey -conv_form compressed -out /etc/open5gs/hnet/secp256r1-2.key
o The private and public keys can be viewed with the command.
The public key is used when creating the SIM.
$ openssl pkey -in /etc/open5gs/hnet/curve25519-1.key -text
$ openssl ec -in /etc/open5gs/hnet/secp256r1-2.key -conv_form compressed -text
In ausf/udm.yaml
hnet:
o Home network public key identifier(PKI) value : 1
Protection scheme identifier : ECIES scheme profile A
- id: 1
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 2
Protection scheme identifier : ECIES scheme profile B
- id: 2
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
o Home network public key identifier(PKI) value : 3
Protection scheme identifier : ECIES scheme profile A
- id: 3
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 4
Protection scheme identifier : ECIES scheme profile B
- id: 4
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
Related to #1779
