https://bugs.chromium.org/p/project-zero/issues/detail?id=19...
webrtc data being handled before call answered, problematic in theory, Moxie can't get webrtc upstream to fix it (https://twitter.com/moxie/status/1180226374851710976), not fixed yet.
https://bugs.chromium.org/p/project-zero/issues/detail?id=19...
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 (https://twitter.com/moxie/status/1180261210341511168), fixed same day.
> you can send the callee the message the caller gets when the callee answers
This is the exact same type of bug that was in libssh: https://www.nccgroup.trust/uk/our-research/technical-advisor...
"possible to bypass authentication by presenting to the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication"
Also, Apple had a FaceTime bug of very similar nature:
https://www.theverge.com/2019/1/28/18201383/apple-facetime-b...
"you begin calling somebody via FaceTime Video from within the Phone app. Before that person picks up, you can swipe up to add your own phone number to the call. Once you’ve added yourself, FaceTime immediately seems to assume it’s an active conference call and begins sending the audio of the person you’re calling"
Exploitable in the Android Signal app in particular; not the iOS one.
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.
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.
To reproduce this problem on the Android client, replace the method handleSetMuteAudio in the file WebRtcCallService.java with the following method.
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);
}
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.
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 :/
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.
I'm a big fan of maintaining a forced 90 day disclosure period to pressure companies that do not address relevant security bugs.
But why, when a security issue is fixed, whitehats tend to always disclose immediately? Since it is fixed it is not relevant any more, and disclosing now only increases the likelihood of a hacker abusing the bug. Instead wouldn't it be better if the targeted entity just disclosed that "a critical security vulnerability was found" and that "users should upgrade immediately"?
I don't see the point of disclosing the specifics of a fixed security vulnerability soon after the fix? I understand that recognition is an important factor, but isn't it more logical to delay the recognition step for e. g. 6 months?
I imagine there's probably a short time after update release, almost definitely in the single or double digit hours range, where you might be helping the blackhat that would reverse it do it quicker, but it's probably hard to do more harm than benefit by releasing the details earlier than later.
Hackers on the other hand don't need to be informed, they can always look for juicy bugs the moment fixes are rolled out.
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.
This specific example required a Google department to find it. Who would have found it if Google got restrained by the NSA?. Other notable examples include openSSL.
On top of that, here is a great talk about how easy it would be to infiltrate open source projects: https://www.youtube.com/watch?v=fwcl17Q0bpk
Also, please don't say "Google". A bunch of hackers (on Google's payroll) found it, not Google. We can't tell what would've happened in a counterfactual universe where Google was not financing Project Zero.
Who’s got your back on that?