[Перевод] Раскрытие памяти (Memory Disclosure) ядра в современных ОС08.07.2018 18:46

Под катом расположен перевод вступительной части документа Detecting Kernel Memory Disclosure with x86 Emulation and Taint Tracking (Статья Project Zero) от Mateusz Jurczyk.

В переведенной части документа:

• специфика языка программирования C (в рамках проблемы раскрытия памяти)
• специфика работы ядер ОС Windows и Linux (в рамках проблемы раскрытия памяти)
• значимость раскрытия памяти ядра и влияние на безопасность ОС
• существующие методы и техники обнаружения и противодействия раскрытия памяти ядра

Хотя в документе пристально рассматриваются механизмы общения привилегированного ядра ОС с пользовательскими приложениями, суть проблемы можно обощить для любой передачи данных между различными доменами безопасности: гипервизор — гостевая машина, привилегированный системный сервис (демон) — GUI приложение, сетевые клиент — сервер и т.д.

Введение

Одной из задач современных операционных систем является обеспечение разделения привилегий между пользовательскими приложениями и ядром ОС. Во-первых к этому относится то, что влияние каждой программы на среду выполнения должно быть ограничено определенной политикой безопасности, а во вторых то, что программы могут получать доступ только к той информации, которую им разрешено читать. Второе сложно обеспечить, учитывая свойства языка C (основного языка программирования, используемого при разработке ядра), которые делают чрезвычайно сложным безопасную передачу данных между различными доменами безопасности.

Современные операционные системы, работающие на платформах x86/x86–64, многопоточны и используют клиент-серверную модель, в которой приложения пользовательского режима (клиенты) выполняются независимо друг от друга и вызывают ядро ОС (сервер) при намерении работать с ресурсом, управляемым системой. Механизм, используемый кодом режима пользователя (ring 3) для вызова заранее определенного набора функций ядра ОС (ring 0), называется системными вызовами (system calls) или (коротко) syscalls. Типичный системный вызов показан на рисунке 1:

Рисунок 1: Жизненный цикл системного вызова.

Очень важно избегать непреднамеренной утечки содержимого памяти ядра при взаимодействии с программами пользовательского режима. Существует значительный риск раскрытия чувствительных данных ядра ОС. Данные могут неявно передаваться в выходных параметрах безопасных (с остальных точек зрения) системных вызовов.

Раскрытие привилегированной системной памяти происходит, когда ядро ОС возвращает регион памяти, больший (избыточного размера), чем необходимо для хранения соответствующей информации (содержащейся внутри). Часто избыточные байты содержат данные, которые были заполнены в другом контексте, а затем память не была предварительно инициализирована, что предотвратило бы распространение информации в новые структуры данных.

Специфика языка программирования C

В этом разделе мы рассмотрим несколько аспектов языка C, которые наиболее важны для проблемы раскрытия памяти.

Неопределенное состояние неинициализированных переменных

Отдельные переменные простых типов (таких, как char или int), а также члены структур данных (массивы, структуры и объединения) остаются в неопределенном состоянии до первой инициализации (вне зависимости от размещения их на стеке или в куче). Соответствующие цитаты из спецификации C11 (ISO/IEC 9899:201x Committee Draft N1570, April 2011):

6.7.9 Initialization
…
10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

7.22.3.4 The malloc function
…
2 The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

7.22.3.5 The realloc function
…
2 The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size. The contents of the new object shall be the same as that of the old object prior to deallocation, up to the lesser of the new and old sizes. Any bytes in the new object beyond the size of the old object have indeterminate values.

Наиболее применима к системному коду та часть, что относится к объектам, расположенным на стеке, поскольку ядро ОС обычно имеет интерфейсы динамического выделения с их собственной семантикой (не обязательно совместимые со стандартной библиотекой C, как будет описано далее).

Насколько нам известно, ни один из трех самых популярных компиляторов C для Windows и Linux (Microsoft C/C++ Compiler, gcc, LLVM) не создает код, который предварительно инициализирует неинициализированные программистом переменные на стеке в режиме Release-сборки (или ее эквивалента). Существуют опции компилятора, позволяющие помечать фреймы стека специальными байтами — маркерами (/RTCs в Microsoft Visual Studio, например), но они не используются в Release-сборках по соображениям производительности. В результате неинициализированные переменные на стеке наследуют старые значения соответствующих областей памяти.

