Signal: Incoming call can be connected without user interaction

Signal: Incoming call can be connected without user interaction(bugs.chromium.org)

231 points by iamd3vil 6 years ago | 30 comments

wolf550e 6 years ago |

Two separate issues:

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.

thinkbud 6 years ago | |

Deja Vu.

> 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"

pushedx 6 years ago | | |

And what’s the common theme here? Naive switch statement logic instead of a real state machine with fully mapped transitions.

wolf550e 6 years ago | | |

Yes, it's a classic bug, also reminds me of https://mitls.org/pages/attacks/SMACK#skip

loeg 6 years ago | |

> State machine bug in Signal app

Exploitable in the Android Signal app in particular; not the iOS one.

zenexer 6 years ago | | |

It’s potentially exploitable on iOS, but a UI issue has so far prevented the exploit from being useful. That’s not to say it couldn’t be exploited in a useful manner, and the vulnerability is still present. Continuing to use an unpatched version on iOS would be high-risk.

Avery3R 6 years ago |

The bug tracker requires javascript, transcript for anyone that doesn't want to enable it:

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);
  }

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.

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.

bArray 6 years ago | |

Thank you, why absolutely no text can be displayed without JS enabled is beyond me. The page source is filled to the brim with trackers.

craftyguy 6 years ago | | |

> The page source is filled to the brim with trackers.

I would expect nothing less from a site owned by google.

jka 6 years ago |

It looks like this was shortly preceded by https://bugs.chromium.org/p/project-zero/issues/detail?id=19... 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.

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 :/

aminecodes 6 years ago |

It's fixed and updated.

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.

hprotagonist 6 years ago |

fixed for a week. Update and you should be good.

Koffiepoeder 6 years ago | |

What I don't understand is:

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?

kbenson 6 years ago | | |

Because blackhats look through updates to determine what has been fixed by reversing the change, and try to capitalize on the time between an update being available and it being widely deployed. The more you raise awareness of people that might be susceptible to attack in that time frame to get them to update sooner than automated systems would allow, the less victims there are to exploit.

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.

ilikepi 6 years ago | | |

Well, even if the bug report wasn't disclosed, there's a decent chance it was reverse engineered out of the patch that was released a week ago by anyone with enough determination. It seems like the act of disclosing it soon after the patch is available allows information to propagate through the security community, which in theory helps accelerate the spread of the update.

the8472 6 years ago | | |

People need to know when to update. Disclosure provides an incentive to do so, especially in corporate eenvironments.

Hackers on the other hand don't need to be informed, they can always look for juicy bugs the moment fixes are rolled out.

tpush 6 years ago | | |

A hacker doesn't need the disclosure if a patch is already available.

josh2600 6 years ago |

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!!”.

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.

askmike 6 years ago | |

I think open-source software is great as well, but assuming these kind of bugs are found because you can inspect the code is very wishful thinking that doesn't always hold up.

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

feanaro 6 years ago | | |

The fact it's open source enabled someone outside the project to find it in practice. While also possible with closed source software, if you think the bar is possibly too high with an open source project, it is an order of magnitude higher with closed source.

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.

o-__-o 6 years ago | | |

Do you know what your app library dependency is doing? They talked about advertising and that got people up in a roar... but what if it’s doing reconnaissance? Mapping out your build and deploy infrastructure because you fetch externally from 12 different locations along your pipeline. Then one day they target a specific company in a patch release and then fix it later. In a high release project you would never know.

Who’s got your back on that?

t34543 6 years ago | | |

What it does mean is that the community can fix it, and you don’t have to divert time from a product approved sprint to fix sec bugs.

craftyguy 6 years ago | |

> 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!!”.

There are no such comments here as of this post, or are you lost?

filoleg 6 years ago | | |

That’s exactly what the OP said, i think you might be reading it wrong.

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); }