Code signing crash when WebKit loads private TCC.framework

The application is code signed and launches without problems. Just
when this code comes to initialize WebKit, it crashes.

Please post the full Apple crash report. Use the text attachment feature (the paperclip icon) to prevent it clogging up the timeline.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Please post the full crash log as Quinn mentions above.

Also, does this reproduce on a different Mac (with 11.1 or another build of macOS 11.x Big Sur)? Does it reproduce after you reboot the same Mac? Does it reproduce if you re-install 11.1 (or a newer macOS) on the same Mac? (NOTE: You don't have to check all of these—just suggestions to try if it's easy to do.)

The crash log says that dyld is detecting an invalid code signature (apparently for the TCC.framework/TCC binary), which is unexpected since System Integrity Protection is enabled.

Hi, it's about an app of ours that crashes in four different places, always with the message "Code Signing Invalid". The problems have so far occurred on two Macs running macOS 11.1 and also on one Mac running macOS 10.15.7. Possibly the crashes have the same cause, attached are all the crash logs:

That’s an interesting crash you’ve got going on there. I’m going to focus on the first crash report you posted because I dont have the bandwidth to look at all three.

Consider this:

Code Block  
Exception Type:        EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes:       0x0000000000000032, 0x0000000111c726a0
Exception Note:        EXC_CORPSE_NOTIFY
Termination Reason:    Namespace CODESIGNING, Code 0x2
kernel messages:
VM Regions Near 0x111c726a0:
    CoreAnimation   111c71000-111c72000 … 
-->…TEXT          111c72000-11202d000 …
    …DATA          11202d000-112321000 …
Application Specific Information:
dyld: in dlopen()
/System/Library/PrivateFrameworks/TCC.framework/TCC
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   dyld            0x000000010b6bd326 ImageLoaderMachO::getInstallPath() const + 20

Most code signing crashes are caused by instruction fetches, that is, you’ve jumped to something that’s not code or is code but isn’t signed correctly. In this case, however, it’s a data fetch. Note that the Exception Codes value, 0x0000000111c726a0, isn’t the same as the crashing PC, 0x000000010b6bd326.

You can confirm the crashing PC by looking at rip in the thread state:

Code Block  
Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000698  …  rcx: 0x0000000111c72000  …
  …
  rip: 0x000000010b6bd326  …

Now let’s pull apart the crashing code:

Code Block  
(lldb) disas -n 'ImageLoaderMachO::getInstallPath()'
dyld`ImageLoaderMachO::getInstallPath:
    0x10002b312 <+0>:  pushq  %rbp
    0x10002b313 <+1>:  movq   %rsp, %rbp
    0x10002b316 <+4>:  movl   0x78(%rdi), %eax
    0x10002b319 <+7>:  testq  %rax, %rax
    0x10002b31c <+10>: je     0x10002b32f               ; <+29>
    0x10002b31e <+12>: movq   0x58(%rdi), %rcx
    0x10002b322 <+16>: leaq   (%rcx,%rax), %rdx
    0x10002b326 <+20>: movl   0x8(%rcx,%rax), %eax
    0x10002b32a <+24>: addq   %rdx, %rax
    0x10002b32d <+27>: jmp    0x10002b331               ; <+31>
    0x10002b32f <+29>: xorl   %eax, %eax
    0x10002b331 <+31>: popq   %rbp
    0x10002b332 <+32>: retq   
    0x10002b333 <+33>: nop    

IMPORTANT The absolute addresses will be different due to ASLR so it’s the offsets that matter.

The instruction at +20 adds rcx, rax and 8 and then reads from that address. That sum is 0x0000000111c726a0, which is the value in Exception Codes.

So, the process has crashed because it’s attempted to access data in a Mach-O with a broken signature. You wouldn’t expect this to be possible because of this:

Code Block  
Application Specific Information:
dyld: in dlopen()
/System/Library/PrivateFrameworks/TCC.framework/TCC

and this:

Code Block  
System Integrity Protection: enabled

We’re loading TCC and SIP is enabled, so there’s no way that the code could have been modified in a way that breaks the code signature. And that suggests some other issue.

One further oddity is this:

Code Block  
VM Regions Near 0x111c726a0:
    CoreAnimation   111c71000-111c72000 … 
--> …TEXT          111c72000-11202d000 … /Users/*/Documents/*/*.dylib
    …DATA          11202d000-112321000 … /Users/*/Documents/*/*.dylib

Note the paths at the end (the redaction is in the original crash report, not something I did). That’s weird because it suggests that the problematic code isn’t actually TCC itself but something in ~/Documents. And consider this:

Code Block  
Binary Images:
…
0x111c72000 - 0x11202cfff … /Users/USER/Documents/*/libmysqlclient.18.dylib
0x1123bc000 - 0x112414fff … /Users/USER/Documents/*/libssl.1.1.dylib
0x1162fc000 - 0x116474fff … /Users/USER/Documents/*/libcrypto.1.1.dylib

Your app is using three libraries out of ~/Documents. It’s possible that the Application Specific Information info is a red herring and it’s libmysqlclient.18.dylib that’s broken (note that its load address matches the address in VM Regions Near).

So, to summarise the info so far, something about WebKit is touching your copy of libmysqlclient.18.dylib which has a broken signature which is splashing the process.

---

OK, let’s look further up the crashing thread:

Code Block  
0   dyld             … ImageLoaderMachO::getInstallPath() const + 20
1   dyld             … dyld::loadPhase5check(char const*, char const*, dyld::LoadContext const&) + 142
2   dyld             … dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, unsigned int&, …
3   dyld             … dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, unsigned int&, …
4   dyld             … dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, unsigned int&, …
5   dyld             … dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, unsigned int&, …
6   dyld             … dyld::load(char const*, dyld::LoadContext const&, unsigned int&) + 126
7   dyld             … dlopen_internal + 419
8   libdyld.dylib    … dlopen_internal(char const*, int, void*) + 177
9   libdyld.dylib    … dlopen + 28
10  com.apple.WebKit … invocation function for block in TCCLibrary() + 21
11  com.apple.WebKit … initkTCCServiceMicrophone() + 75

Frames 11 through 10 are WebKit loading the TCC framework dynamically. All the remaining frames are the dynamic linker (dyld) doing its thing. It’s hard to see how this could crash.

As a next step I looked at frame 1: What is dyld doing here? Fortunately most of dyld is in the Darwin open source, so we can take a look. Specifically, dyld::loadPhase5check(…) is in src/dyld2.cpp.

The comment for dyld::loadPhase5check(…) says:

Code Block  
// look for path match with existing loaded images

So, here’s what I think is going on:

1. You’ve called WebKit.

2. WebKit is trying to load the TCC framework.

3. dyld is trying to load one of the libraries that TCC framework depends on.

4. As part of that it has to iterate through the list of loaded Mach-O images to see if it’s already loaded.

5. One of those loaded images is libmysqlclient.18.dylib. This has an invalid code signature, so accessing it has crashed the process.

My advice is that you look at the code signature for these three libraries in ~/Documents to see if you can spot what’s wrong.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"