Содержание статьи
В момент запуска программы в Linux ядро загружает ее в память, а динамический компоновщик подгружает все необходимые библиотеки. Механизм, который мы будем разбирать, работает одинаково для любой динамической библиотеки, но в качестве примера мы возьмем стандартную библиотеку языка C libc. so. 6 : она загружается практически всегда. Именно в ней лежат хорошо знакомые нам функции вроде printf , puts или sleep .
Но тут есть загвоздка. Из‑за ASLR (address space layout randomization) — защитного механизма, который случайным образом размещает библиотеки в памяти, — адрес libc. so. 6 и всех функций внутри нее меняется при каждом запуске. Компилятор не может знать эти адреса заранее. Как тогда программа находит нужную функцию, если ее адрес становится известен только во время выполнения?
Ответ кроется в механизме релокаций: PLT, GOT и ленивой привязке. Давай разберемся, как это работает, на примере простой программы empty_sleep , которая вызывает функцию sleep( 30) и завершается. И не только изучим теорию, но и увидим релокации вживую с помощью отладчика GDB.
Пустая программа для эксперимента
Для примера напишем простую программу empty_sleep . Она ничего не делает, только вызывает sleep( 30) :
Скомпилируем ее в объектный файл:
Затем посмотрим на дизассемблированный код, но сначала — небольшое пояснение.
В зависимости от того, с какими флагами был собран GCC и glibc, вывод команд может выглядеть по‑разному. Я покажу два варианта. Различаются смещения в коде, наличие инструкции endbr64 и структура PLT-заглушек. На логику релокаций это не влияет.
Теперь смотрим дизассемблированный код:
Вот первый пример:
А вот второй пример:
Первый пример — с инструкцией endbr64 , второй — без нее. В первом случае заглушка находится по смещению 0xd , во втором — по смещению 0x9 . В остальном никакой разницы нет.
Что здесь важно? Инструкция call имеет операнд 0x00 00 00 00 — заглушку . Компилятор не знает, где будет находиться sleep , поэтому оставляет пустое место. Четыре нулевых байта — это временный заполнитель, который позже будет заменен настоящим адресом.
Инструкция endbr64 — это часть технологии Intel CET (control-flow enforcement technology) — аппаратной защиты от атак через косвенные переходы, таких как JOP (jump-oriented programming) и подобных. Она не имеет отношения к механизму релокаций. Если твой GCC собран без поддержки CET, этой инструкции не будет, а смещение заглушки окажется на четыре байта меньше. На логику релокаций это тоже не влияет.
Еще раз повторюсь, четыре нулевых байта — это временная метка. Настоящий адрес будет записан позже, а пока компилятор оставил запись в специальной таблице.
Как компилятор сообщает о будущих правках
Компилятор записывает в специальную таблицу следующие сведения: по определенному смещению (сразу после кода операции e8 ) нужно будет вписать адрес функции sleep . Посмотрим:
Вывод:
Конкретное значение смещения зависит от размера кода функции main и может отличаться в твоем случае. Главное — оно указывает ровно на те четыре байта, которые мы видели в дизассемблере.
Разберем запись по полям. Смещение 0xe соответствует примеру с endbr64 . Если в твоем выводе endbr64 нет, смещение будет 0xa .
Откуда взялся индекс 4? Заглянем в таблицу символов:
Символ номер 4 — это sleep . Его значение пока 0x0 , потому что реальный адрес неизвестен. Буквы UND (undefined) означают, что символ определен где‑то вовне, в нашем случае — в библиотеке libc. so. 6 .
Итак, в объектном файле у нас есть:
заглушка 00 00 00 00 в коде;
запись в таблице релокаций: «по этому смещению вписать адрес sleep ».
Дальше в дело вступает статический компоновщик.
Как статический компоновщик создает механизм подстановки
Продолжу с первым примером (с endbr64 ), для второго варианта отличия только в смещениях. Скомпонуем программу:
Теперь посмотрим на main в готовом исполняемом файле:
Адрес main изменился с 0x0 на 0x1149 — статический компоновщик разместил код в финальном файле, добавив заголовки и другие секции. Конкретные адреса у тебя будут другими, это нормально.
Вместо call с нулями теперь call 1050 < sleep@plt> . Статический компоновщик не подставил реальный адрес sleep — он и не может, ведь библиотека загружается динамически и ее адрес станет известен только при запуске. Вместо этого он создал два ключевых механизма:
PLT (procedure linkage table) — таблица заглушек для функций из динамических библиотек;
GOT (global offset table) — таблица, куда динамический компоновщик позже запишет реальные адреса.
Теперь инструкция call в main указывает не на sleep напрямую, а на запись в PLT. Что внутри PLT-заглушки? Разбираемся дальше.
Что внутри PLT-заглушки
Сейчас покажу оба варианта PLT-заглушки, они выглядят по‑разному, но делают одно и то же.
Начнем с терминов. PLT-заглушка — это небольшой фрагмент кода, который main вызывает вместо настоящей библиотечной функции. Резолвер — это код динамического компоновщика, который при первом вызове находит настоящий адрес функции в библиотеке и записывает его в GOT.
Посмотрим на заглушку sleep@plt :
Флаг --no-show-raw-insn скрывает столбец с «сырыми» байтами — с ним вывод чище и легче читается.
Вывод может выглядеть по‑разному. В первом примере (с endbr64 ) заглушка и резолвер окажутся в разных секциях. Во втором (без endbr64 ) — объединены в одном месте.
Вот пример, где заглушка и резолвер объединены (второй пример из раздела «Пустая программа для эксперимента», дальше буду называть его примером с тремя инструкциями):
А вот пример, где заглушка и резолвер разнесены (первый пример из раздела «Пустая программа для эксперимента», дальше буду называть примером с разнесенными инструкциями):
В разнесенном варианте в заглушке нет ни push , ни jmp на резолвер — только jmp в GOT и nop . Но комментарий # 3fd0 < sleep@GLIBC_2. 2. 5> подсказывает, что jmp обращается к GOT по смещению 0x3fd0 . Заглянем туда:
Результат:
Байты 30 10 — это не команда xor , а младшие байты адреса 0x1030 , записанные в обратном порядке (little-endian). Получается, GOT указывает на адрес 0x1030 внутри секции . plt . Давай посмотрим, что там:
Мы увидим такой результат:
Вот они, push и jmp на резолвер, по адресу 0x1030 в секции . plt . Мы нашли их не по имени < sleep@plt> , а по адресу, который лежал в GOT. GOT, в свою очередь, указывает не на заглушку в . plt. sec , а на код резолвера в . plt .
Оба варианта реализуют один и тот же механизм. В первом случае заглушка и резолвер объединены в одном месте, во втором — разнесены по разным секциям: . plt. sec содержит только заглушку (сюда приходит call из main ), а . plt — код резолвера с push и jmp (сюда попадают только при первом вызове через GOT).
Теперь разберем каждую инструкцию подробнее.
Инструкция 1: jmp в GOT
Начнем разбираться на примере с тремя инструкциями:
Инструкция jmp QWORD PTR \[ rip+0x2fca] — это переход по адресу, который хранится в GOT. В примере выше комментарий # 4000 < sleep@GLIBC_2. 2. 5> подсказывает, что адрес находится по смещению 0x4000 . Именно туда динамический компоновщик позже запишет реальный адрес sleep .
Но при первом вызове там лежит не адрес sleep , а адрес, указывающий обратно на код внутри PLT. Заглянем в GOT:
В зависимости от версии objdump название секции может быть . got или . got. plt — это одна и та же область памяти. Вывод тоже может отличаться.
Для примера возьмем вариант с тремя инструкциями:
А вот дизассемблирование для примера с разнесенными инструкциями (как мы уже видели в разделе «Что внутри PLT-заглушки»):
Инструмент objdump интерпретирует содержимое GOT как машинный код. Байты 36 10 00 по смещению 0x4000 (пример с тремя инструкциями) или 30 10 по смещению 0x3fd0 (пример с разнесенными инструкциями) — это не команды ss adc или xor , а младшие байты адреса в обратном порядке (little-endian). В первом случае это 0x1036 , во втором — 0x1030 . Оба адреса указывают на код внутри PLT: либо на следующую инструкцию после jmp (пример с тремя инструкциями), либо на вход в секцию . plt , где лежат push и jmp на резолвер (пример с разнесенными инструкциями).
Продолжение доступно только участникам
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
9990 рублей 5000 р.
950 р.
Опубликованы технические детали и PoC-эксплоит для уязвимости Bad Epoll, обнаруженной в яд…