• CVE-2022-32845: aned signature check bypass for model.hwx.
• CVE-2022-32948: DeCxt::FileIndexToWeight() OOB Read due to lack of array index validation.
• CVE-2022-42805: ZinComputeProgramUpdateMutables() potential arbitrary read due to integer overflow issue
• CVE-2022-32899: DeCxt::RasterizeScaleBiasData() Buffer underflow due to integer overflow issue.

• iPhone 12 Pro (iPhone 13,3) running iOS 15.5
• iPad Pro (iPad 8,10) running iPadOS 15.5
• iPhone 11 Pro (iPhone 12,3) running iOS 15.4.1
• MacBook Air (10,1 with M1 chip) running macOS 12.4

Apple’s Neural Engine Architecture

The user interface

Tools & Frameworks

• Integrated trained models into Xcode apps.
• Load models and on-device training.
• Make predictions.

• Creates models from scratch.
• Converts trained models from other ML tools into CoreML.
• Manipulates/Customizes network layers and operations.
• Loads models and makes predictions.

CoreML loads models through aned system service:

• XPC Interface : com.apple.appleneuralengine.
• Main broker for CoreML interactions with the kernel and the compiler service.
• Responsible for Model compilation and loading.

aned compiles a model through the ANE compiler ANECompilerService:

• XPC Interface : com.apple.ANECompilerService.
• Model Translation & Compilation. Entitled: com.apple.ANECompilerService.allow.
• Produces a binary model “model.hwx”.

Model Formats

• The compilation can also be done via coremlcompiler command.

• The model translation is made by Espresso private framework.

