These libraries depend on the logging module, so add the right
dependency log_headers. Indirectly, this will fulfill the condition of
T. I consider the prior usage of generate_T or {T_LIB} incorrect,
because basically none of these libraries actually, actively use T, but
rather only the logging module, which pulls in T. The dependency of
log_headers will also take care of generating and including T headers,
which is a dependency of the logging module.
For conf2uedata and related, fulfill the dependency
through conf2uedata_lib (on which the rest depends).
remove specific directory for LTE SIM management tools
This is very old code has never been integrated with the "main" OAI
cmake infrastructure and more recent libraries.
This MR integrates the three binaries for LTE virtual sim management in
the regular build process and log system
Tell strncpy() the size including the NULL byte to make sure we copy all
data.
This just fixes these warnings:
openair3/NAS/TOOLS/conf_usim.c: In function ‘gen_usim_data’:
openair3/NAS/TOOLS/conf_usim.c:191:17: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
openair3/NAS/TOOLS/conf_usim.c:190:53: note: length computed here
openair3/NAS/TOOLS/conf_usim.c:195:17: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
openair3/NAS/TOOLS/conf_usim.c:194:54: note: length computed here
add copy with limited size and truncate properly with null C string termination.
As clang-format doesn't handle tab indented files and as it is not the
OAI coding rule, the entire file is re-indented with present OAI coding
rule.
Remove the --usim-test option: to my knowledge, it's not used by users,
and is misleadingly placed in various places where there should not be a
difference w.r.t. USIM configuration.
When making the changes, I assumed that --usim-test would be 0 (the
default), which is the case in all executables when not specified in
options except for the nr_dlsim, nr_pbchsmi, nr_ulsim simulators.
The only exception is the initialization of PDCP from the MAC, which is
not correct (the PDCP is in the CU, so it does not make sense to call it
from the MAC which is in the DU). Instead, always initialize from main,
even in the NSA case (NSA was covered by the incorrect initialization
from MAC).
This in turn let to some more cleanup around function du_rlc_data_req().
After receiving GTP packets at the DU, they were given to the PDCP to
enqueue the packet at RLC. This does not work anymore, since the PDCP is
not initialized; it also does not seem necessary, as this enqueue
functionality is necessary to decouple PDCP and RLC to avoid deadlocks
in monolithic, but in split-mode, this cannot happen. Instead, call
directly into the RLC when receiving GTP packets.
bugfix: read msg_type only after deciphering
There was a problem with accessing msg_type from the input buffer before
deciphering, giving obviously wrong value.
CI team: we should add a test in the CI with NAS ciphering + integrity
(connection to the core) set to not null (I suggest nea2/nia2). With
openair's core, this is done by setting this in the amf config file
(nia1 and nea2 at the top of the list):
supported_integrity_algorithms:
- "NIA2"
- "NIA1"
- "NIA0"
supported_encryption_algorithms:
- "NEA2"
- "NEA1"
- "NEA0"
And also put full security in the AS. This is done with this in the gnb
config file:
security = {
ciphering_algorithms = ( "nea2", "nea0" );
integrity_algorithms = ( "nia2", "nia1", "nia0" );
drb_ciphering = "yes";
drb_integrity = "yes"
};
Ideally we should test this with both openair UE and cots UE. But as a
strict minimum do for openair UE (this is where the bug was).
No need to do much traffic, a few ping is enough. But if you want to
check throughput with full security, why not.
Add NAS Authentication Reject enc/dec library and unit test
This MR introduces the library for encoding/decoding of NAS Authentication
Reject (8.2.5.1 of 3GPP TS 24.501) and relevant unit test.
The message is sent by the AMF to the UE to indicate that the authentication
procedure has failed. A NAS handler was also introduced.
Handle authentication not accepted by the network. The handler assumes the message
is not integrity protected, processes the received NAS message and logs whether a
EAP-failure is enclosed. The UE enters state: 5GMM-DEREGISTERED.
Not done in this commit: the UE shall performs actions as per 5.4.1.3.5 of
3GPP TS 24.501, including (1) Abort any ongoing 5GMM procedure
(2) Stop all active timers: T3510, T3516, T3517, T3519, T3520, T3521
(3) Delete stored SUCI. (4) handle EAP-failure message.
NAS Registration Reject: Add bounds and lengths checks
This change adds lengths checks to the received registration reject
message and also performs a bounds check for the received cause.
Since the cause is not checked, any string in the memory can be
dereferenced, possibly leading to DoS.
Signed-off-by: Eduard Vlad eduard.vlad@rwth-aachen.de
DL NAS Transport: Fix Message Type retrieval on too short message
The change addresses the SM message type retrieval for DL NAS Transport
messages. The assumption of an offset 17 = 7 (MM Sec) + 3 (MM Plain) + 1
(IEI) + 2 (Len) + 4 (SM) is correct.
However, if the DL NAS Transport is received in a plain header, the
lengths would not add up anymore. (This is not complying with the
standard, so not allowed, but possible). The check for the length is
necessary to not process arbitrary memory contents beyond the
pdu_buffer.
Add Security Mode Reject lib/unit test and adopt in stack
This MR is adding the library for the NAS Security Mode Reject, and
relevant unit test.
The UE shall send a SECURITY MODE REJECT containing a 5GMM cause that
typically indicates one of the following cause values: (23) UE security
capabilities mismatch. (24) security mode rejected, unspecified
- The message shall be protected if a security context is available.
- The message is adopted in the handling of Security Mode Command failure.
See 3GPP TS 24.501 5.4.2.5 "NAS security mode command not accepted by
the UE".
This MR includes changes from !3262:
> This patch series addresses a security issue where the UE improperly
> accepts a Security Mode Command (SMC) without an authentication header
> (Security Header 0). This behavior violates TS 24.501 and enables an
> attacker to bypass authentication, set integrity protection to NULL
> (NIA0), and reconfigure the UE without proper verification.
>
> We identified the following issues:
>
> 1. The UE currently accepts unauthenticated SMC messages, even
> allowing NIA0 and EIA0 to be set outside emergency mode.
> 2. When applying NIA0, the MAC field remains uninitialized,
> consistently containing the sequence 0xFF3F0000, making it feasible
> to bypass authentication and enforce insecure configurations.
> 3. The UE does not properly signal security mode failures to the Core
> Network.
>
> This patch series tries to address the above-mentioned issues:
>
> 1. Reject unauthenticated SMC messages, enforcing the requirement that
> they must be integrity-protected.
> 2. Validate MAC before applying security settings, ensuring that only
> authenticated messages are accepted.
> 3. Tear down the security context if an integrity check fails.
> 4. Introduce the Security Mode Reject message to inform the Core
> Network of failed SMC procedures, as required by TS 24.501.
This change performs the algorithm rejection in the corresponding NAS
handler for 5G, since the protocol definitions differ between LTE and
5G, regarding NIA0/EIA0 user plane traffic.
Therefore, for 5G NIA0 is rejected, since it is not allowed under normal
circumstances, while LTE user plane traffic can indeed have EIA0
selected.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
It is not allowed to accept an unauthenticated SMC message,
as this effectively bypasses all security measures and
enables a malicioius attacker to compromise the confidentiality
and integrity of exchanged messages.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
Retrieving the mac is necessary during the handling of the SMC, since the
context is generated from the specified keys therein. Therefore, it is
necessary to check the MAC right after generation and ensure the authenticity
of the message. If it is not given, the message must be rejected.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
This is necessary to indicate to the Core network, that
the security mode command procedure has failed.
Check for the security context presence when generating the Security Mode
reject message: according to 3GPP TS 24.501 5.4.2.5 "NAS security mode command
not accepted by the UE" The UE shall send a SECURITY MODE REJECT containing
a 5GMM cause that typically indicates one of the following cause values:
(23) UE security capabilities mismatch
(24) security mode rejected, unspecified
The message shall be protected if a security context is available
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Co-authored-by: Guido Casati <hello@guidocasati.com>
This 5GMM message is required for an invalid security mode command,
e.g. when the MAC integrity fails, or the wrong Security Header is set.
* Add encode/decode functions for common IEs in fgmm_lib: this library
provides encoding/decoding helpers for IEs shared across multiple
NAS messages. The goal is to avoid the legacy approach of creating
separate files per IE
* add NAS Cause enc/dec lib
* Adopted byte_array_t to handle the buffer
Co-authored-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
The UE shall use the currently stored UL NAS count to derive the
KgNB. Hardcoding the UL count to 0 is wrong, if there is a reset
to be done it should be explicitly done elsewhere.
Closes#832
The Security Mode Command is the only NAS message sending a security header
type "integrity protected with new 5G NAS security context". Such header
type is indicating that there is no valid security context and it is
indicating the current one configured by the AMF.
When receiving a Security Mode Command the "AMF shall reset the downlink NAS COUNT"
and use it to integrity protect the initial Security Mode Command. "The AMF shall
send the SECURITY MODE COMMAND message unciphered, but shall integrity protect [...]
The AMF shall set the security header type of the message to
"integrity protected with new 5G NAS security context".
See 5.4.2.2 3GPP TS 24.501.
This commit is ensuring the NAS DL count is reset when the relevant security header
is received. Also, the security container is deleted since no more valid and
NAS_SECURITY_NO_SECURITY_CONTEXT is returned. The setup of the new security context
is done by "handle_security_mode_command",
NAS 3GPP TS 24.501 clause 4.4.4.2 specify which NAS messages
are an exception to the integrity protection. All the other
scenarios are expected to be integrity protected. The
nas_security_rx_process function is returning:
1) NAS_SECURITY_NO_SECURITY_CONTEXT if no security context is established
2) NAS_SECURITY_UNPROTECTED for the messages listed in 4.4.4.2
3) NAS_SECURITY_INTEGRITY_PASSED if the integrity check is successful
These 3 results can be all considered successful. The other not.
Also, add a function to check whether a message is allowed to be
integrity unprotected, as per clause 4.2.2.2.
* trigger Identity Response callback from the handler
* process decoded message
According to 4.4.4.2 3GPP TS 24.501, Identity Request
with Identity Type SUCI is not expected to be
integrity protected.
The information about the payload carried by NAS DOWNLINK is helpful
in the logging and also for debugging purposes, therefore it was
added in this commit by enabling the already existing relevant function.
This commit restores the behaviour before the changes introduced in 611c0554. The NAS
Deregistration Accept message is unprotected, therefore the function will return
NAS_SECURITY_UNPROTECTED that would then be considered as NAS_SECURITY_INTEGRITY_PASSED
Unprotected message have a plain header of 3 octets, however security protected messages
have a 7 octets header.
This change adds lengths checks to the received registration reject
message and also performs a bounds check for the received cause.
Since the cause is not checked, any string in the memory can be
dereferenced, possibly leading to DoS.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
The change addresses the SM message type retrieval for DL NAS Transport
messages. The assumption of an offset 17 = 7 (MM Sec) + 3 (MM Plain) + 1
(IEI) + 2 (Len) + 4 (SM) is correct.
However, if the DL NAS Transport is received in a plain header, the
lengths would not add up anymore. (This is not complying with the
standard, so not allowed, but possible). The check for the length is
necessary to not process arbitrary memory contents beyond the
`pdu_buffer`.
Signed-off-by: Eduard Vlad <eduard.vlad@rwth-aachen.de>
Add 5GMM Authentication Failure enc/dec lib and unit test
This MR is introducing the 5GMM Authentication Failure message library as per
8.2.4 of 3GPP TS 24.501. This message is sent from UE to network under certain
conditions. The message is also introduced in stack and is send if the received
ngKSI already in use.
- add new library for 5GMM Authentication Failure enc/dec and unit test
- introduce handler and generate function for NAS Authentication Failure
store ngKSI
- send Authentication Failure if ngKSI is already associated with one of
the 5G security contexts stored in the UE
Closes#852
Follow up on NAS Registration Accept lib
This MR is a follow up on !2984 (merged).
The goal is to enhance the NAS Registration Accept lib:
- Add regression test for NAS Registration Accept: the goal of this test is to
prevent on the decoding of the NAS Registration Accept sent by the OAI CN5G
- Add equality check and free utility functions to NAS Registration Accept
library
- Free NAS Registration Accept after use: heap memory is allocated for this
message during decoding and shall be free after processing
- Remove harcoded Slice Differentiator (SD) in NAS decode_nssai_ie and update
the processing logic: The SD stored in the allowed S-NSSAI list was hardcoded
in the decoding function, however this IE is not mandatory but optional.
Therefore, the check of the decoded message contents should take into account
the presence of the field in the received message and in that scenario, check
the stored value against the one from the UICC. If no SD was received, consider
the UICC SD a valid one.
- Cleanup and other fixes to decode_registration_accept: (1) adopt byte array
(2) move registration result enc/dec to registration accept library (3) check
on buffer lengths (4) add defines whenever necessary (5) simplify the code
fix IP address in 4G UE
The following error was appearing when running LTE UE:
inet_pton(): cannot convert -64.-74.0.2 to IPv4 network address
The allocated address by the core actually is 192.182.0.2.
On my host "char" is signed, leading to the above error (192 and 182
are seen as signed).
Let's force "ip_addr" unsigned and everyone is happy.
The following error was appearing when running LTE UE:
inet_pton(): cannot convert -64.-74.0.2 to IPv4 network address
The allocated address by the core actually is 192.182.0.2.
On my host "char" is signed, leading to the above error (192 and 182
are seen as signed).
Let's force "ip_addr" unsigned and everyone is happy.
This commit refactors the TUN interface management by moving its creation
and configuration from the PDCP layer to the SDAP layer for UE.
Key changes include:
- Introduced `tun_generate_ue_ifname` and `tun_destroy` functions for better
TUN interface lifecycle management.
- Added support for creating and destroying UE-specific TUN interfaces in SDAP.
- Refactored `nr_pdcp_module_init` to remove TUN-related logic and moved it
to SDAP.
- Updated NAS and SDAP layers to handle PDU session-specific TUN interface
creation and configuration.
- Enhanced SDAP entity management to include TUN socket handling and thread
lifecycle.
- Updated NAS message handling to initialize default PDU session TUN
interfaces in NOS1 mode.
- Use a single SDAP thread function for gNB and UE
- Allow noS1 mode also in SA on gNB
These changes improve modularity by isolating TUN interface management within
the SDAP layer, aligning with the 3GPP architecture, and simplifying the PDCP
layer.
Co-Authored-By: Robert Schmidt <robert.schmidt@openairinterface.org>
This test verifies that a NAS Registration Accept message, as received
from the OAI CN5G, is correctly decoded and matches the expected output
structure. It ensures that future changes to the NAS decoder do not
break compatibility or correctness with existing decoding behavior.
The SD stored in the allowed S-NSSAI list was hardcoded in the decoding
function, however this IE is not mandatory but optional, therefore
the check of the decoded message contents should take into account
this and check the stored value against the one from the UICC only when the field is present.
If no SD was received, consider the UICC SD a valid one.
Also, add free function to Registration Accept library and adopt in stack to free NAS
Registration Accept after use: heap memory is allocated for this message during decoding
and shall be free after processing.
Guido Casati