[ad_1]
A Technical Evaluation of CVE-2022-22583 and CVE-2022-32800
Exploits & Vulnerabilities
This weblog entry discusses the technical particulars of how we exploited CVE-2022-22583 utilizing a special methodology. We additionally deal with the technical particulars of CVE-2022-32800, one other SIP-bypass that we found extra lately, on this report.
By: Mickey Jin
December 21, 2022
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 Development Micro.
After Notion Level posted a complete weblog entry in regards to the vulnerability and its exploitation particulars, we decided that the tactic we used to use the vulnerability was completely 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 special methodology. We additionally deal with the technical particulars of CVE-2022-32800, one other SIP-bypass that we found extra lately, on this report.
That is the third and remaining 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 providers’ entitlements may be present in our earlier weblog entry final month. We additionally talked about a number of of the greater than 15 crucial SIP-bypass vulnerabilities that we disclosed to Apple throughout the Energy of Neighborhood 2022 Safety Convention (POC2022).
CVE-2022-22583
We found this vulnerability by way of course of monitoring. After we put in an Apple-signed software program installer package deal (PKG) file to the foundation quantity, we observed that the next scripts have 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 have 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.
Via reversing and debugging, we discovered that the momentary folder was created by the “-[PKInstallSandbox prepareForCommitReturningError:]” perform:
Determine 1. The implementation of the “prepareForCommitXXX” perform
At line 16, it calls one other perform, “-[PKInstallSandbox _createDirectory:uniquifying:error:]”, which internally calls the API “mkdtemp” to create the folder with none restrictions.
Determine 2. The implementation of the “_createDirectory:uniquifying:” perform
After seeing that the “PKInstallSandbox.XXXXXX” folder was unprotected, we initially thought that it may be exploited and manipulated. Nevertheless, we didn’t immediately 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 are able to see at line 25 in Determine 1.
There are a minimum of two completely different strategies to beat this explicit problem and exploit this safety situation.
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 accomplished by way of the next steps:
Create a digital picture file and mount it onto “/personal/tmp”.
Set up an Apple-signed package deal with post-install scripts.
Watch for the installer to complete the extraction of the scripts’ listing and collect the random components of the extracted path.
Unmount the picture file. This may revert to the contents of “/personal/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 put up additionally identified that the exploit mentioned there may be depending on timing and won’t succeed always.
Our exploit makes use of a special methodology: a symlink. This exploit may be accomplished by way of 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.
Watch for the payload script to execute.
The total proof of idea for this exploit is uploaded on GitHub. Our proof-of-concept demonstration may also be seen in Determine 3.
Determine 3. Our exploit demonstration that makes use of symlink
Regardless that we’re root, we are able to’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 are able to 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 are able to see that the patch code, which may be seen at strains 17 and 18, makes the excellence between these two providers:
Determine 4. The patch for CVE-2022-22583
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:]” perform.
Determine 5. The implementation of the “_sandboxRepositoryForDestination:XXX” perform
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-SystemSoftwareb. For different PKGs: /Library/InstallerSandboxes/.PKInstallSandboxManager
The set up goal isn’t the foundation quantity:a. For Apple-signed PKGs: $targetVolume/.PKInstallSandboxManager-SystemSoftwareb. 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 information comparable 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:
Determine 6. The implementation of the “addSandboxPathForDestination:XXX” perform
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 house isn’t sufficient, it will likely 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 by way of the “-[PKInstallSandbox initWithSandboxPath:installRequest:error:]” methodology. That is in line with a sandbox path and an set up request.
Observe 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 by way of the “-[PKInstallSandboxManager saveSandboxAsStaged:]” methodology:
Determine 7. The implementation of the “saveSandboxAsStaged” perform
The “PKInstallSandbox” occasion may also be restored or deserialized from the “SandboxState” file later by way of the “-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]” methodology:
Determine 8. The implementation of the “sandboxAtPath:matchingRequest:XXX” perform
Observe that there’s a verify 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 verify brings a small problem to our exploitation process.
Earlier than set up, the “system_installd” service must get an occasion of the “PKInstallSandbox” in line with the set up request within the “-[PKInstallSandboxManager sandboxForRequest:created:error:]” perform.
The perform’s core logic is as follows:
First, it should enumerate all of the folders with the “.sandbox” suffix from the “Sandbox Repository” after which restore the “PKInstallSandbox” occasion from the “SandboxState” file inside.
Determine 9. Enumerating all of the folders with the “.sandbox” suffix
Subsequent, if it will probably’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.
Determine 10. Enumerating all of the folders with the “.activeSandbox” suffix
Lastly, if it nonetheless can’t match such a sandbox, it should create a brand new “Sandbox Path” and assemble a brand new “PKInstallSandbox” occasion.
Determine 11. Create a brand new “Sandbox Path” and 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 standard state of affairs, the “Sandbox Repository” is restricted for Apple-signed packages.
Nevertheless, if the set up vacation spot is a DMG (disk picture) quantity, the “Sandbox Repository” isn’t restricted in any respect. The identical is true for the “SandboxState” file. Thus, we are able to 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 other 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 should name the “-[PKInstallSandboxManager _removeSandbox:]” perform to take away the sandbox and delete all of the information and folders specified by the “_cleanupPaths” member.
Determine 12. The implementation of the “_removeSandbox” perform
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 situation in macOS 12.5.
The patch is within the “-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]” perform:
Determine 13. The patch for CVE-2022-32800
As we are able to see within the verify at line 38, it calls the “PKSIPFullyProtectedPath” perform internally:
Determine 14. The implementation of the “PKSIPFullyProtectedPath” perform
For Apple-signed packages, the “SandboxState” file is required to be trusted or restricted.
Safety suggestions
To efficiently shield methods in opposition to vulnerabilities, customers should often replace their working methods. Usually 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 Development Micro Antivirus for Mac and Development Micro Safety Suites that assist detect and block assaults that exploit such flaws.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
[ad_2]