[ringshall]

> "There are almost certainly multiple vulnerabilities at play here, since long gone are the days where a single vuln gave arbitrary code execution"

Could you go into this in a little more detail?

I'm inferring that chains of vulnerabilities are needed to go from some starting point to arbitrary code execution. Is that correct?

Have efforts to secure computer systems over the past ~2 decades succeeded, at least in that much more effort needs to be invested in order to get to the point of arbitrary code execution?

[roblabla]

For the most part, yes, it's much harder to get ACE today than it was 20 years ago, and even then ACE doesn't actually grant you any fancy capabilities on a modern phone.

To get ACE, you will generally need a couple of primitives, such as an ArbR/ArbW coupled with an infoleak to get ROP. This will allow you to execute arbitrary code, but you're still stuck within the confines of the current process' privileges. Phone apps are generally heavily sandboxed, and the web browsers tend to be sandboxed even harder. Having ACE in some arbitrary process won't give you the ability to do anything: filesystem will still be out of reach, most of the time you won't even be able to see other processes or even make network requests. So you'll need to break the sandbox.

Breaking the sandbox tend to involve looking for an RCE in a process outside the sandbox that you can communicating with over an IPC channel. And you'll likely need to do this twice: once to break free of the browser sandbox, and once to break the "App" sandbox. If we take a look at chrome for instance (which is very well documented[0][1]), they have sandboxing mechanisms built-in to disallow access to most resources (like the filesystem) to most of its processes, and to prevent access to most of the kernel API surface. And then Android further sandboxes all apps to disallow them from accessing each-other's data. So again you'd have to find another bug somewhere to bypass this.

There are tons of mitigations techniques being developed to make bugs harder to exploit, from Pointer Authentication (making it much harder to exploit ArbR/ArbW bugs) to Control Flow Integrity (making it much harder to create a ROP chain). Of course, not all apps actually have those mitigations in place, but the web browsers tend to enable most, for instance chrome has CFI enabled[2].

[0]: https://chromium.googlesource.com/chromium/src/+/master/docs...

[1]: https://chromium.googlesource.com/chromium/src.git/+/master/...

[2]: https://www.chromium.org/developers/testing/control-flow-int...

[erikmolin]

Would you mind expanding the acronyms? This is super interesting, but hard to follow (and also somewhat hard to google, apparently Arbr is a bike brand)

[roblabla]

Ah, can't edit the comment anymore but:

RCE: Remote Code Execution. It's fairly straightforward, but basically any vulnerability that allows you to run (native) code without physical access to the phone (e.g. when a user visits a website).

ACE: Arbitrary Code Execution. Basically any technique that allows taking control of the execution to execute your own arbitrary code.

ArbR/ArbW/ArbCall: Arbitrary Read, Arbitrary Write, Arbitrary Call primitives. They tend to be the "basic unit" which you can weave together to further poke at things once you've gained ROP.

ROP: Return Oriented Programming, a technique used to take control of execution when you have the ability to overwrite the Return Pointer of the current stack frame (for instance, from a stack buffer overflow). ROP is used because nowadays, most processes adhere to W^X (Write Xor Execute, basically a memory page is never both writable and executable at the same time), meaning we can't just inject shellcode and jump to it anymore. You can find a small tutorial on ROP at [1].

ROP This can then be used to generate various primitives (ArbW can be achieved by weaving together a "ROP Chain" that calls memcpy with the right registers, for instance).

IPC: Inter-Process Communication. Imagine a Unix Pipe, where two processes communicate with each-other over stdin/stdout. This is an example of an IPC. There are other IPC mechanisms (D-Bus, Unix Sockets, localhost...). When a process is sandboxed, it will sometimes need access to things beyond its sandbox (like accessing the filesystem to access a cached image or something). To do so, it will talk to another process over an IPC mechanism, with a well-defined protocol.

[1]: https://tc.gts3.org/cs6265/2019/tut/tut06-01-rop.html

[iudqnolq]

Guessing partly, but maybe ArbR = arbitrary read, ArbW = arbitrary write, RCE = remote code execution, IPC = inter process communication.

[pbhjpbhj]

ACE arbitrary code execution

RCE remote code execution

ROP return-oriented programming, which I understand to be using code already on the target and manipulating code flow in order to piece together the boots of programme to execute a routine of the attackers choosing (like cutting letters out of a newspaper to make a ransom note!), https://en.m.wikipedia.org/wiki/Return-oriented_programming

[CGamesPlay]

Yes. For example, webpages viewed in Safari are sandboxed. You can't run arbitrary code to affect parts other webpages. So they had to break out of that.

All apps, including Safari, are sandboxed. Apps can't run arbitrary code to affect other apps. So they had to break out of that.

The system itself is sandboxed. Restarting the phone resets it, in many ways, to a "known" state. So they had to install something that would persist across rebooting the phone.

[stepstop]

Yes you’re correct about the chains. For examples, look at Stuxnet or some of the more expensive Chrome bug bounties over the past few years.