Конфигурация

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

Су­щес­тву­ет нес­коль­ко спо­собов задать пра­виль­ную кон­фигура­цию, но мы выберем menuconfig. Он удо­бен и нет­ребова­телен к GUI. Выпол­няем коман­ду make menuconfig и наб­люда­ем сле­дующую кар­тину.

Для того что­бы у нас появи­лись отла­доч­ные сим­волы, идем в сек­цию Kernel hacking → Compile-time checks and compiler options. Тут надо будет выб­рать Compile the kernel with debug info и Provide GDB scripts for kernel debugging. Кро­ме отла­доч­ных сим­волов, мы получим очень полез­ный скрипт vmlinux-gdb.py. Это модуль для GDB, который поможет нам в опре­деле­нии таких вещей, как базовый адрес модуля в памяти ядра.

Те­перь надо убрать про­тек­тор сте­ка, что­бы наш модуль был экс­плу­ати­руем. Для это­го воз­вра­щаем­ся на глав­ный экран кон­фигура­ции, заходим в раз­дел General architecture-dependent options и отклю­чаем фун­кцию Stack Protector buffer overflow detection.

Мож­но нажать на кноп­ку Save и выходить из окна нас­трой­ки. Что дела­ет эта нас­трой­ка, мы уви­дим далее.

Сборка ядра

Тут сов­сем ничего слож­ного. Выпол­няем коман­ду make -j<threads>, где threads — это количес­тво потоков, которые мы хотим исполь­зовать для сбор­ки ядра, и нас­лажда­емся про­цес­сом ком­пиляции.

Ско­рость сбор­ки зависит от про­цес­сора: око­ло пяти минут она зай­мет на мощ­ном компь­юте­ре и нам­ного доль­ше — на сла­бом. Можешь не ждать окон­чания ком­пиляции и про­дол­жать читать статью.

Модуль ядра

В ядре Linux есть такое понятие, как character device. По‑прос­тому, это некото­рое устрой­ство, с которым мож­но делать такие эле­мен­тарные опе­рации, как чте­ние из него и запись. Но иног­да, как ни парадок­саль­но, это­го устрой­ства в нашем компь­юте­ре нет. Нап­ример, сущес­тву­ет некий девайс, име­ющий путь /dev/zero, и, если мы будем читать из это­го устрой­ства, мы получим нули (нуль‑бай­ты или x00, если записы­вать в нотации C). Такие устрой­ства называ­ются вир­туаль­ными, и в ядре есть спе­циаль­ные обра­бот­чики на чте­ние и запись для них. Мы же напишем модуль ядра, который будет пре­дос­тавлять нам запись в устрой­ство. Назовем его /dev/vuln, а фун­кция записи в это устрой­ство, которая вызыва­ется при сис­темном вызове write, будет содер­жать уяз­вимость перепол­нения буфера.

Код модуля и пояснения

Соз­дадим в пап­ке с исходным кодом ядра вло­жен­ную пап­ку с име­нем vuln, где будет находить­ся модуль, и помес­тим там файл vuln.c вот с таким кон­тентом:

Этот модуль соз­даст в /dev устрой­ство vuln, которое будет поз­волять писать в него дан­ные. Путь у него прос­той: /dev/vuln. Любопыт­ный читатель может поин­тересо­вать­ся, что за фун­кции оста­лись без ком­мента­риев? Их зна­чение мож­но поис­кать вот в этом ре­пози­тории. В нем, ско­рее все­го, оты­щут­ся все фун­кции, на которые есть докумен­тация в ядре Linux в виде стра­ниц man.

Уязвимость

