LINUX.ORG.RU

Уязвимость в IPComp

 ipcomp, ,


0

1

Обнародована уязвимость в реализации стандарта IPComp, способная привести к компрометации серверов на некоторых операционных системах. Стандарт IPComp используется для сжатия дейтаграмм IP с целью повышения скорости передачи данных по соединению, в основном работает совместно с IPSec и другими технологиями VPN.

Как сообщает эксперт по безопасности Тэвис Орманди (Tavis Ormandy), распаковка некоторых дейтаграмм из-за уязвимости может оказаться рекурсивной, что приведет к переполнению стека. Это позволяет атакующему впрыснуть в систему произвольный код и при удачном для него стечении обстоятельств выполнить его. Даже при самых простых сценариях атаки все может привести к аварийному выходу из системы. Орманди утверждает, что атака может быть осуществлена удаленно без необходимости идентификации в системе, а также с поддельным адресом отправителя пакетов.

Атаке подвержены реализации IPSec стека в NetBSD и FreeBSD, а также в производных от них системах (Darwin, Xnu, FTOS, ...).

Патчи для NetBSD и FreeBSD

>>> Подробности

Ответ на: комментарий от anonymous

> Если стек не защищен от выполнения - будет то что надо.

Юнихи разрешают выполнять код только из сегмента кода и все. При переходе на сегмент стека вылетает сегфолт. Сегмент кода, в свою очередь, защищен от записи. В винде эта защита опциональна.

Так что выполнение произвольного кода возможно только путем интерпретации.

Правда, это все работает лишь на тех архитектурах, где адрес возврата лежит в стеке, а не в регистре, как, к примеру в ППЦ или АРМе

В регистре там лежит только последний адрес возврата. Сделано это для повышения скорости. Однако, все адреса возврата в регистр не впихнешь. Все равно используется стек.

segfault ★★★★★
()

Впрыснуть, говоришь... А слово «вставить» или «внедрить» из словаря давно исчезло?

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

Для кода или атакующего? :)

P.S. ушел смотреть на даемон...

jackill ★★★★★
()
Ответ на: комментарий от anonymous

> Опции stack-protector в gcc недостаточно?

Это активная защита, которая а) может не сработать б) жрет ресурсы ЦП.

Я предлагал если не нативную хардварную защиту, то хотя бы размещение следом за стеком защищенного от записи сегмента. Хотя, его тоже можно перепрыгнуть, но в куда более редких случаях. Таким образом, мы все равно получаем аппаратную защиту от переполнения стека - эту роль исполняет контроль сегментации.

segfault ★★★★★
()
Ответ на: комментарий от Led

> И я не представляю как вообще можно сделать аппаратный stack-protector? данные для контроля стэка в астральный стэк складывать?

Добавить в ЦП 2 регистра, содержащих адреса начала и конца сегмента стека. Если значение esp выходит за эти границы - кидаем исключение.

segfault ★★★★★
()
Ответ на: комментарий от segfault

>Добавить в ЦП 2 регистра, содержащих адреса начала и конца сегмента стека. Если значение esp выходит за эти границы - кидаем исключение.

Т.е. вложенность функций - максимум 1 уровень?

Led ★★★☆☆
()
Ответ на: комментарий от Led

> man gcc на предмет -stack-protector

Еще раз, для тех кто в танке: gcc stack-protector программный. А я говорил про аппаратный, работающий по совсем иному принципу.

segfault ★★★★★
()
Ответ на: комментарий от Led

Еще раз, это будет не тот же stack-protector, просто перенесенный на уровень железа. Аппаратно защита от stack overflow реализуется намного проще.

Добавить в ЦП 2 регистра, содержащих адреса начала и конца сегмента стека. Если значение esp выходит за эти границы - кидаем исключение.

segfault ★★★★★
()

Для обработки любых исключений,прерываний и т.д. необходим опять же стек. Кроме того, esp достаточно активно модифицируется. (если мы говорим о x86 like архитектурах). Проще это сделать через ограничение границ сегментного регистра, однако в этом случае потребуется возня с этими границами.

V0ID ★★★
()
Ответ на: комментарий от segfault

Вот здесь вам все правильно описали: http://www.linux.org.ru/jump-message.jsp?msgid=6116310&cid=6119674

И еще на заметку: - Не везде реализована защита стека от исполнения (в контексте ядра в большинстве ОС ее нет, включая чистый линукс без сторонних патчей) - Даже на запрещенный к исполнению стек можно проводить атаки типа return-to-operaion (return-to-libc как частный случай): http://en.wikipedia.org/wiki/Return-to-libc_attack

anonymous
()
Ответ на: комментарий от V0ID

> Для обработки любых исключений,прерываний и т.д. необходим опять же стек.

Да? Как же тогда у меня обработалось исключение «segmentation fault», когда я начал использовать esp в арифметических операциях, забыл про это и вызвал push?

Проще это сделать через ограничение границ сегментного регистра, однако в этом случае потребуется возня с этими границами.

Я уже четвертый пост про это пишу. И возни там уж очень много - аж один раз при запуске программы установить границы в соответствующие регистры!

segfault ★★★★★
()
Ответ на: комментарий от anonymous

> в контексте ядра в большинстве ОС ее нет, включая чистый линукс без сторонних патчей

Давайте не будем рассматривать сферических коней в вакууме. Только что проверил у себя на федоре - защита есть. Еще я могу гарантировать это на убунте, сусе, арче и других широко распространенных дистрах.

Даже на запрещенный к исполнению стек можно проводить атаки типа return-to-operaion

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

segfault ★★★★★
()
Ответ на: комментарий от segfault

Вы проверили запрет на исполнение стека пользовательских процессов. У процессов ядра аналогичной защиты нет.

Просто при защищенном от выполнения стеке злоумышленнику не удастся подсунуть уж совсем любой код.

Если процессу разрешено помечать (через mprotect) память стека на запись и исполнение, то можно комбинировать ROP-атаку для вызова mprotect с последующим возвратом на внедренный код на стеке.

anonymous
()
Ответ на: комментарий от segfault

>>>Да? Как же тогда у меня обработалось исключение «segmentation fault», когда я начал использовать esp в арифметических операциях, забыл про это и вызвал push?

Вы бы хоть читали на какой пост я отвечал. Прочтите в разрезе наличия двух мифических дополнительных регистров ограничивающих стек...

V0ID ★★★
()
Ответ на: комментарий от V0ID

Простите, но сейчас уже не видно, на какой пост вы отвечали.

разрезе наличия двух мифических дополнительных регистров

Да нет этих регистров - я как раз предлагал ввести таковые.

segfault ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.