Dear O-RAN Software Community

I'd like to report the issue regarding xApp registration

After being installed, an xApp needs to provide RMR routing information to the app manager service for registration. This information is then added to the RMR routing table managed by the Routing Manager, allowing the xApp to send and receive RMR packets of various types, such as RIC_SUB_REQ and RIC_INDICATION.

However, the RMR routing information provided by the xApp is not restricted. We can use RMR message types that xApps shouldn't be using, potentially disrupting the operation of other services.

For instance, if xApp includes RIC_E2_SETUP_REQ in its registration RMR messages, it could mess with the routing table rules for RIC_E2_SETUP_REQ. This message type is usually sent by E2node and is supposed to be processed by e2mgr. But with xApp's registration, RIC_E2_SETUP_REQ goes straight to xApp, leading to improper message processing. E2node can't finish the E2 setup process, triggering a DoS attack.

Impact:

Attackers could register specific RMR message types during xApp's registration to mess with the operation of other service components through xApp, exploiting this vulnerability to launch a DoS attack.

PoC:

Taking the ric-plt-hw-go project as an example, we can simply modify the rmr field in the config-file.json by adding RIC_E2_SETUP_REQ to rxMessages. Then, follow the subsequent steps to deploy the xApp.

export CHART_REPO_URL=http://0.0.0.0:8090 
sudo -E dms_cli onboard config/config-file.json config/schema.json 
sudo -E dms_cli install --xapp_chart_name=hw-go --version=1.0.0 --namespace=ricxapp

#Check current RMR routing table

export RTMGR_HTTP=`sudo kubectl get svc -n ricplt --field-selector metadata.name=service-ricplt-rtmgr-http -o jsonpath='{.items[0].spec.clusterIP}'`

curl -X GET "http://$RTMGR_HTTP:3800/ric/v1/getdebuginfo" -H  "accept: application/json" | jq

Attached are the config file needed for xApp onboard and the routing table managed by the Routing manager after installing xApp, along with logs from the hw-go xApp.

We can see the addition of a new line "mse|12001|-1|service-ricxapp-hw-go-rmr.ricxapp:4560\n", where 12001 represents RIC_E2_SETUP_REQ.

This means that any RIC_E2_SETUP_REQ message will be sent to the hw-go xApp. This behavior can also be spotted in the logs of the hw-go xApp.

As a result, E2node won't receive any response and can't finish the E2 setup process