• The compilation is done by ANECompiler`ANECCompile()
• The model.hwx is a Mach-O file that starts with 0xfeedface or 0xbeefface.
• The model.hwx has segments / sections .. etc

The kernel interface

• Responsible for loading/unloading models.
• A lot of external methods with rich features (large attack surface).
• Entitled: com.apple.ane.iokit-user-access.

• Responsible for model predictions and on-device training.
• Allows apps to Send Procedure Calls Requests to the firmware.
• Reachable from the default app sandbox (an attractive target).

The Firmware interface

References

• BlackHat ASIA 21 Wish Wu: Apple Neural Engine Internals
• George Hotz | Programming | tinygrad: triggering the Apple Neural Engine from C++
• Hollance : The Neural Engine — what do we know about it?

Vulnerabilities

CVE-2022-32840: ANE_ProgramSendRequest() OOB write

• Any validation for the total surface buffers ?

• No validation for total intermediate buffers

CVE-2022-42805: ANECValidateMutableProcedureInfo() integer overflow.

• ANECMutableProcedureInfo is a mapping of an IOSurface buffer.
• The IOSurface object is from structureInput->weightSurfaceId.
• ANECMutableProcedureInfo content is completely under user-control.
• ANECValidateMutableProcedureInfo is called to verify the safety of the object.

• ANECValidateMutableProcedureInfo is called to verify the safety of the object passed to ZinComputeProgramUpdateMutables.

• ANECValidateMutableProcedureInfo() validates the shared surface buffer.
• Integer overflow in the calculation at line 95.
• The security check could be bypassed by overflowing the calculation.

• ANECValidateMutableProcedureInfo() validated our object.
• ANECGetMutableWeight() is called to populate ANECMutableWeight.
• Because of the overflow, _weightBuf could point to any location outside the buffer range.
• This vulnerability could be turned into arbitrary memory read if the procedure_info address was known.

• ANECMutableProcedureInfo is allocated from KHEAP_DATA_BUFFERS.
• Groom KHEAP_DATA_BUFFERS with a lot of ipc_kmsg data buffers.
• Allocate the ANECMutableProcedureInfo object.
• Overflow the calculation : weightInfo->wi_off = (0 - 0x10000);
• Underflow the mw->_weightBuf location to point to an ipc_kmsg buffer.

CVE-2022-32948: DeCxt::FileIndexToWeight() improper index validation

• DeCxt::FileIndexToWeigh() is reachable from H11ANEInDirectPathClient::_ANE_ProgramSendRequest().

• Both index and offset are user-controlled parameters.
• weight_objects class member is an array of ANECMutableWeight.
• ANECMutableWeight array allocation size is opsInfo->op_count from ANECMutableProcedureInfo (user controlled shared buffer).
• The lack of index validation allows reading out-of-bounds ANECMutableWeight objects.
• By grooming kernel memory, the attacker can read data from arbitrary kernel pointer with arbitrary size.

CVE-2022-32899: DeCxt::RasterizeScaleBiasData() OOB write

• The function converts floating-point values from single-precision to half-precision.
• param_1, param_2 and param_3 are user-controlled input.

• param_1 is 64-bit value and it’s user-controlled input.

• param_2 is 16-bit value and it’s user controlled input.

• MUTK_kernel_section is an IOSurface mapped buffer created by the kernel.
• Created by H11ANEIn::AllocateSharedMemorySurface().

• A sanity check for a potential integer overflow in the calculation at line 16.
• The sanity checks does NOT prevent from integer underflow.
• Buffer underflow that allows to write arbitrary data to any location prior the MUTK_kernel_section address.
• Up to 0x20000 bytes of user-controlled data could be written.

• Another OOB read/write in DeCxt::RasterizeScaleBiasData().
• Because offset and pos are fully user-controlled and not validated before their usage.

How to reach H11ANEIn::patchMutableSurface() ?

• The model.hwx (Mach-O file ) must have some special flags in some mach sections.
• The model.hwx must have a procedure (Neural Network) with mutable features.

• No documentation available.
• To understand the compilation/translation options available, you need to RE some private frameworks yourself : mlcompiler, Espresso and ANECCompiler.
• Good luck reversing frameworks written in C++ and STL.

Load a malformed model.hwx (Mach-O) file

• {kANEFModelType : nil } ⇒ Compiles + Loads .mlmodelc.
• {kANEFModelType : kANEFModelPreCompiled } ⇒ Loads model.hwx from arbitrary location.
• {kANEFIsInMemoryModelTypeKey : <model> } ⇒ Loads model.hwx from the cache directory.

• Cache Directory: Loads an already compiled model.
• Arbitrary location: Loads a compiled model from a given directory.

• macOS: /Library/Caches/com.apple.aned/<build no>/InMemoryModelCache
• *OS: /var/mobile/Library/Caches/com.apple.aned/<build no>/InMemoryModelCache
• Even root can’t read its content. Security Features need to be disabled in macOS.

• Get the cache directory location.
• Append csIdentity to that cache directory.
• Append kANEFIsInMemoryModelTypeKey value.
• Append “model.hwx” string to the cache directory.

• Only the models that were compiled by Apple can be loaded from any location.
• Our (malicious) model needs to be located in the cache directory in order to be loaded.
• As a result: there’s no legitimate way to load a modified model.

• Find a vulnerability to trick aned to load our malicious (non-signed) model.hwx.

CVE-2022-32845: aned signature check bypass for model.hwx

• Get the cache directory location.
• Append csIdentity to that cache directory.
• Append kANEFIsInMemoryModelTypeKey value.
• If found, Append “model.hwx” string to the cache directory.

• kANEFIsInMemoryModelTypeKey value is not sanitized.
• Load a malformed model.hwx outside of the cache directory by exploiting the path traversal input.
• However the model’s cache directory path must first be created.
• We need to compile a mlmodelc to create the directory.

Proof Of Concept: Load a malformed model.hwx

• Send foo.mlmodelc as a model directory to aned for loading.
• aned calls ANECompilerService to compile the model under foo.mlmodelc directory.
• ANECompilerService creates foo directory in the cache directory then saves the compiled model.hwx for later use.

• Put the malformed model.hwx in a directory bar.
• Create an option dictionary with {kANEFIsInMemoryModelTypeKey : bar_path }. Where bar_path = ../../../../../../../../../../../../bar
• Call aned to load the model from kANEFIsInMemoryModelTypeKey path: -[_ANEInMemoryModelCacheManager cachedModelPathMatchingHash:csIdentity:] is called to retrieve the cache directory for that model

• +[_ANEStorageHelper memoryMapModelAtPath:isPrecompiled:modelAttributes:] to load malicious_model.hwx from the malicious path with isPrecompiled = False.

Exploitation

Build an arbitrary kernel r/w primitive

• CVE-2022-32845: aned signature check bypass for model.hwx.
• CVE-2022-32948: DeCxt::FileIndexToWeight() improper index validation.
• CVE-2022-42805: ANECValidateMutableProcedureInfo() integer overflow.
• CVE-2022-32899: DeCxt::RasterizeScaleBiasData() OOB writes.

- Overwrite IOSurfaceClient reference in IOSurfaceRootUserClient for arbitrary r/w:

• First public appearance of the technique was in my oob_event kernel exploit for iOS 13.7
• Used to bypass zone_require() by corrupting corpse_task->map with kernel_map to gain tfp0

- Build a fake IOSurface and use external methods for kernel r/w

- John Åkerblom’s Zer0Con 2022 slides for more details

- Apple mitigated the technique in iOS 15.3

IOSurface Security Changes

Apple introduced IOSurfaceRootUserClient::getSurfaceClient()

which does the following:

• Pointer Authenticate IOSurfaceClient object when it’s looked-up via a given surface id.
• IOSurfaceClient->user client reference matches the calling UserClient.
• IOSurface->SurfaceRoot must match gIOSurfaceRoot value.

Strong validation checks for IOSurfaceClient objects:

• PAC Bypass is required to corrupt the array of IOSurfaceClient objects.
• IOSurfaceRootUserClient location is required to forge IOSurfaceClient.

Weak validation checks for IOSurface objects:

• IOSurfaceRoot location is required.

No checks at all for IOSurface->SharedRO/RW pointers.

To achieve kernel r/w, corrupt IOSurfaceClient->IOSurface location with a fake IOSurface. The attacker needs the following:

• A write primitive to overwrite IOSurfaceClient->IOSurface is needed.
• Leak an IOSurfaceClient object location that’s created by the attacker.
• Leak IOSurfaceRoot location to bypass IOSurfaceRootUserClient::getSurfaceClient() last check.
• A (Fake IOSurface) kernel pointer whose content is under the attacker’s control.

• For the write primitive, I used DeCxt::RasterizeScaleBiasData() OOB write to corrupt the target IOSurfaceClient object.
• To achieve this, the mutable kernel section (MUTK) address is required.

- The OOB write can be used as:

• Near Writes: Write into any offset near to MUTK.
• Far Writes: Perform arbitrary write to any kernel memory below `MUTK`.

- For Far Writes we need to locate the exact address of the MUTK buffer.

Leak ‘MUTK’ Section Mapping Address

What is the 'MUTK' from the attacker’s perspective?

• It’s a private IOSurface mapped buffer created by the kernel.

• The buffer is allocated from IOKit Pageable Maps.
• MUTK buffer is mapped in the kernel via H11ANEIn::patchMutableSurface().

• The mapping address is stored in ProgramBuffer object.
• All ‘MUTK’ information stored in H11ANESharedMemorySurfaceParamsStruct.
• Leak ProrgamBuffer->MUTK_Surface object to user-space to retrieve the MUTK buffer address.

What’s a programBuffer from the attacker’s perspective ?

• H11ANEProgramBufferParamsStruct size is 0x53e70.
• kalloc_type()’ed object.
• Big allocations don’t have a dedicated zone.
• Big allocations without zone fall into KHEAP_DEFAULT.
• Big allocations in KHEAP_DEFAULT with size > 0x8000 fall into kernel_map.
• H11ANEProgramBufferParamsStruct is allocated from kernel_map.

• H11ANESharedMemorySurfaceParamsStruct object holds interesting IOSurface information
• How to leak H11ANESharedMemorySurfaceParamsStruct content?

• Use DeCxt::FileIndexToWeight() index to fetch programBuffer->MUTK_Surface[0] as a fake mutable weight buffer.
• Make one ProgramBuffer adjacent to ANECMutableWeight array.
• Because the ANECMutableWeight array allocation size is user-controlled, the attacker can direct the allocation to take place in kernel map.
• ANECMutableWeight allocations is a temporary.
• To make ProgramBuffer and ANECMutableWeight near to each other, kernel_map grooming is required.

• Load multiple ProgramBuffer objects by creating several programs.
• Allocate an OSArray backing store of size 0x54000 between each 2 programBuffer objects.

• Release all the OSArray objects.

• Allocate ANECMutableWeight array with size of 0x54000.

• Use DeCxt::FileIndexToWeight() lack of array index validation.
• index = (sizeof(ANECMutableWeight[]) + offsetof(programBuffer, MUTK_Surface[0]) / sizeof(ANECMutableWeight).
• index = ( 0x54000 + 0x53E10) / 0x10 = 0x000a7e1.
• The selected weight buffer is passed to DeCxt::ParseTransform() for processing.
• Then DeCxt::RasterizeScaleBiasData() stores the elements to `MUTK` IOSurface buffer.

• `MUTK` IOSurface object is private therefore its content cannot be read.
• Because MUTK cannot be read, the OOB index bug is technically not exploitable.
• To make the OOB index exploitable, combine it with the OOB write vulnerability.
• Use the Near-Write to copy the leaked structure outside of the MUTK buffer.
• The target location to write into must be readable by our process.
• `MUTK` IOSurface buffer is allocated from IOKitPageableMaps.
• Groom IOKitPageableMaps is required.

• Buffers that can be allocated in IOKitPageableMaps.
• Those buffers can be shared with (or copy data out to) user-space process.
• Shared memory FTW!

• The best option is : IOGPU shared buffers.
• IOGPU is reachable from the default app sandbox.

• Allocate MAX_SHMEMS ( =0x3000) shared memory objects.
• Shared memory object size = 0x4000.
• Map shared memory objects to the kernel via s_submit_command_buffers().
• Use Near Writes to copy H11ANESharedMemorySurfaceParamsStruct to one of our shared buffers
• Write H11ANESharedMemorySurfaceParamsStruct at MUTK_kernel_address - 0x280000

• Scan all the shared buffers to find the scratched one using lookup_scratched_shmem().

• For full implementation see groom_pageable_maps() in the exploit source code.
• If found, one of the shmem buffers holds H11ANESharedMemorySurfaceParamsStruct.

• A kernel address from IOKitPageableMaps (MUTK buffer).
• IOSurface address from IOSurface_zone.

• We need to find an IOSurfaceClient address to perform the arbitrary write.

Leak an IOSurfaceClient object location

• Can be found in IOSurfaceRootUserClient which created it.
• Can be found in IOSurface: in a queue that keeps track of IOSurfaceClient’s refs.
• An IOSurface address was leaked already but it doesn’t have an IOSurfaceClient object.
• The goal is to find an IOSurface object that’s owned by the attacker, thus has an IOSurfaceClient.
• Use ANECValidateMutableProcedureInfo() integer overflow to read 1 page from IOSurface_zone.

• Round down the address of IOSurface to get the page address.
• Leak 1-page of IOSurface_zone to user-space.
• The page must have at least one IOSurface created by us.
• Reading more than one page may result in a kernel panic.
• weightSurface (aka ANECMutableProcedureInfo) address is required to achieve arbitrary read.
• Because weightSurface can be in IOKitPageableMaps, its location can be deduced from the leaked MUTK address.

• 1 page contains ~15 IOSurface objects.
• 1 page may not necessarily have one of our IOSurface objects.

• Spray IOSurface_zone with our IOSurface objects to increase the odds.

• Release some IOSurface objects.

• Allocate a programBuffer so MUTK IOSurface overlaps with one of the freed IOSurface objects.

• IOSurface_zone_page = trunc_page(aneMemSurface.p_IOSurface);
• Scan the whole page to find a matching IOSurfaceID.

• The second object in the page dump is a potential IOSurface target.

IOGPU Shared Buffers as a fake IOSurface object

• Use IOSurface::get_use_count() to identify the kernel r/w shm_id.
• If the returned value is 0x41410AAA, it means that 0xAAA is the corresponding shm_id.

WeightBuf Kernel Exploit

• Kernel r/w exploits alone are not enough to fully hack iPhones nowadays.
• WeightBuf demonstrates that despite the challenges posed on by current mitigations, memory corruption bugs can still be exploited.
• WeightBuf works across all devices: macOS, iOS and iPadOS.
• The exploit reliability may differ from one device to another, some exploit tuning is required to increase the reliability for a particular device.

Conclusion

• iOS now is one of the hardest (if not the hardest) targets to hack.
• This is not the end of iOS exploitation, you just need a high quality bugs to pwn it. When there’s a will there’s a way.
• There are many excellent bugs out there just waiting to be found.
• As a security researcher, learn to follow the nudges of your intuition.
• Thanks to Apple SEAR for making the challenge super fun and more interesting than ever.