Отказ в обслуживании в Java JRE

В очередной раз:

Ну и при чём здесь Linux???

Remotely DoSing JBoss 4.0.2 with serialized java objects
Implications of serialisation vulnerabilies in JDK

Каким боком dos в JBoss имеет отношение к безопасности JDK? ;-)

>В очередной раз: Ну и при чём здесь Linux???

Причем тут java? ;-)
Дырки в java нет. Есть возможность сделать dos в плохосконфигурированном jboss ;-)

Такое приложение примерно выглядит так "System.exit(0)" :)

--седайко стюмчик

> Ну и при чём здесь Linux???

Да ни при чём, просто Саеыча снова провоцируют :)

>Каким боком dos в JBoss имеет отношение к безопасности JDK? ;-)

Таким что JBoss - это pure java application и в принципе не может вызвать EXCEPTION_ACCESS_VIOLATION в нативе (разве что используя некие шаманские методы упоминать о которых не буду) и если простая десериализация роняет VM - значит это проблема в JRE/JVM.

Тем более что уронились в [jvm.dll+0x599b6].

>Причем тут java? ;-)Дырки в java нет.

After my bug report Sun announced fixes in 5.0U6, 1.4.2_11 and 1.3.1_17.

>Есть возможность сделать dos в плохосконфигурированном jboss ;-)

It shall be noted that there is no vulnerability problem with JBoss itself, as this is a flaw in the JDK only. Problems in the java serialisation API are not new, see http://sunsolve.sun.com/search/document.do?assetkey=1-26-57707-1 JBoss is used only for demonstration purposes to show a good product may suffer from vulnerabilities in the layer below. Therefore every architecture that uses the serialisation API is potentially affected.

Если Вам сударь, влом прочитать текст по ссылке, то нечего и п**деть. Не позорьтесь.

В подробности надо было дать вот эту ссылку http://sunsolve.sun.com/searchproxy/document.do?assetkey=1-26-57707-1, чтобы недомерки, не читающие текст в статье, прочитали бы название.

>>Каким боком dos в JBoss имеет отношение к безопасности JDK? ;-)

>Таким что JBoss - это pure java application и в принципе не может вызвать EXCEPTION_ACCESS_VIOLATION в нативе (разве что используя некие шаманские методы упоминать о которых не буду) и если простая десериализация роняет VM - значит это проблема в JRE/JVM.

почитай когда это происходит:

A vulnerability in the Java Runtime Environment (JRE) involving object deserialization could be exploited remotely to cause the Java Virtual Machine to become unresponsive

При десириализации неизвестно чего из потока.
Ещё раз, если ты настроил JBOSS что он десириализует данные из не проверенного источника да ещё с ненастроенным SecurityManager то тут ума много что бы выключить jvm не надо.

Это относится скорее к ошибкам /dev/hands и /proc/admin/DNA
:-)

>>Есть возможность сделать dos в плохосконфигурированном jboss ;-)

It shall be noted that there is no vulnerability problem with JBoss itself, as this is a flaw in the JDK only. Problems in the java serialisation API are not new, see http://sunsolve.sun.com/search/document.do?assetkey=1-26-57707-1 JBoss is used only for demonstration purposes to show a good product may suffer from vulnerabilities in the layer below. Therefore every architecture that uses the serialisation API is potentially affected.

>Если Вам сударь, влом прочитать текст по ссылке, то нечего и п**деть. Не позорьтесь.

:-)
Благородный дон, воспользуйтесь своим бесценным советом и сходите по ссылке сами.

A vulnerability in the Java Runtime Environment (JRE) involving object deserialization could be exploited remotely to cause the Java Virtual Machine to become unresponsive

[повторюсь]
При десириализации неизвестно чего из потока.
Ещё раз, если ты настроил JBOSS что он десириализует данные из не проверенного источника да ещё с ненастроенным SecurityManager то тут ума много что бы выключить jvm не надо.

Это относится скорее к ошибкам /dev/hands и /proc/admin/DNA

>При десириализации неизвестно чего из потока. Ещё раз, если ты настроил JBOSS что он десириализует данные из не проверенного источника да ещё с ненастроенным SecurityManager то тут ума много что бы выключить jvm не надо.

Блажен кто верует. А я грешным делом полагал что Вы человек вменяемый.

> Ещё раз, если ты настроил JBOSS что он десириализует данные из не проверенного источника да ещё с ненастроенным SecurityManager то тут ума много что бы выключить jvm не надо.