Рассмотрим пример стандартной реализации вымышленного системного вызова Windows, который умножает входное целое на два и возвращает результат умножения (листинг 1). Очевидно, что в частном случае (InputValue == 0) переменная OutputValue остается неинициализированной и копируется обратно клиенту. Такая ошибка позволяет раскрывать четыре байта памяти стека ядра при каждом вызове.

NTSTATUS NTAPI NtMultiplyByTwo(DWORD InputValue, LPDWORD OutputPointer) {
    DWORD OutputValue;

    if (InputValue != 0) { 
        OutputValue = InputValue * 2;
    }

    *OutputPointer = OutputValue;
    return STATUS_SUCCESS;
}

Листинг 1: Раскрытие памяти через неинициализированную локальную переменную.

Утечки через неинициализированную локальную переменную на практике не очень распространены: с одной стороны современные компиляторы часто обнаруживают и предупреждают о таких проблемах, с другой стороны подобные утечки являются функциональными ошибками, которые могут быть обнаружены во время разработки или тестирования. Однако второй пример (в листинге 2) показывает, что утечка может также происходить через поле структуры.

В этом случае зарезервированное поле структуры никогда явно не используется в коде, но все же копируется обратно в пользовательский режим и, следовательно, также раскрывает четыре байта памяти ядра вызывающему коду. В этом примере отчетливо видно, что инициализация каждого поля каждой структуры, возвращаемой клиенту, для всех веток исполнения кода является непростой задачей. Во многих случаях принудительная инициализация выглядит нелогично, особенно если это поле не играет никакой практической роли. Но именно тот факт, что не проинициализированная переменная (или поле структуры) на стеке (или в куче) принимает содержимое данных, ранее сохраненных в этой областях памяти (в контексте другой операции), лежит в основе проблемы раскрытия памяти ядра.

typedef struct _SYSCALL_OUTPUT {
    DWORD Sum; 
    DWORD Product; 
    DWORD Reserved;
} SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; 

NTSTATUS NTAPI NtArithOperations(
    DWORD InputValue,
    PSYSCALL_OUTPUT OutputPointer
) { 
    SYSCALL_OUTPUT OutputStruct;

    OutputStruct.Sum = InputValue + 2; 
    OutputStruct.Product = InputValue * 2; 

    RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); 

    return STATUS_SUCCESS;
}

Листинг 2: Раскрытие памяти через зарезервированное поле структуры.

Выравнивание структур и заполняющие (padding) байты

Инициализация всех полей выходной структуры является хорошим началом, чтобы избежать раскрытия памяти. Но и этого не достаточно, что бы гарантировать, что в низкоуровневом представлении отсутствуют неинициализированные байты. Давайте снова обратимся к спецификации C11:

6.5.3.4 The sizeof and Alignof operators
…
4 […] When applied to an operand that has structure or union type, the result is the total number of bytes in such an object, including internal and trailing padding.

6.2.8 Alignment of objects
1 Complete object types have alignment requirements which place restrictions on the addresses at which objects of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. […]

6.7.2.1 Structure and union specifiers
…
17 There may be unnamed padding at the end of a structure or union.

То есть компиляторы языка С для x86(-64) архитектур применяют естественное выравнивание полей структур (имеющих примитивный тип): каждое такое поле выравнивается на N байт, где N — размер поля. Кроме того, целые структуры и объединения также выровнены, когда они объявляются в массиве, при этом выполняется требование к выравниванию вложенных полей. Чтобы обеспечить выравнивание, неявные байты заполнения (padding) вставляются в структуры там, где это необходимо. Хотя они не доступны напрямую в исходном коде, эти байты также наследуют старые значения из областей памяти и могут передавать информацию в пользовательский режим.