Об­рати вни­мание на фун­кцию vuln_write. На сте­ке выделя­ется 128 байт для сооб­щения, которое будет написа­но в наше устрой­ство, а потом выведет­ся в kmsg, устрой­ство для логов ядра. Одна­ко и сооб­щение, и его раз­мер кон­тро­лиру­ются поль­зовате­лем, что поз­воля­ет ему записать нам­ного боль­ше, чем положе­но изна­чаль­но. Здесь оче­вид­но перепол­нение буфера на сте­ке, с пос­леду­ющим кон­тро­лем регис­тра RIP (Relative Instruction Pointer), что поз­воля­ет нам сде­лать ROP Chain. Мы погово­рим об этом в раз­деле, пос­вящен­ном экс­плу­ата­ции уяз­вимос­ти.

Сборка модуля

Сбор­ка модуля дос­таточ­но три­виаль­ная задача. Для это­го в пап­ке с исходным кодом модуля надо соз­дать Makefile вот с таким кон­тентом:

Пос­ле это­го в пап­ке появит­ся файл vuln.ko. Рас­ширение ko озна­чает Kernel Object, он нес­коль­ко отли­чает­ся от обыч­ных объ­ектов .o. Получа­ется, мы уже соб­рали ядро и модуль для него. Для запус­ка в QEMU оста­лось про­делать еще нес­коль­ко опе­раций.

Rootfs

Воп­реки рас­простра­нен­ному мне­нию, Linux не явля­ется опе­раци­онной сис­темой, если рас­смат­ривать его как отдель­ную прог­рамму. Это лишь ядро, которое в совокуп­ности с ути­лита­ми и прог­рамма­ми GNU дает пол­ноцен­ную рабочую РС. Она, кста­ти, так и называ­ется — GNU/Linux. То есть если ты запус­тишь Linux прос­то так, то он выдаст Kernel panic, сооб­щив об отсутс­твии фай­ловой сис­темы, которую мож­но при­нять за кор­невую. Даже если таковая есть, ядро пер­вым делом попыта­ется запус­тить init, бинар­ник, который явля­ется глав­ным про­цес­сом‑демоном в сис­теме, запус­кающим все служ­бы и осталь­ные про­цес­сы. Если это­го фай­ла нет или он работа­ет неп­равиль­но, ядро выдаст панику. Поэто­му нам нужен раз­дел с userspace-прог­рамма­ми. Далее я буду исполь­зовать pacstrap, скрипт для уста­нов­ки Arch Linux. Если у тебя Debian-подоб­ная сис­тема, ты можешь исполь­зовать debootstrap.

Возможные варианты

Су­щес­тву­ет мно­го раз­ных вари­антов соб­рать пол­ностью рабочую сис­тему: как минимум, есть LFS (Linux From Scratch), но это уже слиш­ком слож­но. Так­же есть вари­ант с соз­дани­ем initramfs (файл с минималь­ной фай­ловой сис­темой, необ­ходимый для выпол­нения некото­рых задач до заг­рузки основной сис­темы). Но минус это­го спо­соба в том, что такой диск не очень прос­то сде­лать, а редак­тировать еще слож­нее: его при­дет­ся пересо­бирать. Поэто­му мы выберем дру­гой вари­ант — соз­дание пол­ноцен­ной фай­ловой сис­темы ext4 в фай­ле. Давай раз­берем­ся, как мы будем это делать.

Создание диска

Для начала надо отвести мес­то под саму фай­ловую сис­тему. Для это­го выпол­ним коман­ду dd if=/dev/zero of=./rootfs.img bs=1G count=2. Дан­ная коман­да запол­нит rootfs.img нулями, и уста­новим его раз­мер в 2 Гбайт. Пос­ле это­го надо соз­дать раз­дел ext4 в этом фай­ле. Для это­го запус­каем mkfs.ext4 ./rootfs.img. Нам не тре­буют­ся пра­ва супер­поль­зовате­ля, потому что фай­ловая сис­тема соз­дает­ся в нашем фай­ле. Теперь оста­ется пос­леднее, что мы сде­лаем перед уста­нов­кой сис­темы: sudo mount ./rootfs.img /mnt. Теперь пра­ва супер­поль­зовате­ля нам понадо­бят­ся для того, что­бы смон­тировать эту фай­ловую сис­тему и делать манипу­ляции уже в ней.

