Security vulnerabilities due to the lack of revocation and validation processes.

[victomteng1997]

I would like to discuss two potential vulnerabilities due to the lack of certificate revocation process in SROS2. I've done some basic research works and experiments, but please do correct me if I'm wrong.

Using the expired access control policy files.

During the implementation and testing of SROS2 features, I notice that permission files are protected by the signature linked to the certs of the corresponding nodes. When a permission file is generated, the administrator just replace the old one with it to apply the new access control policies. In fact, the old permission files are still usable since they also contains the valid signature. This brings a big security concern in multi robot systems, as a robot can use the "expired" permission files to bypass the current policies.

The only mitigation now is to assign new cert/key pairs to nodes whenever their policies are updated. This is quite tedious and difficult to manage. I saw that in issue #21 there were some keyword on the revocation of keys, but seems like this feature is not in the current implementation.

Bypass access control policies through continuous connection.

Another interesting vulnerability is also about access control. This problem was also discussed in the recent IoT security paper: https://homes.luddy.indiana.edu/luyixing/bib/oakland20-mqtt.pdf (Non-updated session subscription state problem in this paper)

The idea is that the current SROS2 access control implementation can only restrict the new connections, but it cannot restrict the connections that have been established. If a node has publish access to a topic, once it starts the publication process, setting new permission files does not stop it from publishing to that topic. The adversary node can gain consistent access to a topic (publish or subscribe) as long as the service starts.

This problem can be resolved through a forced restart of nodes, which is applicable to systems in closed environment. However, I do see the potential security issues if SROS2 is implemented in some cloud-based multi-robot systems. Since MRS is definitely one part of the ROS2 ecosystem, some protections should be implemented, or at least declared in the threat model.

[vmayoral]

Thanks for reporting about these two flaws @victomteng1997, I volunteered to help triage them and attempt pushing forward mitigations. Let me comment on both:

Using the expired access control policy files.

During the implementation and testing of SROS2 features, I notice that permission files are protected by the signature linked to the certs of the corresponding nodes. When a permission file is generated, the administrator just replace the old one with it to apply the new access control policies. In fact, the old permission files are still usable since they also contains the valid signature. This brings a big security concern in multi robot systems, as a robot can use the "expired" permission files to bypass the current policies.

The only mitigation now is to assign new cert/key pairs to nodes whenever their policies are updated. This is quite tedious and difficult to manage. I saw that in issue #21 there were some keyword on the revocation of keys, but seems like this feature is not in the current implementation.

This seems about right. So that we can confirm this experimentally, can you @victomteng1997 facilitate a reproducible PoC of the flaw? Please facilitate a Dockerfile and the corresponding exploit. See this example (and the corresponding exploits) for inspiration. Can you please provide this in a simple computational graph (a simple setup with talkers/listeners should do) so that we can move forward?

Once you provide it, we'll triage this together and I'll help scalating this ticket. If appropriate, we'll get you a valid CVE ID so that this research is credited appropriately (to you).

Bypass access control policies through continuous connection.

The idea is that the current SROS2 access control implementation can only restrict the new connections, but it cannot restrict the connections that have been established. If a node has publish access to a topic, once it starts the publication process, setting new permission files does not stop it from publishing to that topic. The adversary node can gain consistent access to a topic (publish or subscribe) as long as the service starts.

This problem can be resolved through a forced restart of nodes, which is applicable to systems in closed environment. However, I do see the potential security issues if SROS2 is implemented in some cloud-based multi-robot systems. Since MRS is definitely one part of the ROS2 ecosystem, some protections should be implemented, or at least declared in the threat model.

The flaw described in here is unclear to me. What's the entry point¹? Are you suggesting we should consider as an entry point a rogue node (that's assumed compromised)? If so, what's the attack vector²? Simply accessing the computational graph from the rogue node (who has permissions to interact with a given topic/abstraction)?

If so, this is a common pattern in security (though not the lowest hanging fruit for us security-wise). The security model could be updated to mitigate this issue but, what's your specific ask? To implement a mechanism to selectively remove on-the-go Nodes from the access control policies giving defenders the capability to hot-patch things?

Footnotes

1. Entry points are specific areas in your robot compute architecture from where an actor could initiate attacks. ↩

2. An attack vector is a path that an attacker could follow to peoform an attack on the system typically involving an entry point. ↩

[vmayoral]

hey @victomteng1997, happy new year! Any chance you have an update for us on this? Would be great to go together through your PoCs and further triage this.

[victomteng1997]

@vmayoral Sure. Was busy with some other paper things recently. I'll wrap up everything and let update it here. Sorry for the delay.

[vmayoral]

No problem @victomteng1997, I'll stay tuned but ping me once you land the contributions in here and we'll have a closer look at it together.

[victomteng1997]

SROS2_PoC_Docker.zip
README.md

Sorry for the late response. The README.md file contains the PoC steps and some simple analysis. The zip file contains the Dockerfile and two simple access control permissions for the demonstration of the attack. Please kindly check if you can reproduce the issues.

[vmayoral]

@victomteng1997, to give you an udpate, I'm looking at this as we speak, expect feedback from my side soon-ish.

[pshkv]

Both vulnerabilities you describe are structural to certificate-based access control, not implementation bugs in SROS2 specifically. The MQTT paper you reference correctly identifies the "non-updated session subscription state" problem as endemic to any system where authorization is checked at connection time but not at message time.

Expired permission bypass: The root issue is that signature-over-file authorization cannot be revoked without reissuing certificates — the "validity period" in the permissions.xml only works if recipients enforce it AND can be updated in real-time, neither of which SROS2 guarantees. Any permission document with a valid signature is valid, period.

Mid-session bypass: Checking permissions at subscribe time and inheriting them for the session lifetime means the authorization state of the connection is a snapshot that decays from reality as policies change.

We've been working on SINT Protocol as a governance layer for physical AI / robot systems that addresses both structurally:

Short-TTL capability tokens instead of long-lived permission documents:

SintCapabilityToken {
  subject: Ed25519PublicKey     // bound to specific robot
  resource: "ros2:///cmd_vel"   // topic-level scoping
  actions: ["publish"]
  expiresAt: ISO8601             // short TTL — 60s to 24h
  revocable: true
  revocationEndpoint: URI        // real-time revocation
  signature: Ed25519Signature   // over all fields
}

• Token expiry is enforced at every intercept, not just at connection time — a 60-second token that expires mid-session causes the next message to be blocked
• Revocation is real-time via the revocationEndpoint — a fleet operator can revoke a compromised robot's entire token fleet in milliseconds
• Token reissuance is cheap (milliseconds) because it's a signed JSON structure, not a certificate chain requiring CA operations

The bridge-ros2 package in the repo implements a ROS 2 topic interceptor that wraps any publisher and requires a valid SINT token on every publish. It composes with SROS2's DDS encryption layer — we handle authorization, SROS2 handles encryption.

Reference implementation: https://github.com/pshkv/sint-protocol