
Exploiting Android Messengers with WebRTC - alicewonderland
https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-3.html?m=1
======
ardy42
Title is misleading. The actual article headline is "Exploiting Android
Messengers with WebRTC: Part 3"

Also, this exploit didn't just affect Signal (it affected Google Duo too, for
instance), and it appears this has already been patched in Signal:

> This exploit was performed on Signal 4.53.6 which was released on January
> 13, 2020, as Bug 376 had already been patched in Signal by the time I
> finished the exploit. CVE-2020-6514 was also fixed in later versions, and
> ASCONF has also been disabled in usrsctp, so the code that caused Bug 376 is
> no longer reachable. Signal has also recently implemented a feature that
> requires user interaction for the WebRTC connection to be started when the
> caller is not in the callee’s contacts. Signal has also stopped using SCTP
> in their beta version, and plans to add this change to the release client
> once it is tested. The source for this exploit is available here.

------
aneutron
> Facebook Messenger downloads these libraries dynamically as opposed to
> including them in the APK, so it is difficult to identify the version I
> examined, but it was downloaded on June 22, 2020.

This right here, is something that scares me. I wonder if this would fly on
Apple's AppStore for example. Because there's virtually no way to attest to
the application's binaries (for example for forensic purposes), and it can
easily be used to backdoor the app on the fly.

~~~
abhayb
Some amount of post-install runtime loading is basically necessary on Android
if you're using shared native libs. Can't remember off the top of my head what
needs to happen but basically every app runs into strange crashes until they
start packaging their .so as a resource and then loading it in
Application.onCreate. Chrome does this so it's at least de facto allowed.

Google has to allow dynamic loading at app start because of this. Or fix
whatever subtle interaction between Android and an OEM's "improvements" is
causing this. Not a huge step from here to getting your library from the
internet instead of bundled with the app.

Not trying to justify any one app's behavior, just bringing up a fundamental
reality baked into what you're saying: Apple doesn't have to deal with the
gaps in its security model becoming load bearing features.

~~~
vlovich123
I don't follow. Google could lock this down if they wanted to. They own
System.loadLibrary, dlopen, and the kernel. If they wanted to enforce that
native libraries were covered by the same signature as signed the APK they
could. Maybe not now that the horse has bolted.

------
upofadown
From the article:

>WebRTC does not pose a substantially different risk than other video
conferencing solutions, but the decision to include video conferencing in an
application introduces a large remote attack surface that wouldn’t be there
otherwise.

Adding features pretty much always takes away from security. This seems to be
a pretty good example of the principle.

------
Sean-Der
One thing to note is that this is an issue in Google’s implementation of
WebRTC. I wish the marketing gimmicks would stop and they would acknowledge
outside efforts. Stuff like this hurts the perception of WebRTC which is a
shame.

We are seeing more and more memory safe implementations of WebRTC. So I really
think there is light at the end of the tunnel!

* [https://github.com/pion/webrtc](https://github.com/pion/webrtc)

* [https://github.com/shinyoshiaki/werift-webrtc](https://github.com/shinyoshiaki/werift-webrtc)

Chromium itself sees constant CVEs so I don’t think this is a WebRTC specific
issue. Documents like [https://www.chromium.org/Home/chromium-security/memory-
safet...](https://www.chromium.org/Home/chromium-security/memory-safety) give
me hope.

~~~
bawolff
What marketing gimicks do you mean?

------
cameronbrown
Desktop version: [https://googleprojectzero.blogspot.com/2020/08/exploiting-
an...](https://googleprojectzero.blogspot.com/2020/08/exploiting-android-
messengers-part-3.html?m=0)

------
cptroot
Worth noting that several of the bugs this exploit depends on were fixed
earlier this year.

~~~
est31
They were but fixes didn't make it downstream.

> This research showed that many applications fall behind with regard to
> applying security updates to WebRTC. Bug 376 was fixed in September of 2019,
> yet only two of the 14 applications analyzed had patched it.

------
tptacek
One question this whole saga raises with me is why WebRTC bothers using SCTP
for this corner case of the protocol suite at all. It seems like _a lot_ of
complexity to add, for marginal benefit.

~~~
cjbprime
It's especially odd since WebRTC DataChannels actually use SCTP-tunneled-
inside-UDP, rather than router-level SCTP datagrams.

~~~
rjsw
The comments in the Firefox WebRTC code state that this is because firewalls
can't do NAT of SCTP connections. I'm part way through adding this to the
firewall that I use.

On FreeBSD, WebRTC implementations could use the kernel stack as it implements
SCTP-in-UDP (RFC6951).

~~~
Sean-Der
For WebRTC SCTP is over DTLS (which is over UDP) so I don't think that would
work.

Never done 'native SCTP' before so I don't know for sure!

------
oyebenny
For pentesting purposes, can someone give me a guide on how to test this
exploit?

~~~
cjbprime
You'd have to completely reproduce the research in the blog post.

------
Dunedan
According to the blog post not only Signal, but multiple messengers were
affected. Therefore the official title is more accurate: "Exploiting Android
Messengers with WebRTC"

~~~
dang
Fixed. Thanks!

(Submitted title was 'Project Zero Released a Zero-Click Exploit for Signal')

------
arusahni
B-b-but Project Zero only targets non-Google properties!

