Компания Oracle представила крупнейшее в истории обновления с исправлением проблем безопасности в Java SE - Java SE 7 Update 13 и Java SE 6 Update 39, в которых устранено 50 уязвимостей, 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), известный польский исследователь безопасности, недавно заявил, что уровни безопасности можно обойти и они эффективны только в теории. На практике же, достаточно быстро удалось найти уязвимость, позволяющую обеспечить выполнение вредоносного ПО даже при активации наивысшего уровня защиты, вообще запрещающего запуск неподписанных апплетов. Используя указанную уязвимость вредоносное ПО как и раньше может запускаться с открытой страницы, абсолютно незаметно для пользователя.
Дополнительно можно упомянуть опубликованную вчера заметку Эндрю Хьюза (Andrew Hughes), одного из разработчиков IcedTea из компании Red Hat, о будущем полностью открытой реализации Java SE, построенной с использованием свободных средств сборки. По мнению Эндрю проект IcedTea потерял смысл и близок к своему завершению. IcedTea по сути является перепаковкой OpenJDK и с незначительными локальными патчами. Раньше во время недоступности некоторых компонентов в составе OpenJDK и распространении кода только в виде tar-архивов, разработка IcedTea имела смысл. Но в настоящее время первоначальные проблемы, для решения которых создавался IcedTea, решены и проект OpenJDK ведёт разработку с использованием полноценных репозиториев и средств отслеживания ошибок.
Если текущие ветки IcedTea ещё будут какое-то время поддерживаться, то будущий выпуск IcedTea на базе Java SE 8 под большим вопросом. В настоящее время компания Red Hat рассматривает возможность закрытия проекта и переходу к непосредственной работе над OpenJDK в upstream, без ведения отдельного форка.
