PageTableInjection

Внедрение кода — инъекция вредоносной полезной нагрузки через таблицы страниц (pagetables) PML4.

Введение

Это всего лишь proof-of-concept техники внедрения через таблицы страниц для инъекции вредоносного кода в произвольные пользовательские процессы.
В Windows (и некоторых современных ОС) каждый процесс имеет свой PML4, также известный как Directory Table Base. Таким образом, процесс A не может получить доступ к процессу B без API. Но что, если мы сможем внедрить произвольную запись PML4? Разумеется, запись PML4 будет указывать на соответствующий физический адрес записей — PDP, PD и PT, в точности как в поддерживающем процессе.

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

Давайте посмотрим на буферы поддерживающего и целевого процессов. В данном случае буферы таковы:

• VA поддерживающего процесса: 0x1A45F810000
• VA, внедрённая в целевой процесс: 0x6EA45F810000

Прежде чем перейти к следующему, некоторые могут подумать, что второй адрес (0x6EA45F810000) выглядит странно, ведь обычно мы выделяем буфер через malloc или VirtualAlloc, и виртуальный адрес должен выглядеть как 0x17C7CAC0000, 0x23BE9D80000, 0x19FE76F0000 или что-то подобное. Это связано с тем, что вредоносная запись PML4 не участвует в работе менеджера памяти Windows и не управляется им. Конечно, любой виртуальный адрес в 64-битном процессе Windows потенциально может иметь любое значение в диапазоне пользовательской памяти.

Итак, если мы посмотрим на оба адреса...

0: kd> .process ffff9803d8037080
Implicit process is now ffff9803`d8037080
0: kd> db 0x6EA45F810000 l2
00006ea4`5f810000  4d 5a       MZ

0: kd> !vtop 7968b000 0x6EA45F810000
Amd64VtoP: Virt 00006ea45f810000, pagedir 000000007968b000
Amd64VtoP: PML4E 000000007968b6e8
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 6ea45f810000 translates to physical address 14306000.

0: kd> .process ffff9803d9f6b080
Implicit process is now ffff9803`d9f6b080
0: kd> db 0x1A45F810000 l2
000001a4`5f810000  4d 5a       MZ

0: kd> !vtop 564f6000 0x1A45F810000
Amd64VtoP: Virt 000001a45f810000, pagedir 00000000564f6000
Amd64VtoP: PML4E 00000000564f6018
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 1a45f810000 translates to physical address 14306000.

Оба адреса соответствуют одним и тем же записям таблицы страниц: PDP, PD, PT и физическому адресу. Таким образом, если мы изменим буфер поддерживающего процесса, изменение также отразится и в целевом процессе. Это очень похоже на разделяемую память в Windows, но отличие в том, что область памяти в целевом процессе никогда не будет отображаться ни в одной записи VAD этого процесса. С другой стороны, если буфер поддерживающего процесса освобождается, это также происходит и в целевом процессе, но без очистки записей таблицы страниц целевого процесса, что приводит к ошибке (bugcheck) MEMORY_MANAGEMENT или может вызвать ещё более серьёзную тройную ошибку (triple fault) на CPU.

Проблема

Эта техника имеет серьёзные проблемы со стабильностью, как уже упоминалось: внедрённая вредоносная запись PML4 не участвует в работе менеджера памяти Windows или ядра. Нет никакой гарантии, что поддерживающий процесс будет жив до завершения целевого процесса, и целевой процесс не имеет возможности очистить вредоносную запись PML4 при завершении поддерживающего процесса.

Лицензия

Лицензия MIT, авторские права принадлежат Kento Oki <[email protected]>

Исходный код может содержать внешние компоненты; такие компоненты принадлежат их правообладателям.