srsUE integrity check bypass 2

[unrloay2]

Issue Description

[Describe the issue in detail] Even after establishing the NAS security context (after NAS Security Mode Complete), srsUE accepts the plain NAS message. In other words, srsUE does not check the integrity of the NAS message if the security header type is set to 0.

Related function: https://github.com/srsran/srsRAN/blob/254cc719a9a31f64ce0262f4ca6ab72b1803477d/srsue/src/stack/upper/nas.cc#L468-L594

The function write_pdu does not check whether the UE established the security context or not. According to TS 24.301 (subclause 4.4.4.2), the UE shall not process any NAS signaling messages unless they have been successfully integrity checked by the NAS, after establishing the NAS security context.

However, this function checks the integrity of the message only according to the security header of the received message, not the presence of the security context. The parsing functions also do not check the presence of the NAS security context, leading to the integrity check bypass.

Setup Details

[Specify details of the test setup. This would help us reproduce the problem reliably] e.g. Network configuration, Operation System, Hardware, RF front-end, library and driver versions

Expected Behavior

[What you expect to happen] UE should drop plain NAS messages after establishing the NAS security context.

Actual Behaviour

[What happens instead e.g. error message] UE doesn't drop them and performs corresponding behaviors.

Steps to reproduce the problem

[Tell us how to reproduce this issue e.g. RF setup, application config files] When srsUE completes the NAS security context setup (after NAS security mode complete), srsEPC sends a NAS message with security header type 0.

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

We can use have_ctxt to check if the UE established the security context. We can slightly modify the following function using have_ctxt.

https://github.com/srsran/srsRAN/blob/254cc719a9a31f64ce0262f4ca6ab72b1803477d/srsue/src/stack/upper/nas.cc#L509-L526

(Additional if statement)

if (sec_hdr_type == LIBLTE_MME_SECURITY_HDR_TYPE_PLAIN_NAS) {
  if (have_ctxt) {
    logger.error("Not handling ~~");
    return;
  }
...
} 

[unrloay2]

@andrepuschmann Hi Andre, can you check the above issue?

[andrepuschmann]

Hi @unrloay2 , apologies for the late reply. I can confirm the bug. I've prepared an update and will publish that shortly. Thanks

[andrepuschmann]

Just for reference, with the suggested change there is a regression in the UE conformance tests. Specifically those tests fail:

[srsue_conf_testcases.TC_9_2_2_1_1](http://10.12.1.139:8080/view/TTCN3/job/srsue_conf_test_nightly/238/testReport/junit/(root)/srsue_conf_testcases/TC_9_2_2_1_1/)
[srsue_conf_testcases.TC_9_2_2_1_7](http://10.12.1.139:8080/view/TTCN3/job/srsue_conf_test_nightly/238/testReport/junit/(root)/srsue_conf_testcases/TC_9_2_2_1_7/)
[srsue_conf_testcases.TC_9_3_1_17](http://10.12.1.139:8080/view/TTCN3/job/srsue_conf_test_nightly/238/testReport/junit/(root)/srsue_conf_testcases/TC_9_3_1_17/)

We won't merge this change unless we also pass those tests. It seems there is a security context clear missing somewhere. However, we don't have the bandwidth right now to further investigate the issue.