LINUX.ORG.RU

Ошибка обработки IPv6-пакетов в OpenBSD серьезнее, чем казалась


0

0

13 марта CoreSecurity Tech опубликовали историю переписки между ними и разработчиками OpenBSD. Согласно ей, ошибка при обработке специально сформированных IPv6-пакетов (об этом уже сообщали на LOR) может привести не только к отказу в обслуживании, но и дает возможность удаленно выполнять код в режиме ядра, т.е привести к полной удаленной компрометации системы. Хакеры из CoreLabs предоставили разработчикам PoC-эксплоит в качестве доказательства.

В связи с чем Theo de Raadt отметил эту уязвимость как "очень важную" (изначально это был bug, а не vulnerability) и рекомендовал всем как можно скорее пропатчить свои системы.

Это - вторая за 10 лет удаленная уязвимость в OpenBSD, установленной по умолчанию.

>>> Официальный advisory от Core Labs

★★

Проверено: ivlad ()

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

>Не ошибаешься :) >http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html >первый же пример !

Мне вот все же интересно: ты только jsp и используешь чтоли? А как насчет ejb? А коннекторы? А jdbc-драйвера которые должны быть подгружены через -classpath ?

Во всех этих местах можно вставить любую херню которая и свалит jvm. Нету сейчас там системы разграничения доступа пригодной для этого. (про JAAS рассказывать не надо ) Сейчас одно приложение = один инстанс jvm

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

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

java.security.* при желании можно натравить на любой класс.

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

Да нет, не только...
Просто в томкате хорошо расписано, прямо в твой притензии.
А там используется стандартная модель security. Точно так же
устанавливаются права и на другие системы:

http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch8.chapter.html
смотри 8.7. Running JBoss with a Java 2 security manager

>Во всех этих местах можно вставить любую херню которая и свалит jvm.

System.exit() - мы убрали ? убрали.
Давай оставшуюся херню будем рассматривать, только ты попорядку.

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

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

Ладно - что ты будешь делать с классом подгруженным через системный класслоадер? который в -classpath указан?

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

мистер тролль, джава здесь не причём.

А как С/C++ прога защищена от того же самого ? никак.

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

Если действия подгружаемых классов будут удовлетворять системе безопасности то все будет выполнятся нормально, как что-то попадет под
запрет - будет возникать исключение.
Можешь почитать здесь более подробно
Security: http://java.sun.com/javase/6/docs/technotes/guides/security/index.html

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

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

ну че с ним спорить, он примерно так спрашивает "а как ваша OC защищена от запуска заражённых бинарикав ? что сама определить что он заражённый не может ? безобразие !"

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

Нет, ну что так опускаться... Ведь всегда можно найти кучу недостатков у других. Например, что делать с модулем ядра прописанном в rc.M? Если человек имеет доступ к изменению таких данных, то речь о секюрити системы уже не идет (она уже взломана). Можно и ядро поменять и виртуальную машину заменить на свою. Бред.
Я спать, всем спасибо!

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

>Я же говорю, спрашивай что конкретно тебя не устраивает в системе >безопасности.

Конкретно: можно ли средствами JAAS дать возможность вызвать эту функцию только из определенных классов? Т.е для всех по умолчанию -запрет а для классов в списке -разрешено?

И еще -я правильно понимаю что использование jaas включается через ключи переменных?

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

>Нет, ну что так опускаться...

ты зря этому товарищу отвечаешь - с утра его бред потрут модераторы а заодно и автоматически все ответы на его посты

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


@RolesAllowed(manager)
@RunAs(myRole)
a(){
b() ;
}

@RolesAllowed(myRole)
b() {}


JAAS - Java Authentication and Authorization Service
В разных системах настраивается по разному, смотря через что происходит система а/а (LDAP, File.properies, DATABASE)

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

>В разных системах настраивается по разному, смотря через что происходит >система а/а (LDAP, File.properies, DATABASE)

Это то понятно. Меня больше волнует что для успешного закрытия с ее помощью jvm от зловредного приложения придется слишком много в эти правила запихивать. Ты вот видел хоть раз полностью отстроенный jaas? чтобы тот же System.exit() из всех частей приложения не работал?

