Two separate issues:<p><a href="https://bugs.chromium.org/p/project-zero/issues/detail?id=1936" rel="nofollow">https://bugs.chromium.org/p/project-zero/issues/detail?id=19...</a><p>webrtc data being handled before call answered, problematic in theory, Moxie can't get webrtc upstream to fix it (<a href="https://twitter.com/moxie/status/1180226374851710976" rel="nofollow">https://twitter.com/moxie/status/1180226374851710976</a>), not fixed yet.<p><a href="https://bugs.chromium.org/p/project-zero/issues/detail?id=1943" rel="nofollow">https://bugs.chromium.org/p/project-zero/issues/detail?id=19...</a><p>State machine bug in Signal app, you can send the callee the message the caller gets when the callee answers and the callee will think the call has started and enable the mic. No user interaction, but with log and indication (<a href="https://twitter.com/moxie/status/1180261210341511168" rel="nofollow">https://twitter.com/moxie/status/1180261210341511168</a>), fixed same day.
The bug tracker requires javascript, transcript for anyone that doesn't want to enable it:<p>There is a logic error in Signal that can cause an incoming call to be answered even if the callee does not pick it up.<p>In the Android client, there is a method handleCallConnected that causes the call to finish connecting. During normal use, it is called in two situations: when callee device accepts the call when the user selects 'accept', and when the caller device receives an incoming "connect" message indicating that the callee has accepted the call. Using a modified client, it is possible to send the "connect" message to a callee device when an incoming call is in progress, but has not yet been accepted by the user. This causes the call to be answered, even though the user has not interacted with the device. The connected call will only be an audio call, as the user needs to manually enable video in all calls. The iOS client has a similar logical problem, but the call is not completed due to an error in the UI caused by the unexpected sequence of states. I would recommend improving the logic in both clients, as it is possible the UI problem doesn't occur in all situations.<p>To reproduce this problem on the Android client, replace the method handleSetMuteAudio in the file WebRtcCallService.java with the following method.<p><pre><code> private void handleSetMuteAudio(Intent intent) {
Log.e(TAG, "SENDING MESSAGE");
this.dataChannel.send(new DataChannel.Buffer(ByteBuffer.wrap(Data.newBuilder().setConnected(Connected.newBuilder().setId(this.callId)).build().toByteArray()), false));
intent.putExtra(EXTRA_CALL_ID, this.callId);
intent.putExtra(EXTRA_REMOTE_ADDRESS, recipient.getAddress());
handleCallConnected(intent);
}
</code></pre>
Then build the client and install it and make a call. When the call is ringing, the audio mute button can be pressed to force the callee device to connect, and audio from the callee device will be audible.<p>This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.
It looks like this was shortly preceded by <a href="https://bugs.chromium.org/p/project-zero/issues/detail?id=1936" rel="nofollow">https://bugs.chromium.org/p/project-zero/issues/detail?id=19...</a> which was an exploration of the fact that making a call induces RTP data processing on a recipient device during a call, prior to the recipient answering.<p>That 'seems' innocuous (and both Signal and WebRTC had reasonable arguments around expecting that behaviour) but this follow-up exploit looks more serious, and the researcher is correct to note how an expanded attack surface can lead to problems like this :/
It's fixed and updated.<p>But this demonstrates how much advantages open-source software has, this transparency does pay off with users who are gradually paying attention to the technology and security landscapes.
It thrills me to no end that there aren’t a bunch of snarky comments about “OH THIS PROVES SIGNAL IS A TOOL OF THE NSA!!”.<p>Open-source software is great because you can find bugs like this by inspecting the software. Anything that is related to personal communications should be open-source.