Exploiting Android Messengers with WebRTC | Hacker News Reader

Exploiting Android Messengers with WebRTC

googleprojectzero.blogspot.com

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.

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

They might be using App Bundles dynamic delivery [1] on Android, in which case this isn't really an issue. Helps keep the initial download size small, while allowing larger features to be delivered on-demand.

https://developer.android.com/guide/app-bundle/dynamic-deliv...

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.

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.

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.

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/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... give me hope.

What marketing gimicks do you mean?

Desktop version: https://googleprojectzero.blogspot.com/2020/08/exploiting-an...

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

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.

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.

DataChannels themselves are hugely important. Projects like Tor Snowflake and WebTorrent really inspire me.

I don’t think there was really an alternative at the time if you wanted feature rich DataChannels. Maybe we could stuck with the simpler RTP Datachannel. All that conversation was before I was aware of WebRTC though.

I personally don’t find SCTP that complex. You can implement a basic version pretty easily. Implementing the full spec is overwhelming for sure. I feel pretty confident saying any alternative protocol that is feature rich written in C/C++ will have issues as well.

Can you say more about how DataChannels are "hugely important" to the common-case use of WebRTC? Adding a whole additional (complicated!) transport protocol just to get WebTorrent seems like the definition of "marginal returns".

In 2018 Google claimed they were seeing 3 Petabytes weekly from DataChannel usage. This is from the 2018 KrankyGeek talk.

For me personally I use DataChannels pretty extensively for Teleoperation work. Also project like https://github.com/nurdism/neko and https://github.com/giongto35/cloud-game are pretty compelling.

3 out of 8 ‘official use cases’ depend on it. https://www.w3.org/TR/webrtc-nv-use-cases/ as well.

Oh I also think great for E2E security. It is better to exchange metadata and keys via a DataChannel. If you push that stuff through signaling there is a good amount of information leaking.

The question isn't why WebRTC has a DataChannel feature. It's why the DataChannel feature is as complicated as it is. Why not just use UDP? What's the return on all the complexity the protocol suite is spending?

Ah, sorry missed the question :(

I think just so users don’t have to solve the same problem themselves. SCTP gets you multiple streams and they can be ordered/reliable if you want.

The congestion control is pretty impressive. You can jump the TSN forward if you send a bunch of data but lose one Datagram in the middle. Cool stuff like that.

That's why literally every feature exists. The question is what the return on that feature is. If most applications don't get any value from the additional complexity of SCTP, and SCTP itself causes implementation flaws that harm users, the feature is not benign.

Having an unreliable transport option is essentially for real time networked multiplayer games.

But really, why the hell did it have to take almost a decade to get data channels, when you could jump through a bunch of hoops and essentially build a software dial up modem and transmit data over audio streams? Reminds me of the "minutes vs. texts vs. data" billing nonsense with cell phones. You trying to tell me audio and video aren't data?

Sure, which is why games tend to use UDP for this. UDP is much simpler than SCTP, and, more importantly, it's already built into the stack.

Yeah, I think it's actually the reverse: the SCTP is being tunneled inside UDP anyway, and adding in SCTP allows for a reliable channel to be built on top of the unreliable primitive. i.e. SCTP is used by DataChannels to add the option of reliable transport (and congestion and flow control) to them.

SCTP doesn't simply add reliability; you can get reliability from UDP trivially.

I really don't think it is that trivial!

* SCTP allows multiple independent streams

* Each streams have different rules on reliability/ordering

* SCTP does congestion control and reports back to the user your estimated bandwidth so your application can change what it is doing.

Yes, those are all features beyond reliability. If all you need is reliable transport of some sort, you don't need these.

If all we can do is list reasons why SCTP is an interesting and useful protocol, we're at an impasse, because I like SCTP. I just don't know that it belonged in this design, where most applications that want WebRTC for simple use cases are paying a complexity and security cost to make it simpler (not even "feasible", just "easier") to build things like WebTorrent.

Ah ok. So the question is more ‘does WebRTC need the complexity’. I think so, reliable transport is pretty useless without backpressure.

So here are the recent projects I have worked with that need the complexity.

* Teleoperation - Robot control went over reliable stream. Metadata goes over lossless stream, we don’t care about sensor readings 3 seconds ago.

* File Transfer - If you send too fast you will cause complete loss. You also need to measure constantly since link quality will fluctuate.

* Large Image Transfer - SCTP also handles breaking up messages to fit MTU. If you just send UDP Datagram you need to probe how big of packers you can actually send.

* Unreliable Large Image Transfer - If you don’t care if an image arrives and you lose packet 1 you shouldn’t send the rest of the Datagram. This was big for a project, saved a lot of bandwidth making sure we didn’t complete corrupted messages.

These are all extreme niche cases for WebRTC, aren't they? Niche, here, relative to actual usage, not "number of apps".

If the overwhelming majority of daily invocations of WebRTC protocols is due to simple videoconferencing applications, and all those invocations have to pay a complexity and security tax in order to potentially enable someone else's "teleoperation", that's a misallocation, isn't it?

Congestion control seems pretty important for videoconferencing, especially given that these are mobile apps that are especially prone to signal degradation/tower switching that will drastically affect throughput. I'd argue that being able to fall back to reliable text chat when your network is imploding and video/audio is unusable is a core feature of web conferencing tools.

This isn't the channel used for videoconferencing!

TIL! That definitely makes the use case a lot more dubious.

Doing some googling, I'm wondering whether the original intent was to switch everything over to SCTP: data channels seem to have used the same protocol as media pre-2014. Maybe no one got around to it and things ossified?

Congestion Control still works though between the two protocols!

SCTP and RTP try and respect each other. It follows the same rules as having multiple people using WebRTC on the same internet.

That's... besides the point? The argument isn't that SCTP is a bad protocol.

But we didn't have any option to use UDP from the web stack prior to Data Channels.

I guess worries about security trump "make the web stack do everything" though.

I'm not debating whether Data Channels are useful. I'm debating whether they should be backed by SCTP.

Curious about your axe to grind with SCTP. Is it just that you feel the features of SCTP would be better implemented a la carte by applications? Are there other issues?

I haven't really used the protocol, the extent of my knowledge was reading about it back in 2011 and thinking "cool".

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

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).

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!

I think the big piece is DTLS here.

* OpenSSL was already in all the browsers, so you have a DTLS client.

* Extracting the keys for SRTP gives you PFS, which is really great! This came up a lot during the SDES conversations.

* I have heard that most gateways only support UDP/TCP, and other protocols aren't going to happen. That is the argument for running QUIC over UDP (vs a layer lower)

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

Article contains link to CVE with POC(s)..

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

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"

Yeah, the title should be changed.

Fixed. Thanks!

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

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

Reply on news.ycombinator.com