В примере из листинга 3 структура SYSCALL_OUTPUT возвращается обратно вызывающему коду. Она содержит 4-х и 8-ми байтовые поля, разделенные 4-мя байтами заполнения (padding), необходимыми для того, что бы адрес поля LargeSum стал кратен 8-ми. Несмотря на то, что оба поля правильно инициализированы, байты заполнения (padding) не заданы явно, что опять-таки приводит к раскрытию памяти стека ядра. Специфика расположение структуры в памяти показана на рисунке 2.

typedef struct _SYSCALL_OUTPUT {
    DWORD Sum; 
    QWORD LargeSum;
} SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; 

NTSTATUS NTAPI NtSmallSum(
    DWORD InputValue,
    PSYSCALL_OUTPUT OutputPointer
) { 
    SYSCALL_OUTPUT OutputStruct;

    OutputStruct.Sum = InputValue + 2;
    OutputStruct.LargeSum = 0;

    RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); 

    return STATUS_SUCCESS;
}

Листинг 3: Раскрытие памяти через выравнивание структуры.

Рисунок 2: Представление структуры в памяти с учетом выравнивания.

Утечки через выравнивания относительно распространены, так как достаточно много выходных параметров системных вызовов представлены структурами. Проблема особенно остро встает для 64-х битных платформ, где размер указателей, size_t и подобных типов увеличивается с 4 до 8 байт, что приводит к появлению заполнения (padding), необходимого для выравнивания полей таких структур.

Поскольку байты заполнения (padding) не могут быть адресованы в исходном коде, необходимо использовать memset или аналогичную функцию для сброса всей области памяти структуры до инициализации любого из ее полей и копирования ее в пользовательский режим, например:

    memset(&OutputStruct, 0, sizeof(OutputStruct));

Тем не менее, Seacord R.C. в своей книге «The CERT C Coding Standard, Second Edition: 98 Rules for Developing Safe, Reliable, and Secure Systems. Addison-Wesley Professional» 2014 утверждает, что это не идеальное решение, поскольку байты заполнения (padding) могут по-прежнему быть сбиты после вызова memset, например, как побочный эффект операций со смежными полями. Озабоченность может быть оправдана следующим утверждением в спецификации С:

6.2.6 Representations of types
6.2.6.1 General
…
6 When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values. […]

Однако на практике ни один из компиляторов C, которые мы тестировали, не читал и не писал за пределами областей памяти явно объявленных полей. Похоже, что это мнение разделяют разработчики операционных системы, которые используют memset.

Объединения (Unions) и поля разного размера

Объединения — еще одна сложная конструкция языка C в контексте общения с менее привилегированным вызывающим кодом. Рассмотрим как спецификация C11 описывает представление объединений в памяти:

6.2.5 Types
…
20 Any number of derived types can be constructed from the object and function types, as follows: […] A union type describes an overlapping nonempty set of member objects, each of which has an optionally specified name and possibly distinct type.

6.7.2.1 Structure and union specifiers
…
6 As discussed in 6.2.5, a structure is a type consisting of a sequence of members, whose storage is allocated in an ordered sequence, and a union is a type consisting of a sequence of members whose storage overlap.
…
16 The size of a union is sufficient to contain the largest of its members. The value of at most one of the members can be stored in a union object at any time.

Проблема состоит в том, что если объединение состоит из нескольких полей разного размера и явно инициализировано только одно полей меньшего размера, то оставшиеся байты, выделенные для размещения больших полей, остаются неинициализированными. Давайте рассмотрим пример гипотетического обработчика системных вызовов, представленный в листинге 4, вместе с распределением памяти объединения SYSCALL_OUTPUT, показанным на рисунке 3.

typedef union _SYSCALL_OUTPUT {
    DWORD Sum; 
    QWORD LargeSum;
} SYSCALL_OUTPUT, *PSYSCALL_OUTPUT; 

NTSTATUS NTAPI NtSmallSum(
    DWORD InputValue,
    PSYSCALL_OUTPUT OutputPointer
) { 
    SYSCALL_OUTPUT OutputStruct;

    OutputStruct.Sum = InputValue + 2;

    RtlCopyMemory(OutputPointer, &OutputStruct, sizeof(SYSCALL_OUTPUT)); 

    return STATUS_SUCCESS;
}

