Skip to content

Fix the DoS vulnerability in RA procedure

Takayuki Okabe requested to merge fix-dos-vulnerability-of-RA-procedure into develop

Problem

In the RA procedure of the initial registration, if messageClassExtension is sent instead of RRCSetupRequest and it is repeated several times, the DU will no longer accept the new RA procedure

Reproduction procedure

This problem was confirmed using ci-scripts/yaml_files/5g_f1_rfsimulator/docker-compose.yaml.

(1) Change the source code (do_RRCSetupRequest() in openair2/RRC/NR/MESSAGES/asn1_msg.c) to send messageClassExtension instead of RRCSetupRequest as follows:

- ul_ccch_msg.message.present = NR_UL_CCCH_MessageType_PR_c1;
+ ul_ccch_msg.message.present = NR_UL_CCCH_MessageType_PR_messageClassExtension;

(2) Start gNB and UE, execute the initial registration, and stop UE after a few seconds.

(3) Undo the changes in (1), start UE, and execute initial registration again. Then, it can be confirmed that the initial registration fails.

Cause of the problem

When messageClassExtension is sent as MSG3 in RA procedure, CU does not respond to it, as the message is not RRCSetupRequest.

If CU responds nothing for the message, the DU detects ra_timer expire and terminates the RA procedure, but does not free RA resources.

If this procedure is repeated for a while, all the RA resources are marked as "using" and no new RA procedure is accepted.

Fix detail

I fixed DU to release resources of the RA procedure when DU times out in RA procedure.

I checked TS38.331 and TS38.321 and confirmed that there is no need to reuse the resources of the RA procedure after a timeout as a specification.

In the case of CFRA, the cfra and rnti values included in the resources of the RA procedure are left as they are (I understand that commit: ab9f9bdd is this intention).

Concern

Similar resource exhaustion probably occur when the RA procedure in CFRA is performed (not due to my fix).

Signed-off-by: okabetakayuki okabe_takayuki@jp.fujitsu.com

Merge request reports