Я вот честно признаюсь - не видел.

(Все больше не буду мешать тебе спать :))

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

> P.S. Я сейчас ухожу, если будет интересно, завтра продолжим...

Я тоже выходил, и без меня тут высказали всё, что я хотел высказать. Из природного занудства :) я просуммирую высказанное:

ни языки типа Cyclone, ни Java не дают абсолютной защиты, это верно. Но никто и не утверждал, что дают. Утверждается одно - они гораздо беопаснее "обычного" Си за счет проверок времени компиляции и исполнения.

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

сравнительная статистика дыр и уязвимостей в Си- и Java-программах отнюдь не в пользу Си

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

Гм. Всегда думал, что java безопаснее за счет того, что синтаксис не позволяет глубоко копаться, отдавая все вещи, которые программер часто может забыть подсмотреть или неверно расчитать, на откуп компилятору/jvm.

Но я ведь и не программер. Я неверно думал?

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

java безопаснее потому что type safe, и потому что реализаци jit'а не так часто отклонения от этого "type safe" находят.

zort
()

Казалось бы, причем тут жава? Ан нет, лор остаётся лором.

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

> Всегда думал, что java безопаснее за счет того, что синтаксис не позволяет глубоко копаться, отдавая все вещи, которые программер часто может забыть подсмотреть или неверно расчитать, на откуп компилятору/jvm.

Не совсем. Java безопаснее потому, что 0) не допускает явного управления памятью 1) компилируется в байт-код высокоуровневой машины 2) байт-код верифицируется так, что многие ошибки Си/Си++ в нем просто невозможны.

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

виерификация и управление памятью есть необходимое условие для type safe.

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

>Точно так же в gcc может оказаться уязвимость и _все_ приложения, скомпиленные им, будут уязвимы. Причем для устранения такой уязвимости придется поставить новый gcc (бинарный, ибо уязвимым компилятором его нельзя собирать) и перекомпилить _весь_ софт. В случае ошибки в jvm/python/perl... нужно пропатчить только jvm/python/perl...

Gcc не занимается проверкой безопасности, он транслирует код из одного синтаксисса в другой.

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

>Не совсем. Java безопаснее потому, что 0) не допускает явного управления памятью 1) компилируется в байт-код высокоуровневой машины 2) байт-код верифицируется так, что многие ошибки Си/Си++ в нем просто невозможны.

Описанное выше не есть признак безопасности. Ошибки в jvm приводят к тому, что можно добраться до данный вне ее пределов - да, нельзя переписать указатель возврата в стеке, но можно поменять /etc/shadow или другие файжные данные.

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

>tailgunner * (*) (15.03.2007 9:43:19)

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

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

Уфф... какие-то "сферические кони в вакууме". Что такое "простейшее ограничение", какого "языка"? В Java нельзя затереть адрес возврата в стеке, нельзя выйти за пределы массива, нельзя использовать освобожденную память. Вы считаете, что это не дает "никакой дополнительной безопасности"? "Да" или "нет"?

> остаток как был уязвимым, так таковым и остался.

Я попробую донести свою мысль (последний раз, обещаю) - никакой язык не является _абсолютно безопасным_ (т.е. программы на любом языке могут содержать уязвимости). Но в некоторых языках остуствуют важные классы уязвимостей - modulo bugs в компиляторе и исполняющей системе, конечно. И даже учитывая эти баги, уязвимости из исключаемых классов появляются на порядки реже, и в основном в теории.

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

>Я попробую донести свою мысль

а я, какой уже раз добавлю, что компиляторы и VM бывают верифицированными e.g VLISP

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

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

>Уфф... какие-то "сферические кони в вакууме". Что такое "простейшее ограничение", какого "языка"? В Java нельзя затереть адрес возврата в стеке, нельзя выйти за пределы массива, нельзя использовать освобожденную память. Вы считаете, что это не дает "никакой дополнительной безопасности"? "Да" или "нет"?