Между "выключить с ненастроеным SecurityManager" и EXCEPTION_ACCESS_VIOLATION in jvm.dll благородный дон разницы не видит? Учитывая что в последнем случае хоть расшибись об стену как томми с настройками SecurityManager - а JVM крашнется.

Полагаю что аргументированный разговор с фанатиком принципиально невозможен. Человек просто невьезжает, что речь идет о некоторых обьектах (like several classes from rt.jar ), которые будучи сериализованы СТАНДАРТНЫМИ СРЕДСТВАМИ при СТАНДАРТНОЙ десериализации роняют вм по АВ. Или не умеет читать?

>> Ещё раз, если ты настроил JBOSS что он десириализует данные из не проверенного источника да ещё с ненастроенным SecurityManager то тут ума много что бы выключить jvm не надо.

>Между "выключить с ненастроеным SecurityManager" и EXCEPTION_ACCESS_VIOLATION in jvm.dll благородный дон разницы не видит? Учитывая что в последнем случае хоть расшибись об стену как томми с настройками SecurityManager - а JVM крашнется.

Видит, равно как и знает, что при загрузке десириализованного класса JNI попользовать можно не только в богоугодных целях ;-)

>СТАНДАРТНЫМИ СРЕДСТВАМИ при СТАНДАРТНОЙ десериализации

это, знаете ли, звучит как "речь идет о запуске эксплойтов скомпилированных СТАНДАРТНЫМ gcc в СТАНДАРТНЫЙ elf", если вы хоть что-то понимаете в сериализации

мораль: не надо злоупотреблять CAPSLOCK

> Человек просто невьезжает, что речь идет о некоторых обьектах (like , которые будучи сериализованы СТАНДАРТНЫМИ СРЕДСТВАМИ при СТАНДАРТНОЙ десериализации роняют вм по АВ

Покажи код который сериализует класс из rt.jar и после десерилизации убивает jvm. Не обязательно для этого посылать его по http (пример с jboss и http для демонстрации такой проблемы не нужен).
А пока такого кода нет, воспользуйся своим ником shut up.


>будучи сериализованы СТАНДАРТНЫМИ СРЕДСТВАМИ

Почему же в коде не показано как этот класс был получен? :-)
Подсказка (читай внимательно текст статьи).

>при СТАНДАРТНОЙ десериализации роняют вм по АВ.

По тому что десиарилизуемый класс сфабрикован.

> Полагаю что аргументированный разговор с фанатиком принципиально невозможен.

Полагаю, что когда нет аргументов, начинаются эмоции.

> Видит, равно как и знает, что при загрузке десириализованного класса JNI попользовать можно не только в богоугодных целях ;-)

Благородный дон вообще представляет о чем говорит? Какое JNI? Класс должен быть в обоих VM чтобы имела место быть сериализация. То что метод native сериализатору не холодно не жарко - код не передается.

>По тому что десиарилизуемый класс сфабрикован.

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

I rewill not disclose the SERIALIZED vulnerable version of the affected java.lang.* classes until the release of a fix.

Прошу пардону за фанатика и прочее.

>> Видит, равно как и знает, что при загрузке десириализованного класса JNI попользовать можно не только в богоугодных целях ;-)

>Какое JNI? Класс должен быть в обоих VM чтобы имела место быть сериализация.

отвечу вашим же вопросом.
Благородный дон вообще представляет о чем говорит?

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

А если вы про десиарилизацию.
То динамически подгруженный класс может дернуть (через JNI например) очень много чего если не настроен SecurityManager.

О! небо раскололось и медведь в лесу издох!

На ЛОРе появился человек имеющий мужество извиниться...

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

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

PS Интересно, трудно быть богом, кто-то с ЛОРа читал?;-)

>На ЛОРе появился человек имеющий мужество извиниться...

Я очень удивлен и восхищён (кроме шуток)
мало кто на лоре на такое способен.

А вообще у меня предложение ко всем, ругайтесь меньше.
Если уж человек так вам неприятен, договоритесь о личной встрече
(я например бокс люблю).

>А вообще у меня предложение ко всем, ругайтесь меньше. Если уж человек так вам неприятен, договоритесь о личной встрече (я например бокс люблю).

А после встречи фотоотчет в talks ;)

> Покажи код который сериализует класс из rt.jar и после десерилизации убивает jvm.

