Wrong GID/UID received

[kkretsch]

I try to run a hello world example using vSomeIP 3.1.20.3 inside a docker gitlab CI container. Everything works fine, until I enable check_credentials.

All tasks in that docker are started as root UID/GID 0/0, but I receive those lines by the service and client startup:

2021-04-12 07:26:04.842210 [info] Client 102 () successfully connected to routing  ~> registering..
2021-04-12 07:26:04.843116 [info] Client 101 () successfully connected to routing  ~> registering..
2021-04-12 07:26:04.845689 [info] Application/Client 0102 is registering.
2021-04-12 07:26:04.845941 [info] Application/Client 0101 is registering.
2021-04-12 07:26:04.849429 [info] Client [1] is connecting to [102] at /tmp/vsomeip-102
2021-04-12 07:26:04.854610 [info] Client [1] is connecting to [101] at /tmp/vsomeip-101
2021-04-12 07:26:04.855854 [info] Application/Client 102 () is registered.
2021-04-12 07:26:04.860704 [info] REGISTERED_ACK(0102)
2021-04-12 07:26:04.861229 [info] Application/Client 101 () is registered.
2021-04-12 07:26:04.865871 [info] REGISTERED_ACK(0101)
2021-04-12 07:26:04.867969 [info] vSomeIP Security: Client 0x101 with UID/GID=14/16 isn't allowed to offer service/instance 1111/2222 but will be allowed due to audit mode is active!
2021-04-12 07:26:04.869168 [info] OFFER(0101): [1111.2222:1.0] (true)
2021-04-12 07:26:04.874248 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992
2021-04-12 07:26:04.897975 [info] vSomeIP Security: Client 0x102 with UID/GID=12/16 : Isn't allowed to communicate with service/instance/(method / event) 1111/2222/0 but will be allowed due to audit mode is active!
2021-04-12 07:26:04.899457 [info] REQUEST(0102): [1111.2222:1.4294967295]

So with audit mode they can communicate, but where does that ID come from? It isn't even defined in the docker local passwd or group file.

The same source runs locally on ubuntu with activated security and my local IDs 1000 without problems.

[kkretsch]

It even happens when I explicitly uses a non root user in docker:

https://gitlab.kretschmann.software/kai/commonapisample/-/jobs/7121

The processes see their ID 1000 which is right, but the vsomeip reports funny numbers.

[kkretsch]

It seems related to GCC in version 11, if reduce the docker root package to gcc:9.3.0 that error is gone.

So there must be some problem in the GCC 11 changes regarding the storage for credential pairs in the routing server.

[kheaactua]

I'm seeing this with gcc 9.3.0

[kheaactua]

@kkretsch Did you ever make any progress on this? I've been stepping through the code in a debugger and it seems like the credentials simply don't get set.

I'm somewhat convinced that https://github.com/COVESA/vsomeip/blob/13f9c89ced6ffaeb1faf485152e27e1f40d234cd/implementation/endpoints/src/local_server_endpoint_impl.cpp#L724 should be using bound_uid (received through https://github.com/COVESA/vsomeip/blob/13f9c89ced6ffaeb1faf485152e27e1f40d234cd/implementation/endpoints/src/credentials.cpp#L79 ) instead of uid.

But otherwise, https://github.com/COVESA/vsomeip/blob/13f9c89ced6ffaeb1faf485152e27e1f40d234cd/implementation/helper/1.55/boost/asio/detail/reactor_op_ext_local.hpp#L30-L31 don't appear to be set. Sometimes in the debugger it appears that a memory error sets them, but that's about it. (these are forwarded through the call back with https://github.com/COVESA/vsomeip/blob/13f9c89ced6ffaeb1faf485152e27e1f40d234cd/implementation/helper/1.55/boost/asio/detail/reactive_socket_recv_op_ext_local.hpp#L102 )

[kkretsch]

I didn't have yet the time to continue on it. But I think it should be handled/solved as this might be a security risk otherwise. Hoping to have a look the next days again ...

[kkretsch]

I just checked tht again and still have that problem. By just changing the container from Ubuntu 20.04 to 21.10 (which updates gcc from 9 to 11) and recompiling everything it gets th wrong uids again.

Worked: https://gitlab.kretschmann.software/kai/commonapisample/-/jobs/11647

Failed: https://gitlab.kretschmann.software/kai/commonapisample/-/jobs/11659

[kheaactua]

What version of boost are you using? We're using 1.74. Nothing I did ever got credentials to work unfortunately.

credentials.cpp's receive_credentials function works perfectly, but nothing writes to the uid and gid in vsomeip/implementation/helper/1.55/boost/asio/detail/reactor_op_ext_local.hpp that gets passed in async_receive

[kkretsch]

I'm using the ubuntu given ones 1.74 by installing libboost-all-dev within the container.

I also cloned the vsomeip to my server and changed/added some debugging to it. The boud_uid didn't look any better:

2021-10-29 14:30:10.383940 [error] In on_message, UID=13
2021-10-29 14:30:12.375420 [warning] Get credentials 0/0
2021-10-29 14:30:12.375758 [warning] Get credentials 0/0
2021-10-29 14:30:12.376343 [warning] Bound credentials are 4294967295/4294967295
2021-10-29 14:30:12.376402 [warning] Bound credentials are 4294967295/4294967295
2021-10-29 14:30:12.377252 [warning] Get credentials 13/22034
2021-10-29 14:30:12.377847 [warning] Bound credentials are 1000/1000
2021-10-29 14:30:12.377284 [warning] Get credentials 13/18

That looks rather strange, only sometimes the value 1000 is right.

[kheaactua]

That's exactly what I saw. This makes me question if any one has ever truly gotten vsomeip security features to work. I suspect maybe most users use remote connections where the credentials aren't relevant, so haven't even checked it.

A couple academic vsomeip security paper I read appear to just ignore vsomeip security features, and implement some sort of handshake with encryption and message counters - which to be fair, is a much better approach to credentials for local connections and faith for remote connections.

[kkretsch]

At least for local communication one should be able to trust those IDs. And if I get randomly a "0" then it looks like beeing root without haven those rights in real. For me that is a noteworthy security failure.

I'll try to dig deeper into that as we are using this feature for some real projects.

[ahmedwahdan]

any progress on the wrong uid/gid? vsomeip v2.14 / v2.7 gcc 7.5.0 boost 1.65

[kheaactua]

None... But since my interest is mainly with remote clients, it wouldn't offer much security anyways.

[goncaloalmeida]

@kkretsch could you please confirm if this is occurring with the last release?