Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
<div>
<div>
<div>
<div>
<h4>Sandbox Profiles</h4> </div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p>In this blog, we will be talking about understanding how to read Sandbox Profiles in iOS. In iOS, Sandbox Profiles are configuration files that define the restrictions applied to individual daemons. The sandbox mechanism is a critical part of iOS’s security model, designed to isolate apps and system processes from each other and restrict their access to sensitive resources. This ensures that even if an application is compromised, its ability to harm the system or access unauthorized data is limited. The goal of a sandbox profile is to limit the damage that a compromised or malicious process can do to the system or other processes running on the system. iOS sandbox profiles are written in a <strong>SBPL (Sandbox Profile Language)</strong> format and are embedded into <strong>Sandbox.kext</strong> in a proprietary binary format. Apps that call the kernel or other daemons must have the appropriate sandbox profile and/or appropriate entitlements in order to access (restricted) directories or perform other sensitive operations. In fact, there are several vulnerabilities in daemons that can’t be exploited simply because there is no available attack surface from inside a Sandboxed application.</p> </div>
</div>
<div>
<div>
<h4>Where Are Sandbox Profiles Stored?
As mentioned earlier, the sandbox profiles reside in the kernel and are managed by the sandbox.kext kernel extension (com.apple.security.sandbox). When a process is launched, its associated sandbox profile is applied to it by the kernel. These profiles are typically precompiled and stored within the kernel itself. To dump these Sandbox profiles, the process involves downloading the Kernelcache, extracting the sandbox kernel extension, and then reversing it to identify the compiled profiles along with the list of Sandbox operations. This can then be passed to a tool called Sandblaster (https://github.com/cellebrite-labs/sandblaster) that can be used to dump the Sandbox Profiles. Since there are changes in the way the compilation happens for these Sandbox profiles, tools like Sandblaster need to be updated for different iOS versions. At the moment, the current version supports only 16.5 and 17.0 beta. There is a nice article from tf0labs (https://tfp0labs.com/blog/sandblaster-missing-readme) that talks about dumping sandbox profiles. Also, our on-demand course at 8ksec academy covers how to dump these Sandbox profiles as well.
Where Are Sandbox Profiles Stored?
Sandbox profiles are named based on the process or service they govern. For instance:
com.apple.WebKit.WebContent.sb governs the sandbox rules for WebKit content processes.
com.apple.mobilemail.sb is used for the Mail app.
container.sb is the Sandbox Profile applied to every app downloaded from the App store
platform.sb defines the base sandboxing rules for system-level processes.
It is important to mention that all the apps downloaded from the App Store have the same sandbox profile (named as container.sb). The difference in their permissions is therefore dependent on their entitlements that are signed by Apple.
Platform Sandbox Profile
The platform sandbox profile (platform.sb) is a key profile in iOS. It defines a baseline set of permissions for all processes running on the system. An additional profile specific to that daemon/app is applied on top of that.
Key features of the platform sandbox profile:
- Restricts access to critical system resources required for platform integrity, for e.g the mount syscall that can be used to change the properties of filesystems.
- Restricts access to sensitive data or private APIs unless explicitly permitted.
- Acts as the foundation for building more specific sandbox profiles for system services.
The WebContent process
We will be looking at several components from the Sandbox profile of the WebContent process and try to understand it. The WebContent process is a critical component in Apple’s WebKit-based applications like Safari. It is responsible for rendering web pages, executing JavaScript, and handling other web-related tasks. Due to its direct interaction with potentially untrusted web content, analyzing the WebContent process and its associated sandbox profile is essential for maintaining system security.
In fact, you will see in several exploits, it’s mention whether the exploit is reachable from the WebContent Sandbox or not. This is actually identified by reviewing the Sandbox profile of the process.
Sandbox profiles written in SBPL are composed of multiple rules listed sequentially, with later rules capable of overriding earlier ones. This approach is often used to create whitelisting profiles: first, deny all actions, and then explicitly allow only the necessary ones. Extensive testing has confirmed that the final applicable rule in a profile determines the sandbox’s decision for a given resource.
Each rule has up to four components:
1.Action: Specifies whether to allow or deny access to a resource.
2.Operations: Define the type of resource access the rule applies to.
3.Filters (optional): Restrict the rule’s scope to specific subsets of resources, such as files within a particular directory.
4.Modifiers (optional): Adjust the sandbox’s default behavior. For example, by default, only denied accesses are logged, but a modifier can change this.
This structure ensures granular control over resource access within the sandbox environment.
Let’s have a look at an example here.
(allow mach-lookup
(require-all
(require-not (global-name "com.apple.webkit.camera"))
1. Action: (allow)
•Action: allow specifies that the rule is granting permission for the specified operation(s). In this case, the rule is allowing access under certain conditions.
•Purpose: This action determines the default behavior for the resource access. The absence of this action would imply that the access is denied by default.
2. Operation: mach-lookup
•Operation: mach-lookup refers to the type of operation or resource access being controlled. Specifically, mach-lookup is related to accessing macOS Mach services, which are a low-level interprocess communication (IPC) mechanism.
•Purpose: The rule applies to processes attempting to perform a mach-lookup operation.
3. Filter: (require-all … (require-not (global-name “com.apple.webkit.camera”)))
•Filter: This restricts the scope of the rule to only apply under specific conditions. In this case:
•require-all: Specifies that all nested conditions must be true for the rule to apply.
•require-not (global-name “com.apple.webkit.camera”): Adds a condition that explicitly denies the rule if the global name (Mach service) is com.apple.webkit.camera.
4. Context and Behavior
•What it does: This rule grants access (allow) to the mach-lookup operation only if the target Mach service is not named com.apple.webkit.camera.
•Default behavior: If the Mach service’s global name is com.apple.webkit.camera, the require-not condition prevents the rule from applying, effectively denying access to that service.
In this section we will be looking at the Sandbox profile for the WebContent process and understanding some of the details there. Here are some key Aspects to Analyze in the WebContent Sandbox Profile
- File System Access:
- Ensure only necessary directories (e.g., caches or temporary files) are accessible.
- Deny write access to sensitive areas like /private/var/root/.
- Network Permissions:
- Confirm the sandbox limits network connections to approved domains or protocols.
- System Call Restrictions:
- Review syscall-unix and syscall-mach permissions to ensure only required system calls are allowed.
- Entitlements:
- Verify the use of entitlements like com.apple.private.verified-jit to restrict sensitive operations such as JIT compilation.
- Mach IPC and Kernel Routines:
- Analyze rules like mach-bootstrap, mach-kernel-endpoint, and kernel-mig-routine to confirm they are scoped to necessary interactions only.
So with that being said, let’s analyze the Sandbox profile for the WebContent process. This Sandbox Profiles is dumped for iOS 16.5 using Sandblaster (https://ift.tt/QJGywLZ). Please note than Sandbox Profiles can be very big specially for sensitive process like WebContent. In this case, the Sandbox profile for WebContent is almost 25000 lines. So it’s impossible to cover the entire thing in one blog.
Below is an excerpt from the com.apple.WebKit.WebContent.sb profile (interpreted for demonstration purposes):
For every Sandbox Profile, a default rule is necessary (in this case, “deny”) to establish whether the profile begins in a restrictive state with defined exceptions or starts in a permissive state with specified restrictions.
Mach IPC Filters
(allow mach-lookup
(require-all
(require-not (global-name "com.apple.webkit.camera"))
(require-any
(require-all
(extension com.apple.webkit.extension.mach)
(require-any
(global-name "com.apple.mobileassetd.v2")
(global-name "com.apple.iconservices")
(global-name "com.apple.mobilegestalt.xpc")
(global-name "com.apple.iphone.axserver-systemwide")
(global-name "com.apple.webinspector")
(global-name "com.apple.tccd")
(global-name "com.apple.frontboard.systemappservices")
(require-all
(require-not (xpc-service-name "com.apple.audio.toolbox.reporting.service"))
(require-not (global-name "com.apple.mobilegestalt.xpc"))
(require-not (global-name "com.apple.containermanagerd"))
(require-not (global-name "com.apple.containermanagerd.system"))
(require-not (global-name "com.apple.PowerManagement.control"))
(require-not (global-name "com.apple.diagnosticd"))
(require-not (global-name "com.apple.SystemConfiguration.configd"))
(require-not (global-name "com.apple.fontservicesd"))
(require-not (global-name "com.apple.analyticsd"))
(require-not (global-name "com.apple.aggregated"))
(require-any
(global-name "com.apple.CARenderServer")
(xpc-service-name "com.apple.MTLCompilerService")
(require-all
(require-not (global-name "com.apple.iconservices"))
(require-not (global-name "com.apple.frontboard.systemappservices"))
(require-not (xpc-service-name "com.apple.iconservices"))
(require-not (xpc-service-name-regex #".+"))
(require-any
(global-name "com.apple.system.notification_center")
(require-all
(require-not (global-name "com.apple.runningboard"))
(require-not (global-name "com.apple.lsd.mapdb"))
(require-not (global-name "com.apple.distributed_notifications@1v3"))
(require-any
(global-name "com.apple.logd.events")
(global-name "com.apple.logd")))))))))
</code>
</pre>
</div>
</div>
</div>
<div>
<div>
<p>This sandbox profile rule defines complex permissions for Mach-lookup operations, controlling which services a process can interact with. Here’s a breakdown:</p><p><b>Key Rule: allow mach-lookup</b></p><ul><li>Grants permission for mach-lookup operations under strict conditions, focusing on fine-grained control of interprocess communication (IPC) through Mach services.</li></ul><p><b>Conditions and Their Purpose</b></p><ol><li>Top-Level Block: require-all</li></ol><ul><li>require-not (global-name “com.apple.webkit.camera”):</li><li>Denies access to the global Mach service <strong>com.apple.webkit.camera</strong>.</li><li>require-any:</li><li>Access is allowed if one of the following conditions is satisfied:</li></ul><p>Subcondition 1: WebKit Extension and Global Names</p><ul><li>require-all (extension com.apple.webkit.extension.mach):</li><li>Ensures the process has the WebKit-related entitlement.</li><li>require-any (global-name checks):</li><li>Grants access to specific global Mach services:</li><li>com.apple.mobileassetd.v2, com.apple.iconservices, com.apple.mobilegestalt.xpc, etc.</li></ul><p>Subcondition 2: Restrictive Denials</p><ul><li>require-all (require-not blocks):</li><li>Denies access to the following:</li><li>com.apple.audio.toolbox.reporting.service, com.apple.containermanagerd, com.apple.PowerManagement.control, etc.</li><li>Prevents communication with services related to audio reporting, container management, diagnostics, and analytics.</li></ul><p>Subcondition 3: Conditional Allowances</p><ul><li>require-any (specific services allowed):</li><li>Grants access to:</li><li>com.apple.CARenderServer (rendering services).</li><li>com.apple.MTLCompilerService (Metal shader compilation).</li><li>Additional constraints for excluded services:</li><li>Denies com.apple.iconservices, com.apple.frontboard.systemappservices, and others.</li></ul><p>Subcondition 4: Notifications and Logging</p><ul><li>require-any (notification and logging services):</li><li>Allows access to:</li><li>com.apple.system.notification_center (system notifications).</li><li>com.apple.logd.events and com.apple.logd (logging services).</li></ul><p><b>Purpose</b></p><ul><li>Restricts unauthorized access:</li><li>Denies interaction with sensitive or critical services that could compromise security.</li><li>Enables specific functionalities:</li><li>Allows access to essential services (e.g., rendering, logging, notifications) under strict conditions.</li><li>Granular control:</li><li>Balances functionality and security by allowing only authorized processes to communicate with specific Mach services.</li></ul> </div>
</div>
<div>
<div>
<h4>Syscall Filters</h4> </div>
</div>
<div>
<div>
<p>Sandbox Profiles can also be used to restrict which syscalls are allowed from within the sandbox. This dramatically reduces the attack surface available to the kernel from userland components like WebKit for e.g.</p> </div>
</div>
<div>
<div>
<img alt="" height="332" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2025/01/image5.png?fit=768%2C332&ssl=1" width="768" /> </div>
</div>
<div>
<div>
<p><b>Key Rule: allow syscall-unix</b></p><p>Grants permission for specific Unix system calls, but only when certain conditions are met.</p><p>syscall-number SYS_sem_open:</p><ul><li>Ensures the sem_open system call is permitted for semaphore operations.</li><li>require-any<b> Block</b>:</li><li>Access is allowed <b>if at least one of the following is true</b>:</li><li>require-not:</li><li>The process <b>does not</b> have the entitlement com.apple.private.verified-jit.</li><li>OR it matches one of the following syscall-number values:</li><li>SYS___pthread_kill: Manages thread termination signals.</li><li>SYS_sigprocmask: Manages signal blocking.</li><li>SYS_fgetxattr: Retrieves extended file attributes.</li><li>SYS_openat_nocancel: Opens files relative to a directory descriptor.</li></ul><p> </p> </div>
</div>
<div>
<div>
<h4>MIG (Mach Interface Generator) Routine Filters</h4> </div>
</div>
<div>
<div>
<img alt="" height="528" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2025/01/image1.png?fit=768%2C528&ssl=1" width="768" /> </div>
</div>
<div>
<div>
<p>This governs the allowance of syscall-mig operations under specific conditions, typically for processes interacting with Mach Interface Generator (MIG) routines. MIG routines are used for communication between different parts of macOS or iOS, particularly between user-space and kernel-space processes. Here’s a detailed explanation:</p><p>This directive permits syscall-mig operations but only under the conditions defined in the subsequent blocks.</p><p><b>require-all Blocks</b></p><p>Each require-all block defines conditions that must all be met for the corresponding kernel-mig-routine to be allowed during syscall-mig. </p><p>Let’s break them down:</p><p><b>kernel-mig-routine</b></p><ul><li>Specifies a particular MIG routine by its numerical identifier.</li><li>Each identifier corresponds to a kernel operation or system call that the process is trying to access.</li></ul><p><b>entitlement-is-bool-true com.apple.private.verified-jit</b></p><ul><li>Ensures that the process has a specific entitlement: com.apple.private.verified-jit.</li><li>This entitlement is typically granted to processes requiring Just-In-Time (JIT) compilation capabilities in a controlled and secure environment.</li></ul><p>Each number represents a specific kernel operation or service, and access to these is granted only if the entitlement com.apple.private.verified-jit is true.</p> </div>
</div>
<div>
<div>
<h4>Mach Trap Filters</h4> </div>
</div>
<div>
<div>
<img alt="" height="526" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2025/01/image3.png?fit=768%2C526&ssl=1" width="768" /> </div>
</div>
<div>
<div>
<p>It grants access to specific Mach traps (kernel-level system calls for interprocess communication), but only for processes with the com.apple.private.verified-jit entitlement. This entitlement is typically associated with Just-In-Time (JIT) compilation and dynamic code execution.</p> </div>
</div>
<div>
<div>
<h4>Message Number Filters</h4> </div>
</div>
<div>
<div>
<img alt="" height="188" src="https://i0.wp.com/8ksec.io/wp-content/uploads/2025/01/image6.png?fit=768%2C188&ssl=1" width="768" /> </div>
</div>
<div>
<div>
<p>In the 3rd line, you can see that it permits the process to send or receive messages with the Mach bootstrap port using a specific <strong>msgh_id</strong>. This is part of something called mach message filters that was also discussed in this <a href="https://github.com/externalist/presentations/blob/master/2023%20Zer0con/Mobile%20Exploitation%2C%20the%20past%2C%20present%2C%20and%20future.pdf" rel="noreferrer" target="_blank">talk</a>.</p> </div>
</div>
<div>
<div>
<h4>Conclusion</h4> </div>
</div>
<div>
<div>
<p>The WebContent process plays a vital role in rendering web content securely and efficiently. Its exposure to untrusted content makes it a high-risk target for exploitation, emphasizing the importance of a robust sandbox profile. By analyzing the profile, security researchers can identify the exposed attack surfaces from inside an application. </p><p>Apple has significantly hardened the Sandbox profiles in the last few years. It therefore becomes more important to understand and analyze them before working on a vulnerability. In this blog, we learnt how to read a Sandbox profile and analyze it.</p> </div>
</div>
<div>
<div>
<h4>Explore Our On-Demand Courses</h4> </div>
</div>
<div>
<div>
<p>If you’re interested in diving deeper into topics like kernel panic analysis, vulnerability research, and low-level system debugging, <a href="https://academy.8ksec.io" rel="noreferrer" target="_blank">8ksec Academy</a> offers a wide range of on-demand courses tailored for security professionals and enthusiasts.</p><p>Visit<a href="https://academy.8ksec.io" rel="noreferrer" target="_blank"> academy.8ksec.io</a> to explore our full catalog of courses. Whether you’re a beginner or an experienced professional, you’ll find resources to enhance your skills and stay ahead in the fast-evolving field of Mobile Security.</p><p>Feel free to reach out to us at support@ to ask any questions related to our blogs or any future blogs that you would like to see.</p><p><strong>Have a great day !</strong></p> </div>
</div>
</div>
</div>
</div><p>The post <a href="https://8ksec.io/reading-ios-sandbox-profiles/" rel="noreferrer" target="_blank">Reading iOS Sandbox Profiles</a> first appeared on <a href="https://8ksec.io" rel="noreferrer" target="_blank">8kSec</a>.</p>
Article Link: Reading iOS Sandbox Profiles - 8kSec
1 post - 1 participant
Malware Analysis, News and Indicators - Latest topics
Post a Comment
Post a Comment