Благородный дон читать умеет? Там не тривиальный баг сериализации: там английским по белому написано _специально приготовленный файл_. И если в снаружу торчит ObjectInputStream - JVM будет мертв. И благородному дону должно бы хватить образования заметить, раз он выступает на подобную тему, что в приведенном мессадже сериализован java.awt.color.ICC_ProfileGray с профайлом GRAY.pf - класс из rt.jar, профайл из JRE. Просто его чуть чуть поправили. Кокретно: обнулили байты со смещением 98 и 99. И хана.

К стати баг там в cmm.dll - нативная читалка ICC профайлов.

Вот ронялка: public class TestSer { public static void main( String[] args ) throws Exception{ ByteArrayOutputStream data = new ByteArrayOutputStream(); ObjectOutputStream os = new ObjectOutputStream( data ); DataInputStream profile = new DataInputStream( new FileInputStream( "GRAY.pf" ) ); byte[] bytes = new byte[632]; profile.readFully( bytes ); profile.close(); ICC_Profile instance = ICC_ProfileGray.getInstance( bytes ); os.writeObject( instance ); os.close(); bytes = data.toByteArray(); bytes[0x98] = 0; bytes[0x99] = 0; ObjectInputStream is = new ObjectInputStream( new ByteArrayInputStream( bytes ) ); is.readObject(); is.close(); } }

> По тому что десиарилизуемый класс сфабрикован.

С ума сойти. А как по твоему делают denial of service - стандартным режимом работы что ли? Конечно он был сфабрикован! Как и практически 100% вредоносного кода. От этого что - сервис выживаемее будет? Или JVM меньше рушится?

садитесь, зачет.

ставлю вам отлично за скорость стучания по клавиатуре.

следующее задание - научиться читать ;-)

дык что ещё ожидать от поделки для написания домашних страниц и гаствух;)

>> Покажи код который сериализует класс из rt.jar и после десерилизации убивает jvm.

>Благородный дон читать умеет? Там не тривиальный баг сериализации: там английским по белому написано _специально приготовленный файл_

Умеет, а вы?
Если да, то прочитай тред от начала до конца.
(если коротко)
shut up считал что это происходит при десерилизации обычных классов,
я настаивал(ю) что это не так.

>А как по твоему делают denial of service - стандартным режимом работы что ли? Конечно он был сфабрикован! Как и практически 100% вредоносного кода.

Не нужно давать не известно от куда присылать сериализованные классы.

Это почти все равно что давать запускать у себя произвольный код (без настроек SecurityManager это может быть черевато).

ява зло , а патрик доун

> Не нужно давать не известно от куда присылать сериализованные классы.

Это рекомендация из разряда: если не хотите чтобы вас поломали - выдерните сетевой шнур и забудьте об интернете? Или в интернет сервисы не выставляются?

Понятно что invoker в JBoss наружу торчать не будет - но вот как на счет CORBA? IIOP? Или чисто java вебсервис в котором есть сериализованный объект? Да простой апплет который юзает сериализацию, простая игрушка, простой мидлет, который обменивается с java-сервером сериализованныйми запросами?

>Это почти все равно что давать запускать у себя произвольный код (без настроек SecurityManager это может быть черевато).

SecurityManager тут вообще не в кассу. Если это торчит в снаружу - это будет мертво. Потому и рекомендация от сана - снести нахрен JRE в которой непофиксено.

> shut up считал что это происходит при десерилизации обычных классов, > я настаивал(ю) что это не так.

java.awt.color.IIC_ProfileGrey - обычный класс из rt.jar. GREY.pf - обычный файл из JRE (насколько я понимаю сойдет любой мусор который не сможет распарсить CMM-парсер). Все классы которе я использовал в примере - из rt.jar. При попытке десериализовать байты которые я скормил ObjectInputStream мы получили не IOException, не RuntimeException а отгребли посмертный крашдамп.

Ты все еще настаиваешь что это не так? Ну тогда запусти мой пример. GREY.pf найди в JRE_HOME/lib/cmm.

>> Не нужно давать не известно от куда присылать сериализованные классы.

>Это рекомендация из разряда: если не хотите чтобы вас поломали - выдерните сетевой шнур и забудьте об интернете? Или в интернет сервисы не выставляются?

RMI/IIOP я бы в internet выставлял с большой осторожностью.

Все классы являющеяся аргументами открытых по RMI методов я бы делал final и UID ставил бы не автогенеренное, дабы исключить подмену класса (именно по этой причине String - final).

>Если это торчит в снаружу - это будет мертво. Потому и рекомендация от сана - снести нахрен JRE в которой непофиксено.

