In case that mapped HPLMN SST was not set by the UE in the request to
Establish PDU Session, AMF/SMF would assume it is set to 0 (since the
recent change to allow SST value 0).
3GPP TS 23.003: 28.4.2 Format of the S-NSSAI
The SST field may have standardized and non-standardized values. Values
0 to 127 belong to the standardized SST range and they are defined in
3GPP TS 23.501 [119]. Values 128 to 255 belong to the Operator-specific
range.
- Modified the `ogs_nas_qos_rule_s` structure to increase the size
of the `identifier` field from 4 bits to 6 bits in order to allow
for larger QoS Flow Identifiers (QFI).
- Adjusted the URR access logic in `upf_sess_urr_acc_add` to prevent
out-of-bounds access by ensuring the URR ID is within the valid range.
Resolved a heap-buffer-overflow issue
in the ogs_nas_5gs_decode_registration_request function caused
by improper handling of empty pkbuf.
Added validation checks to ensure pkbuf size is non-zero
before accessing its data.
Reviewed similar patterns in other decoding functions
to prevent similar vulnerabilities.
1. Set packet filter identifier values to 0 when the UE requests to:
- Create new QoS rule
- Modify existing QoS rule and replace all packet filters
- Modify existing QoS rule and add packet filters - As specified in TS24.501, section 9.11.4.13, Table 9.11.4.13.1.
2. Revise QoS rule modification logic:
- Instead of replacing packet filters based on their identifiers (EPC approach), update the implementation to delete all existing packet filters within the QoS rule and add new ones.
- This ensures that when modifying an existing QoS rule to replace all packet filters, the packet filters are correctly reset and updated per 5G Core requirements.
Implement Control Message handling between V-SMF and H-SMF
during Home Routed Roaming process
Completed the implementation of control messages exchanged
between V-SMF and H-SMF as part of the Home Routed Roaming process
* [SBI] Handle and store AMF info
* [SBI] Add "target GUAMI" discovery option
* [SBI] Handle UeContextTransfer request and response messages
* [AMF] Handle NF discovery from AMF to AMF
* [AMF] Add UE Context Transfer Request/Response from AMF to AMF
* [SCP] Handle UeContextTransfer
* Follow-up on #3052
* [AMF] force authentication after 'Ue context transfer' for now
* [AMF] force authentication after 'Ue context transfer' for now
---------
Co-authored-by: Sukchan Lee <acetcom@gmail.com>
1. Reachable assertion in ogs_nas_5gmm_decode
Location: lib/nas/5gs/decoder.c:4445
```c
int ogs_nas_5gmm_decode(ogs_nas_5gs_message_t *message, ogs_pkbuf_t *pkbuf)
{
int size = 0;
int decoded = 0;
ogs_assert(pkbuf);
ogs_assert(pkbuf->data);
ogs_assert(pkbuf->len);
```
When a NAS payload is received over `src/amf/context.c:1675`NGAP that has no data, the ogs_assert(pkbuf->len) assertion will be triggered.
2.Reachable assertion in ogs_nas_emm_decode
```
int ogs_nas_emm_decode(ogs_nas_eps_message_t *message, ogs_pkbuf_t *pkbuf)
{
int size = 0;
int decoded = 0;
ogs_assert(pkbuf);
ogs_assert(pkbuf->data);
ogs_assert(pkbuf->len);
```
Nearly identical to (1), but for LTE.
3. Reachable assertion in nas_eps_send_emm_to_esm
```
int nas_eps_send_emm_to_esm(mme_ue_t *mme_ue,
ogs_nas_esm_message_container_t *esm_message_container)
{
int rv;
ogs_pkbuf_t *esmbuf = NULL;
if (!mme_ue_cycle(mme_ue)) {
ogs_error("UE(mme-ue) context has already been removed");
return OGS_NOTFOUND;
}
ogs_assert(esm_message_container);
ogs_assert(esm_message_container->length);
```
The ESM message payload may be 0-length, as the length is determined by a field in the NAS payload (which can be chosen arbitrarily by an attacker). This leads to the length assertion above being triggered.
5. Reachable assertion and incorrect hash calculation in ogs_kdf_hash_mme
```
void ogs_kdf_hash_mme(const uint8_t *message, uint8_t message_len, uint8_t *hash_mme)
{
uint8_t key[32];
uint8_t output[OGS_SHA256_DIGEST_SIZE];
ogs_assert(message);
ogs_assert(message_len);
ogs_assert(hash_mme);
memset(key, 0, 32);
ogs_hmac_sha256(key, 32, message, message_len,
output, OGS_SHA256_DIGEST_SIZE);
memcpy(hash_mme, output+24, OGS_HASH_MME_LEN);
}
```
When handling NAS attach requests or TAU requests, the ogs_kdf_hash_mme function is passed the NAS payload. However, the length field is represented as an unsigned 8-bit integer, which the passed length of the packet may overflow. This leads to the passed value being truncated.
When the passed value is a multiple of 256, the above assertion (ogs_assert(message_len)) is triggered. Otherwise, the hash is computed on only the first n bits of the message (where n = actual_message_len % 256).
There was a memory problem in the encryption using snow_3g_f8,
so AMF/MME crashed.
To solve this problem, we used the snow-3g encryption library
created as below.
https://github.com/rcatolino/libressl-snow3g
However, it seems that this library cannot be used to create
integrity hash like snow_3g_f8.
So, we decided to keep both snow-3g libraries for the time being.
1. lib/crypt/snow3g* : for INTEGRITY (NIA1, EIA1)
2. lib/crypt/openssl/snow3g* : for ENCRYPTION (NEA1, EEA1)
NAS, GTP, PFCP, SBI, all except S1AP/NGAP use x1000 multiplier for Kbps, Mbps, Gbps ... etc.
From now on in WebUI all units also use a multiplier of x1000.
The improved algorithm better handles some odd bitrates.
With the current version, the bitrates 63 Kbps and 65 Kbps would get
converted into 48 Kbps (unit 16 Kbps x 3) and 64 Kbps (unit 64 Kbps x
1).
Especially in the first case, the conversion error is quite signicant.
Current version tries to find the biggest 'unit', while the 'value' is
still above 0.
With the updated version, the algorithm tries to find the 'unit' low
enough, that the resulting 'value' can still fit into the 16-bit space
without overflow.
From the OpenAPI document,TS29571_CommonData.yaml : BitRate
String representing a bit rate; the prefixes follow the standard symbols from The International
System of Units, and represent x1000 multipliers, with the exception that prefix "K" is
used to represent the standard symbol "k".
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
When a UE that requests slices tries to connect and there are no slices configured, the reject message is:
5GMM cause = 0x7 (5GS Services not allowed)
however it should be:
5GMM cause = 0x3e (No network slices available)
All 5GMM cause value in reject message is reviewed in this commit
For null protection scheme the SUCI needs to be BCD encoded. Whereas for
protection scheme profiles A and B the SUCI needs to be converted from
hexadecimal to ASCII.
This still needs the support for protection schemes A and B in UDM to
work.
The network access mode of HSS has been changed to 0 (Packet and Circuit).
Versions of MME prior to v2.4.2 did not use this value. Open5GS set
the attach result of Attach Complete message as it is by looking
at the attach type of the Attach Request message.
Now, if the network access mode of HSS is set to 2 (Only Packet),
this value is affected by MME from v2.4.3. Regardless of the attach type
of the Attach Request, the MME will set EPS Only to the attach result
of Attach Complete.
3GPP TS 24.501 version 16.6.0 Release 16
4.4 NAS security
4.4.6 Protection of initial NAS signalling messages
1) the UE needs to send non-cleartext IEs in a REGISTRATION REQUEST
or SERVICE REQUEST message, the UE includes the entire REGISTRATION
REQUEST or SERVICE REQUEST message (i.e. containing both cleartext IEs
and non-cleartext IEs) in the NAS message container IE and shall cipher
the value part of the NAS message container IE. The UE shall then send
a REGISTRATION REQUEST or SERVICE REQUEST message containing
the cleartext IEs and the NAS message container IE;
When connecting to the UPF port for the PFCP protocol (8805) and sending
an association setup request followed by a session establishment request
with a PDI Network Instance set to ‘internet’, it causes a stack corruption
to occur.
So, ogs_fqdn_parse() fixed.
nas-common library includes libcrypt. However, SGW-C don't have to use
crypt library. As such, ogs_nas_plmn_id function was moved to
3gpp-core-types.[ch]
For more information,
$ ./install/bin/open5gs-sgwcd
./install/bin/open5gs-sgwcd: error while loading shared libraries: libogscrypt.so.2: cannot open shared object file: No such file or directory
$ ldd ./install/bin/open5gs-sgwcd
linux-vdso.so.1 (0x00007ffc749ad000)
libogsapp.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogsapp.so.2 (0x00007f1f92277000)
libogscore.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogscore.so.2 (0x00007f1f92240000)
libogsgtp.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogsgtp.so.2 (0x00007f1f921eb000)
libogsnas-common.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogsnas-common.so.2 (0x00007f1f921e5000)
libogspfcp.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogspfcp.so.2 (0x00007f1f92177000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f92134000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f91f42000)
libyaml-0.so.2 => /usr/lib/x86_64-linux-gnu/libyaml-0.so.2 (0x00007f1f91f20000)
libogscrypt.so.2 => not found
libogsipfw.so.2 => /home/acetcom/Documents/git/open5gs/install/lib/x86_64-linux-gnu/libogsipfw.so.2 (0x00007f1f91ef5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f922b1000)
