vsomeip
vsomeip copied to clipboard
Someip notifications are sent , even after sending connection rejection(NACK)
Setup: vsomeip - server running notify-sample example as per the readme , changed the vsomeip-local.json (unicast ip to 192.168.56.102) ip-192.168.56.102
python script -client(differnet vm image(equivalent to different device)) crafting a someip sd valid subscribe packet, using scapy someip module and sending it to the server ip-192.168.56.101
Description: server sends the offer in cyclically, when the valid subscribe is sent from the client to the server, the server is sending back a subscribe NACK , but it is followed by server sending the notifications, the server should not send the notifications since it has rejected the connection. this is a vulnerability and can be misused to manipulate server behavior and can lead to loss of information to the client since it receives a NACK assuming connection rejection.
Logs while sending NACK followed by notifications: Setting event (Length=4). Setting event (Length=5). Setting event (Length=6). Setting event (Length=7). 2020-09-07 11:29:11.996296 [info] vSomeIP 3.1.16.1 | (default) 2020-09-07 11:29:11.441598 [info] STOP OFFER(1277): [1234.5678:0.0] (true) Setting event (Length=8). 2020-09-07 11:29:11.899599 [info] Reboot detected: IP=192.168.56.101 2020-09-07 11:29:11.927115 [warning] send_subscribe Couldn't send subscription to local client [1234.5678.4465.ffff] subscriber: 0000 2020-09-07 11:29:11.951018 [info] notify_one_unlocked: Notifying 8778 failed. Event payload not (yet) set! 2020-09-07 11:29:11.976897 [info] REMOTE SUBSCRIBE(0000): [1234.5678.4465] from 192.168.56.101:50000 unreliable was not accepted 2020-09-07 11:29:21.101374 [info] vSomeIP 3.1.16.1 | (default) 2020-09-07 11:29:21.765247 [info] OFFER(1277): [1234.5678:0.0] (true) 2020-09-07 11:29:21.792898 [info] udp_server_endpoint_impl: SO_RCVBUF is: 212992 Setting event (Length=9). Setting event (Length=1).
In the wireshark traces the NACK is sent from the server followed by the notifications.
Could you please attach the wireshark trace?
Hi i tried attaching it but i got "we dont support that file type error" , i tried to attach screenshot i got "something went really wrong" error
Couldn´t you zip it?
please ignore icmp port unreachable messages , since i m using scapy the other side it doesnt open udp ports implicitly, hence the icmp message
when further digged into the issue its seen as shown below,
when the application sends stop offer, socket is closed and if it receives subscribe at that time it will reject it (as shown below), but later when socket is reopened it will send the pending notifications to the client without checking whether the subscription request was rejected earlier
vsomeip tester
(open socket at 30509 to listen) offer at port (30509) --------> offer at port (30509) --------> offer at port (30509) --------> offer at port (30509) --------> offer at port (30509) -------->
stop offer ------->
(close the socket)
(socket closed) <---------- subscribe
subscribe Nack ---------->
(reopen the socket) offer at port (30509) --------> notification --------> offer at port (30509) --------> notification --------> notification --------> offer at port (30509) --------> stop offer -------->
+1
Can you test this with vsomeip 3.3? Thanks
I have also experienced that NACK is sent from the server(Simulated in CANoe) even after "subcribe Eventgroup" sent from the client(Real ECU). Server --> offers to all client --> sent subscribe eventgroup Server --> sent NACK subscribe eventgroup. Do you know what might be the issue why we received NACK subscribe eventgroup from the Server even the offers are subscribed by client.