Автар считает, что JRE 5 05 (последняя) содержит этот баг, по вашему мнению SUN рекомендуюет её удалить?
Cсылку на рекомендации SUN'a приведите пожалуйтса.

>java.awt.color.IIC_ProfileGrey - обычный класс из rt.jar. GREY.pf - обычный файл из JRE (насколько я понимаю сойдет любой мусор который не сможет распарсить CMM-парсер). Все классы которе я использовал в примере - из rt.jar. При попытке десериализовать байты которые я скормил ObjectInputStream мы получили не IOException, не RuntimeException а отгребли посмертный крашдамп. Ты все еще настаиваешь что это не так? Ну тогда запусти мой пример. GREY.pf найди в JRE_HOME/lib/cmm.

1) Ты изменял содержимое серилизованных классов, речь шла о штатной серилизации без изменения потока.

2) Делать выводы о Remote DOS при таком малом количестве информации я бы не стал.
Подумайте сами, если вы позволяется через RMI передавать себе черти что, то что мешает этому черти что банально съесть у вас всю память и забить весть диск (это по поводу SecurityManager, вам там кажется, что-то не было ясно)
Что бы таких проблем было меньше, повторюсь, все классы аргументы RMI методов должны быть final. SecurityManager должен позволять этим классам делать минимум. Иначе пришлют вам вместо Object (я сам видел код RMI код принимающий Object, что таким людям сказать) вами же написанный код с десирилизацией правленого java.awt.color.IIC_ProfileGrey или просто с банальным вызовом rm –rf / или format c: (по вкусу).

> RMI/IIOP я бы в internet выставлял с большой осторожностью.

Но тем не менее;)

> се классы являющеяся аргументами открытых по RMI методов я бы делал final и UID ставил бы не автогенеренное

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

> (именно по этой причине String - final).

Ох, ну е-мое. String final СОВСЕМ не поэтому. Стринг финал чтобы разные умные пацаны не делали наследников и не лезли своими загребущими лапами в performance/memory sensitive код. Работа со стрингами один из таких участков и иммутабельные они именно поэтому.

> Автар считает, что JRE 5 05 (последняя) содержит этот баг, по вашему мнению SUN рекомендуюет её удалить?

Аффтар гонит. Но только по этому вопросу. jre5.0 обрабатывает некорректные ICC профайлы правильно - ругается что они некорректные. 1.4.2 умирает со смертным дампом.

>1) Ты изменял содержимое серилизованных классов, речь шла о штатной серилизации без изменения потока.

Господин хороший, если бы воткнулись немного в смысл этой баги было бы гораздо легче. С сериализацией все в порядке, просто ICC_Profile итмеет customную десериализацию и на readObject _парсит_ байты ICC профайла который ему подсунули. Все модификации _не портят_ сериализованный поток, более того если бы сериализованный поток был испорчен JVM бы не крашился, был бы обычный IOException при попытке десериализации; портятся только данные ICC_Profile Data и делаются непарсабельными. Сериализация в данном случае используется как транспорт для вызова кода парсера который крашит JVM. Опясность баги в том что данный краш происходит с обычнми классами JRE, а следовательно любая JRE которую можно попросить десериализовать ICC_Profile с некорректными жанными умрет.

А следовательно ваше 1) ничем вам не поможет и ни от чего не смасет - DoS 100%.

> 2) Делать выводы о Remote DOS при таком малом количестве информации я бы не стал.

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

> Подумайте сами, если вы позволяется через RMI передавать себе черти что, то что мешает этому черти что банально съесть у вас всю память и забить весть диск (это по поводу SecurityManager, вам там кажется, что-то не было ясно)

Мешает только то, что a)код managed b)JVM подчиняется настройкам типа -Xmx и поэтому будет OutOfMEmoryException но JVM выживет - угнетсья олько треды которым памяти не хватило, если они конечно не научены выживать что делается тоже легко, и потому вся память не кончится - JVM не выходит за пределы ограничений. c)"черти что" - это данные - код так передать нельзя, он должен существовать на принимающей стороне - сериализация не передает код, если это не собственно байты класса, но в этом случае принимающая сторона это запустить только специально( с помощью ClassLoader ), загрузив этот класс, а следовательно все безопасно. d) ну и соотевественно SecurityManager хотя он только регулирует чего можно чего нельзя. При чем регулирует только если код security-aware (для примера можно посмотреть реализацию проверки RESOLVE/CONNECT у сокета).

