LINUX.ORG.RU

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

 ipcomp, ,


0

1

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

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

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

Патчи для NetBSD и FreeBSD

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

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

А как там дела у оффтопика, он же тоже на БСДшном стеке?

adepto
()
Ответ на: комментарий от ins3y3d

>Пишут, что вроде OS X тож затронута.

Ура!

а GNU/Linux затрагивает?

Так несовместимость лицензий, же! Хоть какой-то профит от того, что не всё в Линуксе натырено ))

adepto
()
Ответ на: комментарий от Atlant

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

ins3y3d ★★★★★
() автор топика

Пока линуксоиды пьют чай, БСДшники распаковывают дейтаграммы. Распаковывают, распаковывают и снова распаковывают.

Pavval ★★★★★
()

> способная привести к компрометации серверов

Компрометация (от франц. compromettre — портить репутацию, компрометировать), оглашение сведений, вызывающих недоверие к кому-либо, порочащих его, подрывающих его авторитет в коллективе, обществе.

ДОКОЛЕ?!

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

компрометации

Это неуклюжая калька со слова compromise

Oxford online dictionary

[with object] bring into disrepute or danger by indiscreet, foolish, or reckless behaviour:

situations in which his troops could be compromised

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

Пока линуксоиды пьют чай, БСДшники распаковывают дейтаграммы. Распаковывают, распаковывают и снова распаковывают.

А в Велорибо уже праздник!

Deleted
()

не хватает метки «решето»

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

он же тоже на БСДшном стеке?

нет

Deleted
()

Мне кажется BSD RIP. Тем более, доля Линукс будет только расти, в том числе, благодаря стараниям Шаттлворта. Более или менее, будет востребована OpenBSD, благодаря своим специфическим качествам.

IT-specialist
()
Ответ на: комментарий от adepto

> А как там дела у оффтопика, он же тоже на БСДшном стеке?

Нет, давно нет.

sv75 ★★★★★
()
Ответ на: комментарий от IT-specialist

что за доля позволю я себе вас спросить? откуда циферки?

ArtemZ
()

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

anonymous_sapiens ★★★★★
()
Ответ на: комментарий от IT-specialist

> будет востребована OpenBSD, благодаря своим специфическим качествам.

сразу чувствуется нуб.

anonymous
()

> впрыснуть

впрыснуть

впрыснуть

anonymous
()

wtf?

>приведет к переполнению стека

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

О_о это как? объясните нубу

kaliostr0
()

При чем тут линукс то? Уязвимость в каких-то полудохлых системах

xorik ★★★★★
()

> позволяет атакующему впрыснуть в систему произвольный код

впрыснуть в систему

Я кончил и закурил.

Может не стоит так буквально переводить?

anonymous
()
Ответ на: wtf? от kaliostr0

Программа использует стек без оглядки на его размер. В некоторых случаях, таких как бесконечная рекурсия этого размера не хватает, и ESP (указатель на вершину стека) залазит на другие сегменты ОЗУ и устраивает «стек» там. Хорошо, если в тот другой сегмент писать запрещено - тогда программа получает сигнал sigsegv и с треском вылетает (за исклчением уж очень извращенных случаев). Но если нет - данные в этом сегменте могут быть перезаписаны непонятно чем. А если там лежат инструкции - скрипты, например? И программа потом их исполнит? Вот это и будет «выполнением произвольного кода».

Вообще, я не понимаю, почему не сделали аппаратный контроль переполнения стека (хотя бы в одну сторону), как контроллируются права на сегменты. Но это уже вопрос к штеуду. Другой вариант - размещать сразу за стеком защищенный сегмент либо просто отсутствие такового. Тогда при переполнении вылетал бы segfault. Это вопрос уже к ядрописальщикам или компилаторописальщикам.

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

тогда я не понимаю как бзде уже столько лет, а от переполнения стека не защищена, если это может привести к таким нехорошим последствиям.

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

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

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

да не может быть. Если всем известно про такую дырищу в ОС - то давно б куча вредоносных кодов разлетелась бы по свету и посносила бы кучу серверов и эту уязвимость быстро залатали бы на уровне ядер.

kaliostr0
()
Ответ на: комментарий от anonymous_sapiens

Ну, поищите книги по ассемблеру. Продвинутые какие-нибудь.

P. S. Коммент про основы - мой, забыл залогиниться, пардон. P. P. S. А какой университет-то хоть? =)

Df_Yz
()
Ответ на: комментарий от kaliostr0

Разработка идеально защищенной системы не реальна, это во-первых.

Во-вторых, все такие гадости не проконтролируешь «в ручную» - человеческий фактор же.

В-третьих, разработка многоуровневой «идеальной» защиты зохавает кучу времени. См. Hurd, хотя пример слегка не корректен.

В-четвёртых, всем похер до тех пор, пока под ними не начнёт взрываться земля.

Df_Yz
()
Ответ на: комментарий от kaliostr0

> эту уязвимость быстро залатали бы на уровне ядер.

Ну вот и латают. На уровне ядер, между прочим. Тут граничное условие введут, там ещё чего-нибудь придумают... =)

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

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

пгупс.

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

Ну-ну, зря не заинтересовал - там есть куча интересных моментов. Ну и просто понимание, мол, «как оно работает» на меньшем уровне абстракции. =)

Df_Yz
()
Ответ на: комментарий от kaliostr0

Это «дырища» не в ОС, и даже не в ядре, она в CPU. И добраться до нее можно только пробив брешь во «внешней защите», которую активно «укрепляют». Собственно, тема эта была разведена вокруг новой дыры в той самой «внешней защите». А переполнение стека всего лишь усугубляет последствия от этой пробоины.

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

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

> Это «дырища» не в ОС, и даже не в ядре, она в CPU. И добраться до нее можно только пробив брешь во «внешней защите», которую активно «укрепляют».

Толково объяснил, но с должным обобщением. А то я вот никак нормально сформулировать не смог - чтоб и кратко, и по-существу, и понятно. =)

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

> Ну вот и латают. На уровне ядер, между прочим. Тут граничное условие введут, там ещё чего-нибудь придумают... =)

Имелась в виду проблема порчи памяти вследствие переполнения стека. Ядро тут ни при чем. Можно залатать на уровне компилятора разными манипуляциями с сегментами. Но лучше всего это сделать в ЦП. Схематехнически это делается просто. Нужно будет еще один-два UNIX сигнала ввести, но на первых порах можно использовать существующее исключение. Тот же SIGSEGV.

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

> Имелась в виду проблема порчи памяти вследствие переполнения стека.

Я знаю, что такое «переполнение стека» и чем оно грозит, благодарю. =)

Ядро тут ни при чем. Можно залатать ..

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

P.S. Про «на уровне ядер» и «латают», вообще-то, был подкол про «эту уязвимость быстро залатали бы на уровне ядер». =)

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

Нет, товарищи. Стек переполняют обычно вот для чего:

1. В стек, ввиде данных загоняют код, который надо исполнить. 2. Стек переполняют, чтобы испортить адрес возврата (из функции) 3. Портят адрес возврата так, чтобы он указывал на код из п.1

Все.

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

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

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

В регистре адрес возврата лежит только в leaf процедурах.

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

> Вообще, я не понимаю, почему не сделали аппаратный контроль переполнения стека

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

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

>> Вообще, я не понимаю, почему не сделали аппаратный контроль переполнения стека

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

Это не аппаратный контроль.

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

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