Hacker News Reader

Comment by mgraczyk | Hacker News Reader

Since the issue was in both the iOS and Android versions of the app, and it was caused by an integer overflow, does that mean that the bug was in a bundled C++ library implementing webRTC? Is there any information about the source-level cause of the issue?

View on HN

Notably on iOS there's no good way to isolate unsafe native libraries from the rest of your app without violating app store policies, because Apple enforces apps to be single process and doesn't allow use of its own sandboxing apis.

You have to understand, they enforce those rules for security reasons. /s

When most code is Objective-C it hardly matters anyway.

You only need a bug in a single line of code of your dependency to compromise the whole app. Most of the code doesn’t matter for security.

The usual argument that safer languages are needless, because bugs happen anyway, yet Apple is going Swift, and adopting hardware mitigations to fix these kind of issues.

Hardware mitigations which you can’t use?

I'm pretty sure they're talking about things like PAC, which are are definitely available to apps (and I think even required?).

Not for third party apps, the ABI is not stable yet.

Regardless of the actual usage surface, its need is seen as relevant enough for Apple management to release the necessary budget to spend in engineering to make it happen across the whole stack.

Plenty of mobile code, especially at large companies like this, rely on a ton of C code. It makes it easier to support features on both Android and iOS. I’m sure there are more benefits I’m not aware of.

Benefits that security researchers appreciate as job security.

I believe you’re able to use XPC Services to achieve that no?

Edit: actually no, XPC Services are Mac only so wouldn’t help on iOS.

WASI would be the closest thing to a secure runtime

You can compile your less trusted libraries to webassembly and then run them in a webview?

That sounds like a huge hit to energy use, if it is even feasible for something like implementing webrtc because of communication costs with the native process.

Hrm. If you had a specific WASM engine embedded in the app, you might be able to get it to precompile the bytecode (to avoid violating the runtime modification policy); that might be low-enough overhead (since you also control the communications layer & could make it cheaper).

Video decoder in bytecode?

It seems this way. "RCE via crafted media file" generally points to various media codecs and other processing that is implemented in native.

Reply on news.ycombinator.com