Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Last year, a crazy vulnerability and exploit was discovered in PDF parsing of iOS. This exploit created a weird machine to get arbitrary code execution. However, since the messages is sandboxed, they still had to escape the sandbox. This is a post about how the sandbox escape worked.

Within the complicated weird machine is only a single call to NSFunctionExpression; there is no complicated ROP chain or anything else. This call does two things: cover its tracks and trigger a logic bug within NSPredicate. Covering the tracks is interesting but it is all about cleaning the things up, which I'll skip.

In Objective-C, there is a piece of functionality called NSPredicates. This is used for iterating over collections, such as arrays, to perform functionality. While using predicates, expressions can be used as well. This expression in a small query language, which is similar to SQL in some ways. In OS X 10.5 in 2007, the ability to use the FUNCTION keyword to invoke arbitrary methods was added.

Using these expressions, it is possible to write full-on Objective-C code. Using this, they write our code in order to exploit the sandbox issue. In particular, they make a request to NSXPC, which is a remote procedure call which allows for the instantiation of proxy objects in one process which transparently forward method calls to the "real" object in another process.

There are some restrictions on what objects can be allowed to traverse the boundaries. In particular, the objects must define as protocol for the NSXPC to designate what happens when it is invoked or used. An attack surface analysis from 2019 shows that "subclasses of classes with any level of inheritance are also allowed, as is always the case with NSKeyedUnarchiver deserialization." This means that any object which declares a particular type for a field will accept any subclass of that type, opening up the attack surface.

To dive into the exploit more, they read through the usage of the objects being exploited. While grepping through code, they found an NSXPC interface that accepted NSObject*, which would include NSPredicate. Although this looks like a game over (code execution from the expressions), there is a specific mitigation in place for this. When an NSPredicate is deserialized, a flag is set to disable the evalulation of the predicate. Good job Apple!

The protection above is an application controlled feature though; if the validation is NOT done properly, then the execution could still occur. Within the Sections, the code sets the allowEvaulation flag to true. This means that the predicate is trusted and will be ran, but they never evaluate the predicate. As a result, the predicate gives us code execution within the context of CommCenter.

Now that the attackers have the ability to execute code within the context of a process outside of the IMTranscoderAgent sandbox, they run several expressions. The final expression is to make a request to a URL to download an AES encrypted expression to evaluate this as well. This secondary payload was whatever the attackers wanted at this point, all without any memory corruption.

In response to this exploit, Apple did a two things. First, they reduced the ability of NSExpression to prevent easy code execution with a similar bug. Secondly, they added restrictions onto the PTSection and PTRow objects for parsing NSPredicates. So, good job Apple for hardening this area against future attacks.

The author of the post was quite stunned by how large this attack surface is for the sandbox. By using these tricks (NSObject pointers in protocols and library loading gadgets), all of the initWithCoder implementations could be attacked, with more code execution gadgets being found. NSXPC seems like a powerful attack surface across boundaries, even though it was designed with this exactly in mind.

The final paragraph is the most daunting to me: advent of Memory Tagging Extensions (MTE), likely shipping in multiple consumer devices across the ARM ecosystem this year...innovate too, and are likely already two steps ahead with a renewed focus on logic bugs." There is more to exploitation than memory corruption and hackers are smart. Overall, great post!