vSomeip Version
v3.5.4
Boost Version
N/A
Environment
Embedded Linux
Describe the bug
If specifying the routing credentials using the new, current format, using the '/routing/host/uid' and the '/routing/host/gid' keys, the credentials are not really enforced as it will allow the connection, falling back to 'audit mode', as shown in the picture below:
If specifying the routing credentials using the old, deprecated format, using the '/routing-credentials/uid' and the '/routing-credentials/gid' keys in the JSON configuration file, these credentials are enforced, as shown in the picture below:
The relevant code performing this check is:
I believe the issue is, that the 'check_routing_credentials_' flag, is only set when the routing credentials are loaded using the old format:
And left unset if using the new format:
Although this is something that was tested in v3.5.4 on my side, I believe this to be reproducible in the last version too (the pics currently refer to the master branch), and versions previous to v3.5.4.
It can be relatively substantial security gap that might be affecting multiple releases. In principle any application will be able to connect regardless of configured / actual routing security credentials in the routing manager, as, on error, the check will fallback to audit mode and allow the connection.
Reproduction Steps
Simply use the new format of routing credentials to specify the UID and GID. On error, the connection is still allowed as it wrongly falls back into audit mode.
Expected behaviour
New format expectations should match old format expectations.
Logs and Screenshots
Already explained in detail in description of the bug.
vSomeip Version
v3.5.4
Boost Version
N/A
Environment
Embedded Linux
Describe the bug
If specifying the routing credentials using the new, current format, using the '/routing/host/uid' and the '/routing/host/gid' keys, the credentials are not really enforced as it will allow the connection, falling back to 'audit mode', as shown in the picture below:
If specifying the routing credentials using the old, deprecated format, using the '/routing-credentials/uid' and the '/routing-credentials/gid' keys in the JSON configuration file, these credentials are enforced, as shown in the picture below:
The relevant code performing this check is:
I believe the issue is, that the 'check_routing_credentials_' flag, is only set when the routing credentials are loaded using the old format:
And left unset if using the new format:
Although this is something that was tested in v3.5.4 on my side, I believe this to be reproducible in the last version too (the pics currently refer to the master branch), and versions previous to v3.5.4.
It can be relatively substantial security gap that might be affecting multiple releases. In principle any application will be able to connect regardless of configured / actual routing security credentials in the routing manager, as, on error, the check will fallback to audit mode and allow the connection.
Reproduction Steps
Simply use the new format of routing credentials to specify the UID and GID. On error, the connection is still allowed as it wrongly falls back into audit mode.
Expected behaviour
New format expectations should match old format expectations.
Logs and Screenshots
Already explained in detail in description of the bug.