Листинг 4: Раскрытие памяти через частичную инициализацию объединения.

Рисунок 3: Представление объединения в памяти с учетом выравнивания.

Получается, что общий размер объединения SYSCALL_OUTPUT составляет 8 байт (из-за размера большего поля LargeSum). Тем не менее, функция задает только значение меньшего поля, оставляя 4 конечных байта неинициализированными, что впоследствии и приводит к утечке их клиентскому приложению.

Безопасная реализация должна устанавливать только поле Sum в пользовательском адресном пространстве, а не копировать весь объект с потенциально неиспользуемыми областями памяти. Еще один рабочий вариант исправления — вызов функции memset для обнуления копии объединения в памяти ядра до установки любого из его полей и передачи его обратно в пользовательский режим.

Небезопасный sizeof

Как показано в двух предыдущих подразделах, использование оператора sizeof может напрямую или косвенно способствовать раскрытию памяти ядра, провоцируя копирование большего количества данных, чем ранее инициализировалось.

В языке C отсутствует аппарат, необходимый для безопасного переноса данных из ядра в пользовательское пространство — или, в более общем плане, между любыми разными контекстами безопасности. Язык не содержит метаданных времени исполнения, которые могут явно указать, какие байты были установлены в каждой структуре данных, которая используется для взаимодействия с ядром ОС. В результате ответственность ложиться на программиста, который должен сам определять какие части каждого объекта должны быть переданы вызывающему коду. Если делать правильно, то нужно написать отдельную функцию безопасного копирования для каждой структуры выходных данных, используемых в системных вызовах. Что в свою очередь приведет к раздуванию размера кода, ухудшению его читаемости и в целом будет утомительной и трудоемкой задачей.

С другой стороны, удобно и просто копировать всю область памяти ядра с помощью одного вызова memcpy и аргумента sizeof, и пусть клиент определит, какие части выходных данных будут использоваться. Получается, что это этот подход используется сегодня в Windows и Linux. А когда обнаруживается конкретный случай утечки информации, патч с вызовом memset незамедлительно предоставляется и распространяется производителем ОС. К сожалению, это не решает проблему в общем случае.

Специфика конкретных ОС

Существуют определенные решения для проектирования ядра, методы программирования и шаблоны кода, которые влияют на то, насколько склонна операционная система к уязвимостям на раскрытие памяти. Именно они рассматриваются в следующих подразделах.

Переиспользование динамической памяти

Текущие распределители (allocator) динамической памяти (как в режиме пользователя, так и в режиме ядра) сильно оптимизированы, так как их производительность оказывает значительное влияние на производительность всей системы. Одной из наиболее важных оптимизаций является повторное использование памяти: при освобождении соответствующая память редко полностью отбрасывается, вместо этого она сохраняется в списке регионов, готовых к возврату при следующем запросе на выделение. Чтобы сэкономить циклы ЦП, области памяти по умолчанию не очищаются между освобождением и новым выделением. В результате этого получается, что две несвязанные части ядра работают с одним и тем же диапазоном памяти в течении короткого времени. Это означает, что утечка содержимого динамической памяти ядра позволяет раскрывать данные различных компонентов ОС.

В следующих параграфах мы приводим краткий обзор распределителей памяти (allocators), используемых в ядрах Windows и Linux, и их наиболее примечательных качеств.

Windows
Ключевой функцией диспетчера пула ядра Windows является ExAllocatePoolWithTag, которая может вызываться напрямую или через одну из доступных оболочек: ExAllocatePool{∅, Ex, WithQuotaTag, WithTagPriority}. Ни одна из этих функций не сбрасывает содержимое возвращаемой памяти, ни по умолчанию, ни через любые входные флаги. Напротив, все они имеют следующее предупреждение в своих соответствующих документах документации MSDN:

Note Memory that function allocates is uninitialized. A kernel-mode driver must first zero this memory if it is going to make it visible to user-mode software (to avoid leaking potentially privileged contents).

