{"id":39333,"date":"2023-05-10T15:16:27","date_gmt":"2023-05-10T19:16:27","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=39333"},"modified":"2023-05-10T15:17:25","modified_gmt":"2023-05-10T19:17:25","slug":"code-signing-translocation-vulnerability","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/05\/10\/code-signing-translocation-vulnerability\/","title":{"rendered":"Code Signing Translocation Vulnerability"},"content":{"rendered":"

OccamSec<\/a> (in 2021):<\/p>\n

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.<\/p>

[…]<\/p>

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

[…]<\/p>

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<\/code> 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<\/code> + otool -l<\/code> 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.<\/p>

[…]<\/p>

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.<\/p><\/blockquote>\n\n

Note that the post refers to this as “codesigning translocation,” but this is completely separate from App<\/a> Translocation<\/a>, though that is also related to code signing.<\/p>\n\n

Previously:<\/p>\n