In a few past pieces, I've outlined how the app sandbox and the current version of Seatbelt work on MacOS. I started looking at these two systems because I was interested in how Safari is sandboxed and how you can break out of the sandbox after exploiting Safari itself. Remember, compromising Safari would be only the first step. Safari runs in a kernel-enforced sandbox, and all that compromising Safari could do is give you code execution in a limited process with a controlled environment. To get arbitrary code execution, you need to break out of the sandbox too.

We haven't traced through execution yet, but we know that when a system call is dispatched into the kernel by a sandboxed process, the kernel will check to see if that call is allowed via a hook inserted into the requested system call. If the call is permitted, the hooked call will continue with execution as if the sandbox isn't present. If the call isn't, the call will fail, though the process will generally not terminate.

So what's our attack surface and how can we use it to break out?

Incorrect Policies

The first possible attack vector, once you have control of the sandboxed process, is the policy describing the execution environment. If the policy isn't strict enough, or it contains a bug, we may be able to exploit that bug and escape the sandbox. For example, in a malformed sandbox, it may be possible to, say, spawn a new process without the sandboxing constraints imposed by the parent process. Or, perhaps, you can access a system service, like cron or at, that allows you to schedule a process for later execution, again without the sandbox protections.

Exposed Services

In the previous example, we used services that were exposed by mistake. What about services that are deliberately exposed to the sandboxed process? If that process has access to a system daemon of some kind, say a messaging or mail daemon or a logging system, and that external service has a bug, you may be able to exploit that bug to obtain free system access.

Exposed Files 

What if the policy gives you access to files that are loaded by other, non-sandboxed programs? If so, you can potentially overwrite those files with data you control. You can potentially convince those external applications to do all kinds of things, depending on the program. If that program has a flaw you can exploit, this is another possible avenue for exploitation and access.

Sandbox Services 

Remember, the sandbox itself contains internal services that you can still potentially access after the program is first invoked. Now, most of the work of sandboxing a process happens on program invocation, so if you're attacking a running, previously sandboxed program like Safari, you won't be able to access these call chains. But some of the sandbox services are accessible throughout the process lifecycle. Notably, the sandboxing checks themselves within the kernel and the sandbox logging system hosted by the sandboxed logging and tracing daemon.

That's a quick overview of the major features of the app sandbox attack surface. No matter which attack vector you choose, the existence of the sandbox doubles your work, forcing you to find another exploitable flaw after first compromising Safari. Now, with this outline, we're going to start tracing sandbox execution and beginning to touch on these specific vectors in more detail.