>> (именно по этой причине String - final).

>Ох, ну е-мое String final СОВСЕМ не поэтому. Стринг финал чтобы разные умные пацаны не делали наследников и не лезли своими загребущими лапами в performance/memory sensitive код. Работа со стрингами один из таких участков и иммутабельные они именно поэтому.

Очень рекомендую для автора почитать на счет Java "string is final because" в google.

>> Автар считает, что JRE 5 05 (последняя) содержит этот баг, по вашему мнению SUN рекомендуюет её удалить?

>Аффтар гонит. Но только по этому вопросу.

IMHO Аффтар себе льстит.

>jre5.0 обрабатывает некорректные ICC профайлы правильно - ругается что они некорректные. 1.4.2 умирает со смертным дампом.

C меня достаточно, что Аффтар реабилитировал jRE 5_05. Благадорю за интересную беседу, благородный дон.

to: Модераторы, может теперь можно спопкойно новость удалять? Вроде бы все благородные доны согласились, что в текущей JAVA этой дыры нет, SUN этой дыры не признал (за отсутсвием таковой).

Мне на прошлой неделе удавалось ронять JVM приложением c использованием Jini а там сеть по полной программе используется. Удивился, так как давно такого не видел.

BTW если падает именно JVM то это проблема с JVM. Так что JBoss здесь не при делах. А вот если, например, какой-нибудь NullPointerException вылетает то это уже проблема приложения.

>я например бокс люблю

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

зы. и кстати, "лучший bittorent клиент ..., лучший rss ридер - ...", в каждом втором треде о джабе надоели сообществу лора

>>я например бокс люблю

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

На лисп ещё остались программисты или ты мне предлагаешь первым быть? ;-)

>зы. и кстати, "лучший bittorent клиент ..., лучший rss ридер - ...", в каждом втором треде о джабе надоели сообществу лора

За сообщество благродный анонимный дон, пожалуйтса, не отвечайте. Мой ответ, - способ боротся с мифом, что java на desktop нет (когда очередной пионер поднимает этот вопрос, он получает этот ответ).

> Очень рекомендую для автора почитать на счет Java "string is final because" в google.

Очень рекомендую заглянуть в javadoc и обратить внимание на слова "Because String objects are immutable they can be shared.", на метод intern(), на понятие StringPool, и на случаи когда стринги можно сравнивать через ==, как это получается и самое главное _кто_ это делает возможным. И помедитировать что было бы, если бы от стринга можно было наследоваться, а методы оверрайдить.

>SUN этой дыры не признал (за отсутсвием таковой).

Сан эту дыру признал - вверху треда есть линка на заявление sun по этому поводу.

Во справка с сана:

A vulnerability in the Java Runtime Environment (JRE) involving object deserialization could be exploited remotely to cause the Java Virtual Machine to become unresponsive, which is a type of Denial-of-Service (DoS).

> И помедитировать что было бы, если бы от стринга можно было наследоваться, а методы оверрайдить.

Одно другому не мешает (то что String сделали final по мимо вопросов с Securiy решило ещё ряд вопросов), ещё раз String is final because в google или на java.sun.com

A vulnerability in the Java Runtime Environment (JRE) involving object deserialization _could_ be exploited remotely to cause the Java Virtual Machine to become unresponsive, which is a type of Denial-of-Service (DoS).

Именно _could be_.
Да, если вы принимаете неизвестно что и неизвестно от куда.
Попробуй повалить так remote метод c сигнатурой:

void doSomething(String s){
//..по вкусу любую чушшь
}


Как я понял, проблема была в том, что десерилизация у указанного класса была custom и кривая. Вывод, если ты не даешь изменять свои классы аргументы - то remote DOS не будет. А если даешь (и SecurityManager тебе позволяет что угодно), то свалить твою машину можно куда более простым способом.

Иными словами, проблема есть, но она локальная и возникает только когда ты сам себе вставляешь палки в колёса.

> Как я понял, проблема была в том, что десерилизация у указанного класса была custom и кривая.

Неправильно понял. Деceриализация была прямая - ошибка есть в нативном парсере ICC профайла.

>Вывод, если ты не даешь изменять свои классы аргументы - то remote DOS не будет.

Неправильный вывод. Любая точка где есть ObjectInputStream будет крашнута вне зависимости от того что там ожидается и какой код там что читает. Везде где будет происходит попытка десериализации данных - уязвимое место. Если попытка десериализации будет происходить в сервисе выставленном в сеть - remote DoS.