Note from project technical lead on this bug report (2023-12-14):

We do not consider this a bug as the underlying feature of A&A in the interface between xApp and RIC (RIC-1009) is not yet implemented. I.e., the OSC Near-RT RIC does not comply with chapter 5.1.3 in “O-RAN.WG11.Security-Requirements-Specification.O-R003-v07.00”. Naturally - depending on the exact threat model - in an environment where xApps are not trusted or considered a likely initial entry point for an attack, measures outlined in chapter 5.1.3 should indeed be applied. They depend - as any open-src project - on contributors implementing RIC-1009.

– original report
Dear O-RAN Software Community

I'd like to report an issue with the RMR service not verifying the messages it receives.

We know that components using the rmr library(RMR service) rely on the routing manager to regularly send a routing table, so they can communicate with other components inside the RIC system.

However, the RMR service does not verify the source of the received routing table information, and the transmission of these routing tables is unencrypted, which means we can send forged routing tables to deceive the target service.

Impact:

This lack of validation allows an attacker to exploit this weakness by sending forged routing table information to any RMR service.

For example, attackers could use xApp to send forged routing tables to other RMR services and mess up communication between different components.

PoC:

In the attachment, I have provided an example of a route table packet that can be used to interrupt communication between various components.

You can simply change the component's message routing settings by sending it through xApp to the target component, such as e2term.