Вызывающий код может выбрать один из шести основных типов пулов: NonPagedPool, NonPagedPoolNx, NonPagedPoolSession, NonPagedPoolSessionNx, PagedPool и PagedPoolSession. Каждый из них имеет отдельный регион в виртуальном адресном пространстве, и поэтому выделенные области памяти могут быть повторно использованы только в пределах этого же типа пула. Частота повторного использования кусков памяти очень высока, а обнуленные области обычно возвращаются только в том случае, если подходящая запись не найдена в lookaside-списках, или запрос настолько велик, что требуются новые страницы памяти. Другими словами, в настоящее время практически нет факторов, препятствующих раскрытию памяти пула в Windows, и почти каждая такая ошибка может быть использована для утечки конфиденциальных данных из разных частей ядра.

Linux
Ядро Linux имеет три основных интерфейса для динамического выделения памяти:

• kmalloc — общая функция, используемая для выделения блоков памяти произвольного размера (непрерывных как в виртуальном, так и в физическом адресном пространстве), использует распределение памяти slab.
• kmem_cache_create и kmem_cache_alloc — специализированный механизм выделения объектов фиксированного размера (структур, например), так же использует распределение памяти slab.
• vmalloc — редко используемая функция выделения, возвращающая регионы, непрерывность которых не гарантирована на уровне физической памяти.

Эти функции (сами по себе) не гарантируют, что выделенные регионы не будут содержать старые (потенциально конфиденциальные) данные, что делает возможным раскрытие памяти кучи ядра. Однако существует несколько способов, используя которые вызывающий код может запрашивать обнуленную память:

• Функция kmalloc имеет аналог kzalloc, который гарантирует, что возвращенная память очищена.
• Дополнительный флаг __GFP_ZERO может быть передан в kmalloc, kmem_cache_alloc и некоторые другие функции для достижения того же результата.
• kmem_cache_create принимает указатель на необязательную функцию-конструктор, вызываемую для предварительной инициализации каждого объекта, прежде чем вернуть его вызывающему коду. Конструктор может быть реализован как обертка вокруг memset для обнуления заданной области памяти.

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

Массивы фиксированного размера

Доступ к некоторому количеству ресурсов ОС можно получить по их тестовым именам. Разнообразие именованных ресурсов в Windows очень велико, например: файлы и директории, ключи и значения ключей реестра, окна, шрифты и многое другое. Для некоторых из них длина имени ограничена и выражается константой, такой как MAX_PATH (260) или LF_FACESIZE (32). В таких случаях разработчики ядра часто упрощают код, объявляя буферы максимально допустимого размера и копируя их целиком (например, используя ключевое слово sizeof) вместо того, чтобы работать только с соответствующей частью строки. Это особенно удобно, если строки являются членами более крупных структур. Такие объекты можно свободно перемещать в памяти, не беспокоясь об управлении указателями на динамическую память.

Как и следовало ожидать, большие буферы редко используются полностью, а оставшееся место для хранения часто не сбрасывается. Это может привести к особенно сильным утечкам длинных непрерывных областей памяти ядра. В примере, показанном в листинге 5, системный вызов использует функцию RtlGetSystemPath для загрузки системного пути в локальный буфер, и если вызов завершается успешно, все 260 байтов передаются вызывающему, независимо от фактической длины строки.

NTSTATUS NTAPI NtGetSystemPath(PCHAR OutputPath) {
    CHAR SystemPath[MAX_PATH];
    NTSTATUS Status;

    Status = RtlGetSystemPath(SystemPath, sizeof(SystemPath));
    if (NT_SUCCESS(Status)) {
        RtlCopyMemory(OutputPath, SystemPath, sizeof(SystemPath));
    }

    return Status;
}

Листинг 5: Раскрытие памяти через частичную инициализацию буфера строки.

Регион памяти, скопированный обратно в пользовательское пространство в этом примере, показан на рисунке 4.

Рисунок 4: Память частично инициализированного буфера строки.

