Анатомия эльфов и их репродуктивные возможности
Изначально UNIX (и производные от нее операционные системы) поддерживали множество исполняемых форматов, ожесточенно конкурирующих между собой, но теперь поле боя опустело и среди дымящихся обломков минувших сражений остался один ELF, ставший стандартом де-факто для LINUX и BSD. Кое-где еще встречается древний a.out, но на него можно не обращать внимания.
Аббревиатура ELF расшифровывается как от Execution & Linkable Format (формат исполнения и компоновки). Он состоит в определенном родстве с win32 PE, поэтому у них много общего. В начале ELF-файла расположен служебный заголовок (ELF-header), описывающий основные характеристики файла — тип (исполнения или линковки), архитектура ЦП, виртуальный адрес точки входа, размеры и смещения остальных заголовков…
За ELF-header'ом следует таблица сегментов (program header table), перечисляющая имеющиеся сегменты и их атрибуты. В формате линковки она необязательно. Линкеру сегменты глубоко фиолетов и он работает исключительно на уровне секций. Напротив, системный загрузчик, загружающий исполняемый ELF-файл в память, игнорирует секции, и оперирует целыми сегментами.
Сегменты и секции — что это такое? Сегмент — это непрерывная область адресного пространства со своими атрибутами доступа. В частности, сегмент кода имеет атрибут исполнения, а сегмент данных — атрибуты чтения и записи. Не стоит путать ELF-сегменты с сегментами x86 процессора! В защищенном режиме 386+ никаких "сегментов" в изначальном смысле этого слова уже нет, а есть только селекторы и все сегменты ELF-файла загружается в единый 4 Гбайтовый x86-сегмент! В зависимости от типа сегмента, величина выравнивания в памяти может варьировать от 4h до 1000h байт (размер страницы на x86). В самом ELF-файле хранятся в невыровненном виде, плотно прижатые друг к другу. Так что со свободным пространством для внедрения сплошные напряги.
Ближайший аналог ELF-сегментов — PE-секции, но в PE-файлах, секция — это наименьшая структурная единица, а вот в ELF-файлах сегмент может быть разбит на один или несколько фрагментов — секций. В частности, типичный кодовый сегмент состоит из секций .init (процедуры инициализации), .plt (секция связок), .text (основой код программы) и .finit (процедуры финализации). Секции нужны линкеру для комбинирования, чтобы он мог отобрать секции с похожими атрибутами и оптимальным образом растасовать их по сегментам при сборке файла, то есть "скомбинировать".
Несмотря на то, что системный загрузчик игнорирует таблицу секций, линкер все-таки помещает ее копию в исполняемый файл. Место тратиться совсем немного, зато отладчикам и дизассемблерам так приятнее. По не совсем понятным причинам gdb и многие другие программы отказываются загружать в файл с поврежденной или отсутствующей таблицей секций, чем часто пользуются для защиты программ от постороннего вмешательства.
Рисунок 3 структура ELF-формат с точки зрения линкера (слева) и системного загрузчика операционной системы (справа)
Структуру и назначение полей служебных заголовком здесь разбирать не будем. Этим займется hex-редактор и нам эти подробности не понадобятся. Интересующиеся могут обратиться к файлу /usr/include/elf.h — там все подробно расписано.
Лучше сосредоточимся на загрузке файла в память. По умолчанию ELF-заголовок проецируется по адресу 8048000h, который прописан в его заголовке. Это и есть базовый адрес загрузки. На стадии линковки он может быть свободно изменен на другой, но большинство программистов оставляют его "как есть". Все сегменты проецируются в память в соответствии с виртуальными адресами, прописанными в таблице сегментов, причем, виртуальная проекция образа всегда непрерывна, и между сегментами не должно быть незаполненных "дыр".
Начиная с адреса 40000000h располагаются совместно используемые библиотеки ld-linix.so, libm.so, libc.so и другие, которые связывают операционную систему с прикладной программой. Ближайший аналог из мира Windows – KERENL32.DLL, реализующая win32 API, что расшифровывается как Application Programming Interface, но при желании программа может вызывать функции операционной системы и напрямую. В NT за это отвечает прерывание INT 2Eh, в LINUX – как правило INT 80h (подробнее о различии в реализации системных вызовов можно прочитать в уже упомянутом документе "UNIX Assembly Codes Development for Vulnerabilities Illustration Purposes") или книге Зубкова "Ассемблер– язык неограниченных возможностей".
Для вызова функций типа открытия файла мы можем обратиться либо к библиотеке libc, либо непосредственно к самой операционной системе. Первый вариант — самый громоздкий, самый переносимый, и наименее приметный. Последний — прост в реализации, но при первом же взгляде на дизассемблерный листинг тут же бросается в глаза (правильные программы INT 80h не вызывают!), к тому же он испытывает проблемы совместимости с различными версиями LINUX'а. Вот она — расплата за простоту!
Последний гигабайт адресного пространства (от адреса C0000000h и выше) занимают код и данные операционной системе, к которым мы будем обращаться только посредством прерывания INT 80h или через разделяемые библиотеки.
Стек находится в нижних адресах. Он начинается с базового адреса загрузки и "растет" "вверх" по направлению к нулевым адресам. В большинстве Лихнухов стек исполняем (то есть сюда можно скопировать машинный код и передать на него управления), однако, некоторые параноидальные администраторы устанавливают заплатки, отнимающие у стека атрибут исполняемости, но большой распространенности они не получили и ими можно пренебречь.
Рисунок 4 карта памяти загруженного образа исполняемого файла
