Exploits & Vulnerabilities
This weblog entry discusses the technical particulars of how we exploited CVE-2022-22583 utilizing a distinct methodology. We additionally sort out the technical particulars of CVE-2022-32800, one other SIP-bypass that we found extra lately, on this report.
Learn time: ( phrases)
On Jan. 26, 2022, Apple patched a System Integrity Safety (SIP)-bypass vulnerability within the PackageKit framework, recognized as CVE-2022-22583. Apple shared the credit score for this CVE between researchers Ron Hass (@ronhass7) of Notion Level and Mickey Jin (@patch1t) of Pattern Micro.
After Notion Level posted a complete weblog entry concerning the vulnerability and its exploitation particulars, we decided that the tactic we used to use the vulnerability was totally different from theirs. We additionally found a brand new vulnerability, CVE-2022-32800, after digging deeper into CVE-2022-22583.
This weblog entry discusses the technical particulars of how we exploited CVE-2022-22583 utilizing a distinct methodology. We additionally sort out the technical particulars of CVE-2022-32800, one other SIP-bypass that we found extra lately, on this report.
That is the third and closing entry of a sequence of weblog entries the place we talk about our SIP-related vulnerability discoveries. Extra particulars about SIP and the particular daemon companies’ entitlements may be present in our earlier weblog entry final month. We additionally talked about a number of of the greater than 15 important SIP-bypass vulnerabilities that we disclosed to Apple throughout the Energy of Group 2022 Safety Convention (POC2022).
CVE-2022-22583
We found this vulnerability through course of monitoring. Once we put in an Apple-signed software program installer package deal (PKG) file to the foundation quantity, we observed that the next scripts had been spawned by the privileged “system_installd” service:
/tmp/PKInstallSandbox.l57ygT/Scripts/com.apple.pkg.MXFPlugIns.yJpaxP/preinstall
/tmp/PKInstallSandbox.l57ygT/Scripts/com.apple.pkg.MXFPlugIns.yJpaxP/postinstall
As a result of the “system_installd” service has the particular “com.apple.rootless.set up.heritable” entitlement, these two scripts will likely be executed in a SIP-bypass context.
After seeing that these two scripts had been contained in the “/tmp/PKInstallSandbox.l57ygT” listing, the next questions got here to thoughts:
- Can we modify the scripts contained in the momentary location?
- Who created the momentary folder “PKInstallSandbox” with a random suffix?
- Is the newly created folder protected by SIP?
Guided by these questions, we began our investigation.
By reversing and debugging, we discovered that the momentary folder was created by the “-[PKInstallSandbox prepareForCommitReturningError:]” operate:
At line 16, it calls one other operate, “-[PKInstallSandbox _createDirectory:uniquifying:error:]”, which internally calls the API “mkdtemp” to create the folder with none restrictions.
After seeing that the “PKInstallSandbox.XXXXXX” folder was unprotected, we initially thought that it may be exploited and manipulated. Nonetheless, we did not straight modify the scripts contained in the folder. This was as a result of the subfolder “Scripts” was restricted, and it was moved from the restricted sandbox path, as we will see at line 25 in Determine 1.
There are no less than two totally different strategies to beat this explicit problem and exploit this safety concern.
The primary exploit makes use of the mount trick. Notion Level mentioned this intimately in its weblog entry. Based mostly on the investigation there, the mount trick may be carried out through the next steps:
- Create a digital picture file and mount it onto “/non-public/tmp”.
- Set up an Apple-signed package deal with post-install scripts.
- Look ahead to the installer to complete the extraction of the scripts’ listing and collect the random components of the extracted path.
- Unmount the picture file. It will revert to the contents of “/non-public/tmp” earlier than the extraction.
- Create the scripts listing (utilizing the random path we obtained earlier) and deposit any script that we might need inside it.
Notion Level’s weblog publish additionally identified that the exploit mentioned there may be depending on timing and may not succeed always.
Our exploit makes use of a distinct methodology: a symlink. This exploit may be carried out through the next steps:
- Monitor the creation of the “/tmp/PKInstallSandbox.XXXXXX” listing and substitute it with a symlink to a different “/tmp/fakebox” location to redirect the restricted scripts there.
- As soon as the scripts are situated contained in the “/tmp/fakebox”, take away the symlink and recreate the identical “/tmp/PKInstallSandbox.XXXXXX” listing, then place the payload script within the “/tmp/PKInstallSandbox.XXXXXX/Scripts/pkgid.XXXXXX/” listing.
- Look ahead to the payload script to execute.
The total proof of idea for this exploit is uploaded on GitHub. Our proof-of-concept demonstration will also be seen in Determine 3.
Although we’re root, we will’t create a file within the restricted listing “/Library/Apple” as a result of the SIP standing is enabled. However with the assistance of the exploit program, we will execute arbitrary instructions in a SIP-bypass context and efficiently create a file within the restricted listing.
Apple’s patch for CVE-2022-22583
There’s a little bit of a confusion about how the “installd” service and the “system_installd” service function. In Determine 4, we will see that the patch code, which may be seen at traces 17 and 18, makes the excellence between these two companies:
For Apple-signed packages, the patch makes use of “OpenPath” together with its personal restricted sandbox path. For different packages, it nonetheless makes use of a random path contained in the “/tmp” listing.
Earlier than introducing CVE-2022-32800, we have to perceive some ideas associated to “Set up Sandbox.”
First, let’s check out “Sandbox Repository,” a listing returned and created by the “-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]” operate.
To summarize, there are 4 sorts of sandbox repositories:
- The set up goal is the foundation quantity “/”:
a. For Apple-signed PKGs: /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware
b. For different PKGs: /Library/InstallerSandboxes/.PKInstallSandboxManager - The set up goal shouldn’t be the foundation quantity:
a. For Apple-signed PKGs: $targetVolume/.PKInstallSandboxManager-SystemSoftware
b. For different PKGs: $targetVolume/.PKInstallSandboxManager
It ought to be famous that it’s only when Apple-signed packages are put in to the foundation quantity that the “Sandbox Repository” turns into restricted.
The “Sandbox Path” is used to retailer recordsdata akin to scripts and payloads throughout set up.
It’s a listing contained in the “Sandbox Repository,” created by the “[PKInstallSandboxManager addSandboxPathForDestination:forSystemSoftware:]_block_invoke” methodology:
There are 4 sorts of sandbox paths, every with a universally distinctive identifier (UUID) identify that signifies their particular sandbox state:
- UUID.sandbox: the primary state created
- UUID.activeSandbox: the activated state; in use
- UUID.trashedSandbox: the deactivated state; to be trashed
- UUID.orphanedSandbox: the orphaned state; if the disk area shouldn’t be sufficient, it is going to be cleaned up
“PKInstallSandbox” is an Goal-C class identify for abstraction and encapsulation:
@interface PKInstallSandbox : NSObject <NSSecureCoding>
{
@public
NSString *_sandboxPath;
PKInstallRequest *_installRequest;
NSString *_scriptsPath;
NSString *_temporaryPath;
NSNumber *_stagedSize;
NSDate *_stageDate;
NSMutableDictionary *_scriptDirsByPackageSpecifier;
NSMutableDictionary *_bomPathsByPackageSpecifier;
NSMutableArray *_cleanupPaths;
NSDictionary *_scriptsAttributes;
NSDictionary *_temporaryAttributes;
NSSet *_previousPackageIdentifiersSharingGroupsWithSandbox;
lengthy lengthy _relevance;
BOOL _safeToReset;
}
+ (BOOL)supportsSecureCoding;
– (id)initWithCoder:(id)arg1;
– (id)initWithSandboxPath:(id)arg1 installRequest:(id)arg2 error:(id *)arg3;
@finish
A brand new occasion of “PKInstallSandbox” is initialized through the “-[PKInstallSandbox initWithSandboxPath:installRequest:error:]” methodology. That is in keeping with a sandbox path and an set up request.
Word that the occasion is serializable and that the category applied the “NSSecureCoding” protocol. The “system_installd” service can save or serialize an occasion right into a file named “SandboxState” contained in the sandbox path through the “-[PKInstallSandboxManager saveSandboxAsStaged:]” methodology:
The “PKInstallSandbox” occasion will also be restored or deserialized from the “SandboxState” file later through the “-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]” methodology:
Word that there’s a examine at line 57, which requires that restored set up requests be deeply equal to the set up request handed from the set up shopper. This examine brings a small problem to our exploitation process.
Earlier than set up, the “system_installd” service must get an occasion of the “PKInstallSandbox” in keeping with the set up request within the “-[PKInstallSandboxManager sandboxForRequest:created:error:]” operate.
The operate’s core logic is as follows:
First, it can enumerate all of the folders with the “.sandbox” suffix from the “Sandbox Repository” after which restore the “PKInstallSandbox” occasion from the “SandboxState” file inside.
Subsequent, if it may’t discover a “PKInstallSandbox” occasion matching the set up request, then it will enumerate all of the folders with the “.activeSandbox” suffix and attempt to restore them from these areas.
Lastly, if it nonetheless can not match such a sandbox, it can create a brand new “Sandbox Path” and assemble a brand new “PKInstallSandbox” occasion.
CVE-2022-32800
The CVE-2022-32800 vulnerability permits an attacker to hijack the “SandboxState” file to get a SIP-bypass primitive.
The “SandboxState” file is saved within the “Sandbox Path,” which is contained in the “Sandbox Repository.” In a traditional situation, the “Sandbox Repository” is restricted for Apple-signed packages.
Nonetheless, if the set up vacation spot is a DMG (disk picture) quantity, the “Sandbox Repository” shouldn’t be restricted in any respect. The identical is true for the “SandboxState” file. Thus, we will make a crafted “SandboxState” file to hijack the brand new “PKInstallSandbox” occasion throughout the deserialization course of. All of the member variables of the “PKInstallSandbox” occasion can then be managed.
There are alternative ways to use the difficulty. In Determine 12, for instance, we hijacked the member “_cleanupPaths” to get a primitive to take away arbitrary SIP-protected paths.
When the set up is completed, irrespective of whether or not it’s profitable or not, it can name the “-[PKInstallSandboxManager _removeSandbox:]” operate to take away the sandbox and delete all of the recordsdata and folders specified by the “_cleanupPaths” member.
The total proof of idea for this exploit may be discovered on GitHub, and a video of the demonstration may be seen right here.
Apple’s patch for CVE-2022-32800
Apple addressed this safety concern in macOS 12.5.
The patch is within the “-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]” operate:
As we will see within the examine at line 38, it calls the “PKSIPFullyProtectedPath” operate internally:
For Apple-signed packages, the “SandboxState” file is required to be trusted or restricted.
Safety suggestions
To efficiently shield methods towards vulnerabilities, customers should frequently replace their working methods. Commonly making use of safety patches will hinder malicious actors from exploiting vulnerabilities to raise privileges and launch malicious assaults. As for the vulnerabilities mentioned right here, CVE-2022-22583 was patched in January 2022 and CVE-2022-32800 was patched in July 2022.
Finish customers can profit from safety options such because the Pattern Micro Antivirus for Mac and Pattern Micro Safety Suites that assist detect and block assaults that exploit such flaws.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
