Wednesday, May 10, 2023

Code Signing Translocation Vulnerability

OccamSec (in 2021):

It is far easier, however, to break the codesigning system and sign your binary as an Apple binary. But let’s get this straight: even though the machine will be aware that the LC_CODE_SIGNATURE LoadCommand is tainted, it will still execute.


The result is that we can perform arbitrary memory read and write using the Mach virtual memory APIs and inject code into system processes.


As of Friday, July 16th (perhaps earlier, with the release of Big Sur 11.4), it seems Apple issued a stealth patch against this exploit, without notifying us. Code signatures no longer show up via codesign or other tools, though the kernel is still able to recognize the “detached code signature”, as seen above. It seems that the code signature format may have changed; given tools such as “Apparency” say the code signature is in an invalid format; alongside my script + classic dd + otool -l refuse to spit out a valid code signature. As for why Apple has been so silent on the communications side of things, we don’t know.


This band-aid patch essentially makes it possible for malware to hide a phony code signature, and does nothing on the kernel side to mitigate the vulnerability.

Note that the post refers to this as “codesigning translocation,” but this is completely separate from App Translocation, though that is also related to code signing.


Comments RSS · Twitter · Mastodon

Leave a Comment