Установка Arch

Зву­чит страш­но. На самом деле, если речь идет о Manjaro или дру­гой Arch Linux подоб­ной сис­теме, все край­не прос­то. В репози­тори­ях име­ется пакет под наз­вани­ем arch-install-scripts, где находит­ся pacstrap. Пос­ле уста­нов­ки дан­ного пакета выпол­няем коман­ду sudo pacstrap /mnt base и ждем, пока ска­чают­ся все основные пакеты.

По­том надо будет ско­пиро­вать vuln.ko коман­дой

Мо­дуль в сис­теме, все хорошо.

Небольшая конфигурация изнутри

Те­перь нам нуж­но нас­тро­ить пароль супер­поль­зовате­ля, что­бы вой­ти в сис­тему. Вос­поль­зуем­ся arch-chroot, который авто­мати­чес­ки под­готовит все окру­жение в соз­данной сис­теме. Для это­го запус­каем коман­ду sudo arch-chroot /mnt, а затем — passwd. Таким обра­зом мы смо­жем вой­ти в сис­тему, ког­да заг­рузим­ся.

Так­же нам очень понадо­бят­ся пара пакетов — GCC и любой тек­сто­вый редак­тор, нап­ример Vim. Они нуж­ны для написа­ния и ком­пиляции экс­пло­ита. Эти пакеты мож­но получить с помощью команд apt install vim gcc на Debian-сис­теме или pacman -S vim gcc для Arch-подоб­ной ОС. Так­же желатель­но соз­дать обыч­ного поль­зовате­ля, от име­ни которо­го мы будем про­верять экс­пло­ит. Для это­го выпол­ним коман­ды useradd -m user и passwd user, что­бы у него была домаш­няя пап­ка.

Вый­дем из chroot с помощью Ctrl + d и на вся­кий слу­чай напишем sync.

Финальные штрихи

На самом деле по‑хороше­му надо отмонти­ровать rootfs.img коман­дой sudo umount /mnt. Лич­но я пос­ле записи в /mnt всег­да допол­нитель­но делаю sync, что­бы записан­ные дан­ные не потеря­лись в кеше. Теперь мы пол­ностью готовы к запус­ку ядра с нашим модулем.

Запуск ядра

Пос­ле сбор­ки само ядро будет лежать в сжа­том виде в <kernel sources>/arch/x86/boot/bzImage. Хоть оно и сжа­то, ядро спо­кой­но запус­тится в QEMU, потому что это саморас­паковы­вающий­ся бинар­ник.

При усло­вии, что мы находим­ся в пап­ке <kernel sources> и там же находит­ся rootfs.img, коман­да для запус­ка ядра будет такой:

В kernel мы ука­зали путь к ядру, append явля­ется коман­дной стро­кой ядра, console=ttyS0,115200 говорит о том, что вывод будет давать­ся в устрой­ство ttyS0 со ско­ростью переда­чи дан­ных 115 200 бит/с. Это прос­то serial-порт, отку­да берет дан­ные QEMU. Аргу­мент root=/dev/sda дела­ет кор­невой фай­ловой сис­темой диск, который мы потом вклю­чили с помощью клю­ча hda, а rw дела­ет эту фай­ловую сис­тему дос­тупной для чте­ния и записи (по умол­чанию толь­ко для чте­ния). Параметр nokaslr нужен, что­бы не ран­домизи­рова­лись адре­са фун­кций ядра в вир­туаль­ной памяти. Этот параметр упростит экс­плу­ата­цию. Наконец, -nographic выпол­няет запуск без отдель­ного окош­ка пря­мо в кон­соли.

