FORCEDENTRY: Sandbox Escape
googleprojectzero.blogspot.com
googleprojectzero.blogspot.com
https://googleprojectzero.blogspot.com/2020/01/remote-iphone...
https://googleprojectzero.blogspot.com/2019/08/the-many-poss...
This is always a bad idea. If you want a callback, register it manually so only registered functions are available.
Java serialization and Log4J made same style of security bug.
Note that if you actually wanted to make the attack harder here I'd go after the NSPredicate evaluation instead, which you can see in the blog post is done without checking the sender, rather than going after what the predicate itself can do.
A system that only allows a small set of permitted functions, or implements hard-coded functions like the first version (min, max, avg) just seems far more ... reasonable.
It's the job of an API framework provider to be defensive against these kinds of vectors especially when they may not deprecate this for like, 10+ years. How this made it through Apple's API review is beyond me.
If I saw someone try and pull something like this at the office I would immediately make sure the design was rejected.
NSPredicate is serialisable because you might want to include it in e.g. a schema. These schemas would be loaded from the app bundle so there’s no security concerns unless your threat model includes modifying the app bundle (which is more of an OS level issue).
The issue is that the serialization needs to distinguish between data that is serialized by the developer of the app at build-time, and data that is serialized at runtime.
I think NSPredicate, even a serializable one, makes sense. What doesn't make any sense is arbitrary selector invocation. Not just because it's a security risk, but also because it's a stringly-typed method name that isn't checked by the compiler. The name of the selector changing would just cause it to crash - without a compile-time check. A plist with a serialized selector that no longer exists would cause the app to crash. A plist with a malicious selector would cause the app to crash. And crashing seems like a best case outcome.
I think allowing things like NSFunctionExpressions are ok, but you need to have an explicit namespace, and the default needs to be an empty namespace, not the current/full namespace. Having a default is a good idea because if you don't add one as an API designer, other people creating wrappers around your library will, so at least try to make the default safe. It sounds like that is somewhat similar to your idea of registering a function.
[1]: See in particular the part of the original NeXT presentation right after intermission, with demos of gluing together high-level components using Interface Builder. https://www.youtube.com/watch?v=92NNyd3m79I
> The expressive power of NSXPC just seems fundamentally ill-suited for use across sandbox boundaries, even though it was designed with exactly that in mind.
It reminds me of the YAML deserialization vulnerabilities that plagued Rails. It's clearly necessary to ensure that any data received from an untrusted source is merely data, with no generic way of instantiating arbitrary classes.
I suspect it was inspired by the whole "data is code" philosophy of lisp languages, but it seemed like a well thought out pattern for encoding and decoding data in relatively safe ways. It had a way of tagging fields to indicate that they required processing to derive the decoded value, e.g.
#inst "1985-04-12T23:20:50.52Z"
In effect the format split the work of parsing the data from decoding the data, which is a distinction I haven't seen in many other data encoding mechanisms.
If you happen to think, as I do, that we need safe(r) languages to have any hope of creating secure systems, then problems like these are a striking reminder that memory safety alone isn’t sufficient to achieve security.
Modern serialization frameworks all seem to have moved to a no-polymorphic instantiations model. Eg when deserialising a field of type X, they will only deserialise into an X.
What's the long-term solution for these kinds of problems? How can we get out of this tar pit? Of course in the short run we can be dilligent about updates and bug bounties etc, but how can we actually eliminate these kinds of errors in a 'complete' way?
Have you ever heard of the `swiss cheese method of security`, where each slice of cheese has a hole in it? The idea being: each slice may have a hole, but when sandwiched together, the route of entry is blocked. I've heard the adage: 'complexity enlarges the attack surface' before, but not in all cases especially. Sometimes security 'maxims' get in the way of security.
Now, there are certainly advantages different languages have in ease of writing tests and things like that. There's also formal verification. But unlike memory errors, it's impossible to know if you told the computer to do something you didn't intend.
It's true you'll never be able to catch all logic errors automatically, partly because you need full correctness specifications for that.
But languages like Rust with powerful static type systems can catch lots more important logic errors than C, or C++ --- e.g. using typestate (catches bugs with operations on values in incorrect states), affine types (catches bugs with operations on "dead" values), newtypes (e.g. lets you distinguish sanitized vs unsanitized strings), sum types (avoids bugs where "magic values" (e.g. errors) are treated as "normal values").
Also modern languages like Swift, and Rust to a lesser extent, are treating integer overflow as an error instead of just allowing it (or worse, treating it as UB).
Eventually it was removed. https://pcwalton.github.io/2012/12/26/typestate-is-dead.html
> The reason was that “in practice, it found little use”
And of course the proof is only for those properties that you write down, and you could also have a bug in the spec for those properties.
The best hope for legacy C and C++ code right now is a combination of extensive fuzzing and dynamic analysis to detect as many memory corruption bugs as you can, plus mitigations in CPUs and compilers to make it harder to turn memory corruption bugs into malicious execution, plus sandboxing to limit the damage of malicious execution. This exploit chain demonstrates techniques to bypass that entire mitigation stage (and also shows that Apple severely bungled their sandbox design).
This doesn't bode well for the mitigation approach. They add significant complexity to the silicon and software stack, which has a cost in performance, but also ultimately security --- at some point we will see these mitigations themselves contributing to attack vectors. In return they make exploitation a lot more difficult, but mitigation bypass techniques can often be packaged and reused. For example stack overflow techniques have been effectively mitigated but that doesn't matter to attackers these days, who are now very good at using heap overflow and UAF. Meanwhile those stack overflow mitigations (stack cookies etc) still have to remain in place, making our systems more complex and slower.
The WUFFS code to do this sort of stuff (parse file data, turn it into an array of RGB pixel values) is not only inherently safe, it's also typically faster than you'd write in C or C++ because the safety gives programmers that fearlessness Rust talks about for concurrency. The language is going to catch you every single time you fall, so, you get completely comfortable doing ludicrous acrobatics knowing worst case is a compiler diagnostic or a unit test fails and try again. When you have a hidden array overflow in C++ it's Undefined Behaviour, when you have a hidden array overflow in (safe) Rust it's a runtime Panic, when you have a hidden array overflow in WUFFS that's not a valid WUFFS program, it will not compile now it's not so hidden any more.
So you're right, this doesn't bode well for mitigation - the answer isn't "more complex and slower" but "use the correct tools".
Unlike Rust, WUFFS isn't a general purpose language it can only express a subset of possible programs. For example, WUFFS can't express the program NSO wanted here ("Provide a way to escape from this sandbox") whereas of course in a general purpose language that would feel annoyingly restrictive. What if you want to escape from the sandbox?
WUFFS is exactly the right tool for, say, parsing a file you received to turn it into an image for display on the iPhone's screen.
Except, of course, if your focus is on features at all costs. If you don't care about security then it sucks that WUFFS can't take a file and maybe overwrite the operating system or whatever.
> By sending a .gif iMessage attachment (which was really a PDF) NSO were able to remotely trigger a heap buffer overflow in the ImageIO JBIG2 decoder.
While rewritting the world is not possible, all these attacks show that definitely new systems should probably not be written in memory unsafe languages.
> Late last year we published a writeup of the initial remote code execution stage of FORCEDENTRY, the zero-click iMessage exploit attributed by Citizen Lab to NSO.
The sandbox escape only uses logic bugs:
> In this post we'll take a look at that sandbox escape. It's notable for using only logic bugs.