Вам же белым по синему написали - в java нет некоторой функциональности, это обрезок C/C++, поэтому его нельзя рассматривать как более/менее безопасный. Давайте сравним, что безопаснее - велосипед или автомобиль - первый это лишь часть второго, однако последний ездиет намного быстрее и обладает другими преимуществами.

Основой этой концепции безопасности является как jvm, так и ограничения языка. Ограничения не позволяют одного, jvm - другого, в сумме - безопасный язык. Практика, однако, показывает, что из апплета можно перезаписывать любые файлы в системе (имеющие соответствующие права конечно, но тем не менее вне доступа jvm). И где здесь хваленая безопасность?

>> остаток как был уязвимым, так таковым и остался.

>Я попробую донести свою мысль (последний раз, обещаю) - никакой язык не является _абсолютно безопасным_ (т.е. программы на любом языке могут содержать уязвимости). Но в некоторых языках остуствуют важные классы уязвимостей - modulo bugs в компиляторе и исполняющей системе, конечно. И даже учитывая эти баги, уязвимости из исключаемых классов появляются на порядки реже, и в основном в теории.

Странные люди...

Утверждение java: у нас нет указателей, поэтому мы безопаснее. У нас нет ног, поэтому мы не можем их сломать (а значит мы безопаснее). У нас нет окна, поэтому мы из него не выпадем (а значит мы безопаснее).

Рассматривайте то, что есть - есть java с ее jvm, которые позволяют перезаписывать любые файлы в системе. Поэтому java небезопасна. Абсолютно. Ее спасает только ограничение функциональности. Если вы это считаете безопасностью, то тогда (и _только_ тогда) ее (java+jvm) можно считать безопасной средой. Но с таким же успехом вы можете посадить C приложение в selinux контейнер, и злоумышленник не сможет сделать ровным счетом ничего, что не описано в политике безопасности.

>tailgunner * (*) (15.03.2007 13:06:45)

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

когда встретятся, rtc со своими поитерами будет искать новую работу. я предлагаю ему быть готовым к этому.

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

Замнем. Такое впечатление, что вы с кем-то другим разговариваете. Но напоследок:

> Практика, однако, показывает, что из апплета можно перезаписывать любые файлы в системе (имеющие соответствующие права конечно, но тем не менее вне доступа jvm).

Ссылка на это есть? Интересно почитать.

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

>апплета можно перезаписывать любые файлы в системе

так ты эту уязвимость подразумевал ? это к джаве и к VM не имеет отношения, это ошибка в бровзерном плагине. приведи пример удалённой TCP уязвимости java софта, или иди в баню с своими автомобильными метафорами.

>Утверждение java: у нас нет указателей, поэтому мы безопаснее. У нас нет ног, поэтому мы не можем их сломать (а значит мы безопаснее). У нас нет окна, поэтому мы из него не выпадем (а значит мы безопаснее).

это абсолютный бред. java turing-complete и совсем не похожа brainfuck, поэтому ваши намёки на инвалидность идут лесом.

>позволяют перезаписывать любые файлы в системе.

задолбал. это не VM уязвимость. не имеет отношения к серверам никак.

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

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

>> Практика, однако, показывает, что из апплета можно перезаписывать любые файлы в системе (имеющие соответствующие права конечно, но тем не менее вне доступа jvm).

>Ссылка на это есть? Интересно почитать.

Из последнего:

http://secunia.com/advisories/23445/

А вообще там вагон ошибок...

tailgunner * (*) (15.03.2007 14:04:36)

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

>>апплета можно перезаписывать любые файлы в системе

>так ты эту уязвимость подразумевал ? это к джаве и к VM не имеет отношения, это ошибка в бровзерном плагине. приведи пример удалённой TCP уязвимости java софта, или иди в баню с своими автомобильными метафорами.

Вы глупы.

http://secunia.com/advisories/23757/ - переполнение буфера в jre на gif файлах.

http://secunia.com/advisories/23445/ - ошибка в jre, позволяет апплету читать/писать в локальные файлы и исполнять приложения.

>>Утверждение java: у нас нет указателей, поэтому мы безопаснее. У нас нет ног, поэтому мы не можем их сломать (а значит мы безопаснее). У нас нет окна, поэтому мы из него не выпадем (а значит мы безопаснее).

