Rust remote code execution

[Striker789]

@jim-signal, @jrose-signal and the rest of the Sign team I would like to thank you for the great work regarding the rust implementation for Signals signaling and by replacing the C library with a memory safe language, this vastly reduces the attack surface for memory corruption vulnerabilities.

Signal has since prevented a webrtc connection from being performed prior to a user being registered in the contacts list. Additionally, @peter-signal has contributed in the removal of SDP and SCTP to reduce the number of API's to make matters secure. Nonetheless, Signal does not prevent the caller from sending the signaling message despite the user not being registered in the contact list.
Therefore, despite the use of Rust to limit remote code executions, there are still vulnerabilies in the memory safe language.

However, here are some general techniques that attackers may employ to exploit input validation vulnerabilities in Rust:

1. Injection Attacks: Attackers may attempt to inject malicious code or payloads into input fields that are not properly validated or sanitized. This can lead to code execution vulnerabilities, enabling them to deliver and execute malware within the signaling system.

2. Input Validation: Input validation ensures that the data received by a system meets the expected format, structure, and constraints. Failure to adequately validate input can lead to various security vulnerabilities, including those that could potentially be leveraged for RCE. For

3. Buffer Overflows: Insufficient input validation or boundary checks can lead to buffer overflow vulnerabilities. Attackers can exploit these vulnerabilities by crafting input that exceeds the buffer's capacity, potentially overwriting adjacent memory areas with malicious code, leading to malware execution.

4. Deserialization Vulnerabilities: If the signaling system involves deserializing data received from external sources, inadequate input validation during deserialization can result in deserialization vulnerabilities. Attackers may craft specially crafted input to trigger deserialization flaws, allowing them to execute arbitrary code or deliver malware.

5. Command Injection: In scenarios where the signaling system interacts with external processes or executes shell commands, inadequate input validation can enable command injection attacks. Attackers can manipulate input to inject malicious commands that get executed by the system, potentially leading to malware delivery.

6. Path Traversal Attacks: If the signaling system deals with file or path operations, insufficient validation of user-controlled input can lead to path traversal vulnerabilities. Attackers can exploit these vulnerabilities to access unauthorized files or directories, potentially delivering malware.

To mitigate these risks and protect against input validation vulnerabilities in Rust, it is crucial to follow secure coding practices such as:

1. Implement strict input validation and sanitization routines for all user-supplied data.
2. Enforce proper input and data validation at every layer of the signaling system.
3. Utilize safe Rust constructs, such as option types, error handling, and proper memory management, to minimize the risk of memory-related vulnerabilities.

In doing so, this effectively prevents RCE to be used in Rust coding. Additionally, it would be better to prevent a non registered contact from being to send the protobuf messages in v4, or any signaling messages without being registered in the contacts list.

Thank you

[jrose-signal]

Thanks for your report. We believe that we are properly handling the input from signaling messages such that they cannot result in any of the vulnerabilities you've stated (some of which don't apply to RingRTC and its use of WebRTC). If you have a specific counterexample, please send it to security@signal.org and we can work with you privately.