You Can't Spell WebRTC Without RCE – Part 1 | Hacker News Reader

You Can't Spell WebRTC Without RCE – Part 1

margin.re

58 pointsementally10 comments

Signal should separate WebRTC handling into its own process so that an exploit doesn’t have access to its critical database.

A messaging app has almost all the same security concerns as a browser, so the recommendations here apply: https://developer.apple.com/documentation/browserenginekit

Apple unfortunately declared XPC to be a private API on iOS, whereas on macOS it is the foundation for sandboxing custom services.

I found no way to sandbox things beyond the sandboxes provided by iOS extension points (which are mostly XPC under the hood, but with no control options for the app).

Apple makes heavy use of XPC to sandbox iMessage services, but on iOS that remains an Apple-only feature.

Oh interesting, you have to use browserenginekit to use multiple processes.

This honestly doesn't surprise me all that much. More than 10 years ago I had to dive into Chrome's WebRTC stack for interop and reverse-engineering purposes (at the time, the WebRTC specs were changing all the time, and were poorly documented). The code was massive; it turns out it's a fairly complicated protocol, and dealing with audio and video and handling sessions (even without including a signaling protocol) requires a lot of code (not to mention the use of the then-obscure DTLS security protocol on top of UDP). And that was 12 years ago; I'm sure WebRTC's surface area has only increased since then.

I assume Signal uses a different implementation, but I'm sadly not surprised there are security issues lurking inside it.

This bit at the beginning made me chuckle, though:

> It’s another average Friday morning and my iPhone shows 705 unread Signal messages

I feel like I'm doing communications wrong... if I wake up and find 20 unread messages across all my chat apps, that's on the high side for me.

My personal phone is lucky to get more than 5 a day. My work phone gets hundreds a day, due to automation and slack ops.

Regardless, I think a handful of high quality meaningful messages is well worth hundreds of low value ones.

To be clear, they are not demonstrating issues in the code, they are providing a walkthrough of how one _could_ exploit an issue if one existed and the mitigations weren't in place, as an concrete introduction to how this is done against a mobile app.

e.g. “Given a vulnerability, this is what crafting an exploit looks like”

As we dive into Apple iPhone iOS, we show how to build Signal/iOS, but first let us show you Signal/Android because our Frida tool cannot hook within iOS.

So, it is a build instruction.

> Next, let’s give ourselves an arbitrary write. To make the exploit a bit simpler, we’ll give ourselves an arbitrary memcpy.

They took Signal-webrtc & added a vulnerability to it.

Maybe maybe maybe there's some other means to exploit the lack of time check, but this feels like such a massive & overwhelmingly staked out nothing burger.

I’m also surprised by this…

They’re usually known for high quality research, not fluff like this…

“Now that we have 0-click parsing available, we need some vulnerabilities. As mentioned previously, we are not reporting any Signal 0-days in this post; the point of this series is a crash course in Signal, WebRTC, and iOS research. Let’s leverage Signal-WebRTC’s source code to inject our own vulnerability primitives and keep our research moving.”

Reply on news.ycombinator.com