Безопасная реализация должна возвращать только запрошенный путь, а не весь буфер, используемый для хранения. Этот пример еще раз демонстрирует, как оценка размера данных оператором sizeof (используемого как параметр для RtlCopyMemory) может быть совершенно неверной по отношению к фактическому количеству данных, которое ядро должно передать в пользовательскую область.

Произвольный размер выходных данных системного вызова

Большинство системных вызовов принимают указатели на выходные данные из пользовательского режима вместе с размером буфера. В большинстве случаев информацию о размере следует использовать только для определения того, достаточен ли предоставленный буфер для получения выходных данных системного вызова. Не следует использовать весь размер предоставленного выходного буфера для задания объема копируемой памяти. Тем не менее, мы наблюдаем случаи, когда ядро будет пытаться использовать каждый байт выходного буфера пользователя, не считая количества фактических данных, которые необходимо скопировать. Пример такого поведения показан в листинге 6.

NTSTATUS NTAPI NtMagicValues(LPDWORD OutputPointer, DWORD OutputLength) {
    if (OutputLength < 3 * sizeof(DWORD)) {
        return STATUS_BUFFER_TOO_SMALL;
    }

    LPDWORD KernelBuffer = Allocate(OutputLength);

    KernelBuffer[0] = 0xdeadbeef;
    KernelBuffer[1] = 0xbadc0ffe;
    KernelBuffer[2] = 0xcafed00d;

    RtlCopyMemory(OutputPointer, KernelBuffer, OutputLength);
    Free(KernelBuffer);

    return STATUS_SUCCESS;
}

Листинг 6: Раскрытие памяти через выходной буфер произвольного размера.

Целью системного вызова является предоставление вызывающему коду трех специальных 32-х битных значений, занимающих в общей сложности 12 байт. Хотя проверка правильности размера буфера в самом начале функции верна, использование аргумента OutputLength должно на этом и заканчиваться. Зная, что выходной буфер имеет достаточный размер, чтобы сохранить результат, ядро может выделить 12 байт памяти, заполнить ее и скопировать содержимое обратно в предоставленный буфер пользовательского режима. А вместо этого системный вызов выделяет блок пула (причем с контролируемой пользователем длиной) и копирует выделенную память целиком в пользовательское пространство. Получается, что все байты, кроме первых 12-ти, не инициализируются и ошибочно раскрываются пользователю, как показано на рисунке 5.

Рисунок 5: Память буфера произвольного размера.

Схема, обсуждаемая в этом разделе, особенно характерна для Windows. Подобная ошибка может предоставить злоумышленнику чрезвычайно полезный примитив для раскрытия памяти:

• Оптимизация, часто используемая в системных вызовах Windows, заключается в использовании буферов на основе стека для небольших размеров и выделение памяти из пулов для более крупных. В сочетании с подобной утечкой это может облегчить раскрытие как стека ядра, так и пула с помощью одной уязвимости.
• Возможность контролировать размер раскрываемых данных из пула дает злоумышленнику возможность управлять типом конфиденциальной информации. Это становится возможным, учитывая современные механизмы распределения памяти, имеющие тенденцию к кэшированию областей памяти для последующих запросов выделения памяти с тем же размером буфера. Что дает возможность читать специфические данные, недавно освобожденные другим (в общем случае — не связанным) компонентом ядра.

Таким образом, это один из самых опасных типов раскрытия информации. Безопасная реализация должна отслеживать количество байтов, записанных во временное хранилище ядра, и передавая только этот объем данных клиенту.

Факторы, способствующие появлению ошибок раскрытия памяти

Здесь мы расскажем о том, какие существуют проблемы с выявлением ошибок раскрытия памяти в ходе разработки. Что в течение многих лет способствовало отсутствию признания проблемы, что в свою очередь привело к нагромождению в ядре Windows десятков ошибок раскрытия памяти.