>это абсолютный бред. java turing-complete и совсем не похожа brainfuck, поэтому ваши намёки на инвалидность идут лесом.

Вам что-то мешает читать, что-то в глазах, как у tailgunner, хотя он их уже протер. Это утверждение, что нельзя сравнивать две системы, в оласти, которая полностью отсутствует в одной из них.

>>позволяют перезаписывать любые файлы в системе.

задолбал. это не VM уязвимость. не имеет отношения к серверам никак.

Выше почитали? Ваши знания о предмете очень слабы.

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

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

Нет аргументов - прекращайте спор.

>zort (*) (15.03.2007 14:09:24)

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

> Вам что-то мешает читать, что-то в глазах, как у tailgunner, хотя он их уже протер.

Для протокола - я не изменил своего мнения с начала дискуссии. А ваша фраза о "чем-то в глазах" относилась к моменту, где неправы были именно вы, утверждая, что zort предлагал писать ОС на Java.

По ссылкам - ну да, в JVM (написанной на Си) есть ошибки. Кто-то утверждал, что их нет? Не припомню такого.

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

>А вообще там вагон ошибок.

привел известную апплетную уязвимость, и доволен. в java все уязвимости связаны с аплетами, и с библиотеками типа обработки картинок. к server side java это все отношения не имеет.

ты мне beffer overflow в томкате найди.

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

>апплетные и картиночные уязвимости это децкий сад.

потому что переносимость и безопасность апплетов это дополнительный сервис по сравнению с другими языками, С/С++ вабще не может верифицировать бинарики(по понятным причинам), и никто не жалуется. безопасность С/С++ и java, пожалуйста сравнивайте в тех местах где они эквиваленты по назначению и функционалу, к примеру в области серверного ПО, или сетевых клиентов.

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

>привел известную апплетную уязвимость, и доволен. в java все уязвимости связаны с аплетами, и с библиотеками типа обработки картинок. к server side java это все отношения не имеет.

Вы читали ссылки? Это ошибка в JRE - _все_, что ее использует, автоматически уязвимо.

>ты мне beffer overflow в томкате найди.

У вас серьезные проблемы с пониманием того, о чем идет речь. Попытайтесь думать о системе, а не каком-то одном ее компоненте - в случае ошибок в jre/jvm/j* любой компонент становится источником проблем, следовательно вся система небезопасна, а вы будете утверждать, что "к server side java это все отношения не имеет".

>zort (*) (15.03.2007 14:42:53)

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

>а вы будете утверждать, что "к server side java это все отношения не имеет".

да я буду утверждать. максимум каким местом это имеет отношение к jvm, это проблема с сендбоксингом и верификацией байткода. Эта проблема связана _только_ с враждебным байткодом, а не с сетевой безопасностью. Http серверы байткод от клиентов не принимают. Требовать безопасности здесь (как я уже говорил, но повторю для талантливых) это все равно говорить что линукс дырявый, потому что вирусный бинарик в память загрузить может. У вас фимоз мозга если не видите разницы между Buffer overflow и ошибок с сендбоксингом.

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

>>а вы будете утверждать, что "к server side java это все отношения не имеет".

>да я буду утверждать. максимум каким местом это имеет отношение к jvm, это проблема с сендбоксингом и верификацией байткода. Эта проблема связана _только_ с враждебным байткодом, а не с сетевой безопасностью. Http серверы байткод от клиентов не принимают. Требовать безопасности здесь (как я уже говорил, но повторю для талантливых) это все равно говорить что линукс дырявый, потому что вирусный бинарик в память загрузить может. У вас фимоз мозга если не видите разницы между Buffer overflow и ошибок с сендбоксингом.

У вас каша в голове. Приведенная выше ссылки не требуют специального байт-кода, подойдет любой код, который работает с gif. например обычный апплет. Ах, да, это же не сервер, так что на миллионы клиентских машин, якобы защищенных технологией java нам плевать. Ладно, идем дальше, теперь к серверу.

http://secunia.com/advisories/23186/ - клиент может составить специальный http запрос к Sun Java System Application Server, в результате получим poisoning of the web proxy cache, bypass of certain web application firewall protections, or cross-site scripting attacks.

