Компания Oracle представила (https://blogs.oracle.com/security/entry/february_2013_critic...) крупнейшее в истории обновления с исправлением проблем безопасности в Java SE - Java SE 7 Update 13 (http://www.oracle.com/technetwork/java/javase/7u13-relnotes-...) и Java SE 6 Update 39 (http://www.oracle.com/technetwork/java/javase/6u39-relnotes-...), в которых устранено 50 уязвимостей (http://www.oracle.com/technetwork/topics/security/javacpufeb...), 26 из которым присвоен максимальный уровень опасности (CVSS Score 10.0), подразумевающий возможность выхода за пределы изолированного окружения виртуальной машины и инициирования выполнения кода в системе при обработке специально оформленного контента. Изначально, выпуск обновлений был запланирован на 19 февраля, но был выпущен раньше срока, так как одна критическая уязвимость, исправленная в браузерном Java-плагине, имеет характер zero-day проблемы, для которой в сети уже зафиксированы факты эксплуатации.
Все критические проблемы подвержены удалённой эксплуатации без необходимости аутентификации. 23 критические уязвимости проявляются на стороне клиента при обработке в браузерном плагине специально оформленного Java Web Start приложения или Java-апплета, трём проблемам подвержены как клиентские, так и серверные системы (эксплуатация через обращение к серверному API). Отдельно отмечаются 2 уязвимости в серверном компоненте JSSE (Java Secure Socket Extension).
Из общего числа проблем 49 уязвимостей могут быть эксплуатированы удаленно с вектором атаки через сеть без предварительной аутентификации. 39 уязвимостей выявлено в Java Runtime Environment, а 11 в JavaFX. Из уязвимостей в JRE две проблемы найдены в 2D-подсистеме, 4 в CORBA, 4 в AWT, 10 в Deployment Toolkit, 3 в JMX, 5 в библиотеках, 2 в JSSE, 1 в Java Beans, 1 в системе скриптинга, 1 в звуковой подсистеме, 1 в инсталляторе, 1 в JAX-WS, 1 в JAXP, 1 в RMI, 1 в сетевой подсистеме.
В анонсе Oracle отмечается, что опасность эксплуатации проблем безопасности снижена благодаря тому, что начиная с Java SE 7 Update 11 был изменён предлагаемый по умолчанию уровень безопасности. Если ранее при выполнении апплетов использовался средний уровень безопасности, то теперь задействован наивысший уровень, включающий дополнительные проверки и требующий обязательного ручного подтверждения запуска в браузере неподписанных апплетов, приложений Java Web Start или JavaFX. Тем не менее, Адам Говдяк (Adam Gowdiak), известный польский исследователь безопасности, недавно заявил (https://www.opennet.ru/opennews/art.shtml?num=35941), что уровни безопасности можно обойти и они эффективны только в теории. На практике же, достаточно быстро удалось найти уязвимость, позволяющую обеспечить выполнение вредоносного ПО даже при активации наивысшего уровня защиты, вообще запрещающего запуск неподписанных апплетов. Используя указанную уязвимость вредоносное ПО как и раньше может запускаться с открытой страницы, абсолютно незаметно для пользователя.
Дополнительно можно упомянуть опубликованную вчера заметку (http://blog.fuseyism.com/index.php/2013/02/01/the-death-of-i.../) Эндрю Хьюза (Andrew Hughes), одного из разработчиков IcedTea из компании Red Hat, о будущем полностью открытой реализации Java SE. По мнению Эндрю проект IcedTea потерял смысл и близок к своему завершению, так как с выпуском OpenJDK он по сути является его перепаковкой с незначительными локальными патчами. Если текущие ветки IcedTea ещё будут поддерживаться, то будущий выпуск IcedTea на базе Java SE 8 под большим вопросом.
URL: https://blogs.oracle.com/java/entry/critical_patch_update_fo...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35999