Пос­ле запус­ка мы можем залоги­нить­ся и попасть в кон­соль. Одна­ко, если зай­ти в /dev, мы не най­дем нашего устрой­ства. Что­бы оно появи­лось, надо выпол­нить коман­ду insmod /vuln.ko. Сооб­щения о заг­рузке добавят­ся в kmsg, а в /dev появит­ся устрой­ство vuln. Одна­ко есть неболь­шая проб­лема: /dev/vuln име­ет пра­ва 600. Для нашей экс­плу­ата­ции необ­ходимы пра­ва 666 или хотя бы 622, что­бы любой поль­зователь мог писать в этот файл. Мы можем вруч­ную вклю­чать модуль в ядре, как и менять пра­ва устрой­ству, но, сог­ласись, выг­лядит это так себе. Прос­то пред­ста­вим, что это какой‑то важ­ный модуль, который дол­жен запус­кать­ся вмес­те с сис­темой. Поэто­му нам надо авто­мати­зиро­вать этот про­цесс.

Сервис для systemd

Ав­томати­зиро­вать про­цес­сы при заг­рузке мож­но раз­ными спо­соба­ми: мож­но записать скрипт в /etc/profile, мож­но помес­тить его в ~/.bashrc, мож­но даже перепи­сать init таким обра­зом, что­бы сна­чала запус­кался наш скрипт, а потом вся осталь­ная сис­тема. Одна­ко лег­че все­го написать модуль для systemd, прог­раммы, которая явля­ется непос­редс­твен­но init и может авто­мати­зиро­вать раз­ные вещи цивили­зован­ным обра­зом. Даль­нейшие дей­ствия мы будем выпол­нять в сис­теме, запущен­ной в QEMU. Она сох­ранит все изме­нения.

Непосредственно сервис

По фак­ту нам надо сде­лать две вещи: вста­вить модуль в ядро и поменять пра­ва /dev/vuln на 666. Сер­вис запус­кает­ся как скрипт — один раз во вре­мя заг­рузки сис­темы. Поэто­му тип сер­виса будет oneshot. Давай пос­мотрим, что у нас получит­ся.

Этот код дол­жен будет лежать в /usr/lib/systemd/system/vuln.service.

Запуск сервиса

Так как скрипт дол­жен запус­кать­ся во вре­мя заг­рузки сис­темы, надо выпол­нить коман­ду systemctl enable vuln от име­ни супер­поль­зовате­ля.

Пос­ле перезаг­рузки файл vuln в /dev/ получит пра­ва rw-rw-rw-. Прек­расно. Теперь перехо­дим к самому слад­кому. Что­бы вый­ти из QEMU, наж­ми Ctrl + A, C и D.

Дебаггинг ядра

Де­бажить ядро мы будем для того, что­бы пос­мотреть, как оно работа­ет во вре­мя наших вызовов. Это поз­волит нам понять, как экс­плу­ати­ровать уяз­вимость. Опыт­ные читате­ли, ско­рее все­го, зна­ют о One gadget в libc, стан­дар­тной биб­лиоте­ке C в Linux, поз­воля­ющей поч­ти сра­зу запус­тить /bin/sh из уяз­вимой прог­раммы в userspace. В ядре же кноп­ки «сде­лать клас­сно» нет, но есть дру­гая, пос­ложнее.

GDB и vmlinux-gdb.py

Нас­тоятель­но рекомен­дую тебе исполь­зовать GEF для упро­щения работы. Это модуль для GDB, который уме­ет показы­вать сос­тояния регис­тров, сте­ка и кода во вре­мя работы. Его мож­но взять здесь.

Пер­вым делом надо раз­решить заг­рузку сто­рон­них скрип­тов, а имен­но vmlinux-gdb.py, который сей­час находит­ся в кор­невой пап­ке исходни­ков. Как, собс­твен­но, и vmlinux, файл с сим­волами ядра. Он поможет впос­ледс­твии узнать базовый адрес модуля ядра. Это мож­но сде­лать, добавив стро­ку set auto-load safe-path / в ~/.gdbinit. Теперь, что­бы заг­рузить сим­волы и вооб­ще код, выпол­ни коман­ду gdb vmlinux. Пос­ле это­го надо запус­тить само ядро.

Теги: CSS