Отсутствие видимых последствий
Как правило, ошибки раскрытия информации более сложны для обнаружения, чем нарушения памяти. Последние обычно проявляются в виде сбоев программного обеспечения, особенно в сочетании со специализированными механизмами: AddressSanitizer, PageHeap или Special Pool. Раскрытие информации, напротив, не вызывает каких-либо наблюдаемых проблем и не может быть легко распознано программными решениями. Конфиденциальность любой информации очень субъективна и требуется оценка человеком, что бы определить легитимность предоставленной информации в контексте безопасности. С другой стороны, когда гигабайты траффика передаются между ядром и пользовательским пространством, из памяти программ в файлы на диск, с одной машины на другую через сеть и между контекстами безопасности, не представляется возможным вручную просмотреть весь этот трафик, что бы найти случаи ошибок раскрытия памяти. В результате многие ошибки могут активно сливать данных в течение многих лет, прежде чем они будут замечены (если вообще будут замечены).

Тот факт, что уведомление о подобных утечках не дает ощутимой обратной связи от разработчиков ядра, также означает, что они не учатся на своих ошибках. И что они будут повторять одни и те же небезопасные шаблоны кода в нескольких местах, так как они не знают об этом классе ошибок и не предпринимают действий к предотвращению возникновение подобных проблем.

Утечки, скрытые за системным API
Типичные клиентские приложения реализуют свою функциональность с использованием высокоуровневого системного API, особенно в Windows (Win32/User32 API). API часто отвечает за преобразование входных параметров во внутренние структуры, принятые системными вызовами, и аналогичным образом преобразует выходные данные системных вызовов в формат, понятный вызывающему коду клиентского приложения. В этом случае содержимое памяти, раскрываемое ядром, может быть отброшено системной библиотекой пользовательского режима и, следовательно, никогда не будет передана обратно программе. Это еще больше уменьшает видимость утечек и снижает вероятность их обнаружения при разработке обычного программного обеспечения.

Значимость и влияние на безопасность системы

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

В общем, класс подобных ошибок кажется вполне полезным, как одно из звеньев в длинной цепочке локального повышения привилегий. В настоящее время основная техника, которая основана на неразглашении данных это KASLR (Kernel Address Space Layout Randomization), а расположение различных объектов в адресном пространстве ядра является одним из самых распространенных типов утечек данных. Реальный пример: эксплойт ядра Windows, обнаруженный в дампе Hacking Team в июле 2015 года (Juan Vazquez. Revisiting an Info Leak) в котором использовалось раскрытие памяти пула для определения (derandomize) базового адреса загрузки драйвера win32k.sys, впоследствии используемого для применения в другой уязвимости. Кстати, этот же дефект был обнаружен в тоже время Matt Tait’ом из Google Project Zero (Kernel-mode ASLR leak via uninitialized memory returned to usermode by NtGdiGetTextMetrics) и исправлен в бюллетене MS15–080 (CVE-2015–2433).

Стеки
Различие между стеком и динамической памятью (пулы/кучи) заключается в том, что в стеках обычно хранятся данные, связанные непосредственно с потоком управления (control flow), такие как: адреса модулей ядра, адреса динамической памяти, и секретные значения, установленные механизмами безопасности, такими как StackGuard на Linux и /GS на Windows. Это значимые фрагменты информации, которые могут быть немедленно применены потенциальным злоумышленником в совокупности с эксплоитами порчи памяти. Тем не менее разнообразие данных на стеке ограничено, что позволяет предположить, что эксплуатация утечки стека не представляет большой ценности в виде автономной уязвимости.

Динамическая память (пулы/кучи)
Динамическая память ядра (пулы/кучи) содержит адреса исполняемых модулей, адреса динамически выделенной памяти, а так же ряд конфиденциальных данных, обрабатываемых различными компонентами системы: дисковыми драйверами, драйверами файловых систем, сетевыми драйверами, драйверами видео и так далее. Утечка этой информации позволяет злоумышленнику эффективно следить за деятельностью привилегированных сервисов и других пользователей системы, потенциально получая содержимое конфиденциальных данных, которые имеют ценность сами по себе. Плюс полученные данные могут использоваться при эксплуатации другой ошибки. В целом, проблема эксплуатируемой утечки конкретных типов данных из ядра (содержимого файлов, сетевого трафика или паролей) остается открытой и, к сожалению, она не исследована в должной мере.

Другие существующие исследования

Microsoft Windows

