In the scenario in which the host runs the Sanzu server, the attacker may also control the video encoder.
In this case, on the client side, the video decoder may receive a video stream data controlled by the attacker.
The client decoder code may be split out of the main code in order to sandbox it.
A shared memory to hold raw pixel may be used between the client code and the video decoder
a communication between the video decoder and the main code can be used (using also protobuf)
In this case, the video decoder may sandbox itself before parsing arbitrary data.
Moreover, the video decoder could be forced to use software decoding: this will avoid having allowing the use of graphic drivers in the video decoder sandbox. As the decoding process is light compared to the encoding part, this may be acceptable from a performance point of view. (about half a cpu for the 1080p@25fps)
In the scenario in which the host runs the Sanzu server, the attacker may also control the video encoder. In this case, on the client side, the video decoder may receive a video stream data controlled by the attacker.
The client decoder code may be split out of the main code in order to sandbox it.
In this case, the video decoder may sandbox itself before parsing arbitrary data. Moreover, the video decoder could be forced to use software decoding: this will avoid having allowing the use of graphic drivers in the video decoder sandbox. As the decoding process is light compared to the encoding part, this may be acceptable from a performance point of view. (about half a cpu for the 1080p@25fps)