Java 0day 1.7.0_10

[el-]

https://partners.immunityinc.com/idocs/Java...%20Analysis.pdf

 

[Aels]

это был сплойт из их подписки, да?

 

[steklo]

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

 

[el-]

Aels, нет это просто анализ от них
steklo, уязвима ж вроде только 7 ветка ?

http://schierlm.users.sourceforge.net/CVE-2013-0422.html

 

[neko]

судя по
http://www.cvedetails.com/cve-details.php?...ve_id=2013-0422
то нет, хотя конечно надо тестить

 

[DASM32]

https://partners.immunityinc.com/idocs/Java...%20Analysis.pdf

This vulnerability affects JDK 6 (at least from update 10 and greater) up to the latest JDK 7 update 10.
The comments in the source code state that these classes MBeanInstantiator and JmxMBeanServer
are available since JDK 5, but we did not check versions before JDK 6 update 10.

(одна из двух уязвимостей)

 

[steklo]

steklo, уязвима ж вроде только 7 ветка ?

Ну я только исходя из данных багтрэка сказал. Говорят на шестерке вылетает с исключением, так что без комбинирования не обойтись похоже. Например atomic + jmx. Хотя опять же, могу ошибаться.

 

[Falcon]

Уязвима только 7я ветка.

 

[el-]

https://blogs.oracle.com/security/entry/sec...rt_for_cve_2013

With this Security Alert, and in addition to the fixes for CVE-2013-0422 and CVE-2012-3174, Oracle is switching Java security settings to “high” by default. The high security setting requires users to expressly authorize the execution of applets which are either unsigned or are self-signed.

e.g.: https://twitter.com/kafeine/status/290607837250457600

 

[steklo]

Уже вышел патч, 7u11

 

[Falcon]

Ну вот и пришла пора подписывать апплеты ворованными сертами.

 

[Mr._Zed]

Спойлер: 20

Aels, нет это просто анализ от них

@el-, Gdark Так все-таки Gdark снял эксп с КУЛа или БХЕКа уже?

 

[neko]

el-
уныло то, что теперь даже надежно версию не определить для фильтрации тихо =\ Конец java сплойтам?

Falcon
с ворованными сертами вам баги не нужны так как апплет будет в трустед домене )) до отзыва сертификата конечно. Правда серт нужен от RSA а не майкрософтный для подписи кода.

 

[Aels]

steklo
согласно: http://immunityproducts.blogspot.com.ar/20...one-of-two.html

Over our investigation of the com.sun.jmx.mbeanserver.MBeanInstantiator.findClass and com.sun.jmx.mbeanserver.MBeanInstantiator.loadClass we found that the implementation on JDK6 and JDK7 are the same, which led us at first to the wrong conclusion that both were vulnerable. After further research we found that although the MBeanInstantiator code is the same in both versions, JDK/JRE 6 cannot be exploited.

There is a flag called com.sun.jmx.mbeanserver.JmxMBeanServer.interceptorsEnabled that determines if MbeanServerInterceptors are enabled or not and that value is set in the com.sun.jmx.mbeanserver.JmxMBeanServer constructor.

In JDK7, the public static method com.sun.jmx.mbeanserver.JmxMBeanServer.newMBeanServer(String, MBeanServer, MBeanServerDelegate, boolean) directly calls the constructor
com.sun.jmx.mbeanserver.JmxMBeanServer.JmxMBeanServer(String, MBeanServer, MBeanServerDelegate, MBeanInstantiator, boolean, boolean) where the interceptorsEnabled flag is fully controlled.

JDK6 implementation is different because it calls another constructor that ignores the flag passed to the newMbeanServer method and always sets the flag to false.
This is what is preventing an attacker from getting a MbeanInstantiator instance to then use the findClass method.

так как-то.