http://secunia.com/advisories/24531/ - обход проверки сертификата на сервере (при наличии дополнительных условий)

http://secunia.com/advisories/22646/ - DoS против Sun Java System Application Server

http://secunia.com/advisories/21251/ - получение информации о существовании файла в Sun Java System Application Server

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

>zort (*) (15.03.2007 15:19:25)

rtc ★★
()

Не узнаю ЛОР. Никто не сказал BSD - RIP!

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

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

не найдя уязвимостей с выполнением вражеского кода, плохо понимая какое отношение "Sun Java System Application Server" имеет к языку java и к jvm, он потратил своё время, и привел логические баги с безопасностью в стороннем прикладном приложении.

теперь мне придётся процитировать себя любимого. zort (*) (14.03.2007 17:47:42)

>те дырки что в verified stringly typed type safe language, это логические дырки по раскрытию информации, или предоставление повышенного уровня доступа на уровне ошибки в логике программы, но точно не дырки с выполнением кода.

>от первых дырок защищаться нужно уже не на уровне языка.

теперь объясняю для слабоумных. если в приложении функция проверки логина и пароля, всегда возвращает true, незавнисимо от того что находится в БД, то от такой "уязвимости" не защитит никакой язык. ни с/с++ ни java ни haskell. ошибки с обработкой запросов или парсингом – это то же самое.

вы привели типичные ошибки такого рода. такого рода ошибки в прикладном софте не имеют никокого отношения к java/jvm.

от таких ошибок поможет только не изобретённый ещё мега-язык с "семантическими" аннотациями, прикрученным Theorem Proverом и AI.

>У вас каша в голове. Ваши познания в данной области...

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

>дальнейший спор считаю бессмысленным.

конечно, что дальше то продолжать позорится ? слив то засчитан не в твою пользу.

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

Странный вы.

Просили ошибки в java application server - получили. Просили ошибки в jvm - получили. Что вам еще нужно? Прекратите наконец городить ерунду, почитайте свои же сообщения.

Переполнения буфера в java нет, есть другие ошибки. Именно это и нужно сравнивать в C и java.

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

>Просили ошибки в java application server

server side это != java application server. Server side уязвимость это когда ты посылаешь информацию, и потом этой информацией управляешь _процессором_ _напрямую_, а не через код программы в пределах того что программа может. Специально сформированные локальные документы, которые захватывают процессор при их обработке, это тоже самое. безопасный серверсайд - это значит что если ты сам написал сво` сетевое приложение, которое торчит в сеть, и в его коде отсутствует (к примеру) функция по "отсылке дампа винчестера по почте, или просто открытия бэкдора" , то ты точно можешь знать что эти функции на твоем процессоре выполнены не будут. в случае с Сшным прерполнением буфера такой гарантии нет. впрочем если ты допустил ошибку с провекой перрмишенов в каком то месте, то кто-то сможет выполнить функции которые есть в твоей программе, но ему как бы не положены.

разжевал до атомов.

>Именно это и нужно сравнивать в C и java.

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

просьба перечитать пример с логином и паролем.

безопасность языка защищает не от логических ошибок, не от не правильно сформированного выполняемого кода программы, а от "захвата процессора"

когда ты приводил ошибки с аплетами, это было вполне адекватно, но для клиентов. логические ошибки от APPSERV не адекватны, я надеюсь по понятным причинам.

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

s/логические ошибки к безопасности/логические ошибки безопасности /

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

> Да уж, в OpenBSD начали насиловать IPv6 ещё до официального внедрения (а когда оно?)

На www.ripe.net где-то статистические графики по расходу адресов IPv4 лежат. Если мне память не изменяет, к 25-ому году всё кончится. Это с учётом того, что кое-у кого есть незанятые здоровенные диапазоны /8. А свободные диапазоны, которые могут распределять RIR, должны закончиться лет на 10 раньше.

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

/troll mode on Две дырки... Одна спереди другая сзади :)))) /troll mode off Уважаю OpenBSD, юзаю с 2.7.

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