Обнаружение
До 2015 года в публичных источниках практически не обсуждалась проблема раскрытия памяти в Windows. В июле 2015 года Matt Tait сообщил о проблеме раскрытия неинициализированной памяти пула через системный вызов win32k! NtGdiGetTextMetrics. Использование этой же проблемы было обнаружено в эксплойте ядра Windows из дампа Hacking Team. Насколько нам известно, это было первое публичное доказательств того, что уязвимости этого типа были успешно использованы, как часть цепочки 0-day эксплойта по локальному повышению привилегий в Windows.

Так же в 2015, WanderingGlitch (HP Zero Day Initiative) был упомянут в восьми обнаруженных уязвимостях раскрытия памяти ядра (Acknowledgments — 2015). Некоторые из этих уязвимостей будут позже рассмотрены автором на конференции Ruxcon 2016 (посвящённой информационной безопасности) во время доклада «Leaking Windows Kernel Pointers».

И наконец, в июне 2017 fanxiaocao и pjf из IceSword Lab (Qihoo 360) опубликовали статью «Automatically Discovering Windows Kernel Information Leak Vulnerabilities», где описали свой инструмент, который позволил им обнаружить суммарно 14 утечек в 2017 году (8 из которых пересекаются с обнаруженными нами). Во многом их проект похож на наш Bochspwn Reloaded, в частности в том как он отслеживает стеки ядра и выделения в пулах, и автоматизирует обнаружение утечек анализируя все записи памяти ядра в пользовательское пространство. Ключевое различие заключается в использовании виртуальной машины VMware вместо полной программной эмуляции (Bochs) и отсутствии реализации слежения за всей неинициализированной памятью ядра. Насколько нам известно, помимо Bochspwn Reloaded, это была первая попытка автоматизированной идентификации раскрытия памяти ядра в операционной системе с закрытым исходным кодом.

Хотя это напрямую не связано с уязвимостями раскрытия памяти, стоит отметить, что еще в 2010–2011 годах были обнаружены утечки нескольких адресов ядра через неинициализированные переменные, возвращаемые в системных вызовах win32k: «Challenge: On 32bit Windows7, explain where the upper 16bits of eax come from after a call to NtUserRegisterClassExWOW ()» и «Subtle information disclosure in WIN32K.SYS syscall return values». Против обнаруженных проблем должны были быть приняты меры в Windows 8, но в 2015 году Matt Tait заметил, что исправления были не полными и обнаружил еще несколько новых проблем: Google Project Zero Bug Tracker.

Противодействие
Одним из немногих общих механизмов противодействия (о котором мы знаем), является то, что с июня 2017 года диспетчер ввода-вывода Windows сбрасывает содержимое выходной памяти для всех операций ввода-вывода, обработанных драйверами ядра: Joseph Bialek — «Anyone notice my change to the Windows IO Manager to generically kill a class of info disclosure? BufferedIO output buffer is always zero«d». Это изменение уничтожило большой класс утечек, когда IOCTL-обработчик не заполнял часть байт выходного буфера или весь буфер целиком.

Еще одним незначительным улучшением безопасности является тот факт, что в Visual Studio 15.5 и новее POD-структуры, которые инициализируются объявлением с использованием директивы »= {0}», заполняются нулями целиком. Предыдущие версии обнуляли каждое из полей структуры, оставляя возможность потенциальной утечки в padding-байтах (выравнивание) между полями структуры.

Linux

В отличие от Windows, в сообществе Linux в течение многих лет обсуждали проблемы раскрытия памяти, всплеск интереса к этой теме начался приблизительно в 2010 году. С тех пор был разработан ряд исследовательских проектов, в которых основное внимание уделяется автоматизированному обнаружению утечек данных ядра и уменьшению (или полному аннулированию) влияния предполагаемых (но неизвестных на текущий момент) проблем. Мы считаем, что разрыв в современном уровне техник между Windows и Linux в первую очередь обусловлен природой открытого исходного кода последнего, что позволяет легко экспериментировать с различными подходами — статическими, динамическими и их сочетаниями.

Обнаружение
В течении последнего

© Habrahabr.ru