Max Home IndustryOracle недавно выпустила апрельское обновление Critical Patch, но была обнаружена новая серьезная уязвимость безопасности, которая затрагивает новую серверную JRE, а также все версии Java 7, включая последнее обновление.
Новая проблема безопасности, проблема 61, касается API Reflection, и была обнаружена Адамом Гоудиаком, опытным хакером виртуальных машин Java, основателем и генеральным директором компании Security Explorations, базирующейся в Польше.
Отправив отчет об уязвимости и доказательство концепции, то есть код эксплойта, раскрывающего уязвимость, в Oracle, Гоудиак отправил электронное письмо в список рассылки полного раскрытия информации, в котором описывается новый недостаток, который можно использовать для полного обхода изолированной программной среды безопасности Java на целевая система.
Гаудиак пишет: «Интересно то, что новая проблема присутствует не только в программном обеспечении JRE Plugin / JDK, но также и в недавно анонсированной серверной JRE.
Ссылаясь на Рекомендации Oracle по безопасному кодированию, Гоудиак сообщает, что следующие программные компоненты и API-интерфейсы потенциально подвержены выполнению ненадежного кода Java:
Реализация интерпретатора XSLT Sun
Долгосрочное сохранение компонентов JavaBeans,
RMI и LDAP (RFC 2713)
Многие реализации SQL
Он также выражает озабоченность, что отражено в строке темы электронного письма «Еще один недостаток Reflection API, влияющий на Oracle Java SE», что именно этот API является виновником:
В апреле 2012 года мы сообщили корпорации Oracle о множестве проблем с безопасностью в Java SE 7 и Reflection API, в частности, в нашем первом отчете об уязвимостях. С тех пор прошел год, и, к нашему истинному удивлению, мы все же смогли обнаружить один из самых простых и мощных экземпляров уязвимостей на основе Java Reflection API. Похоже, что Oracle была в первую очередь сосредоточена на отслеживании потенциально опасных вызовов API Reflection в пространстве «разрешенных» классов. Если так, то неудивительно, что 61-й вопрос не был замечен.
Security Explorations последовательно перечисляет недостатки безопасности и ведет журнал состояния поставщиков, в котором указывается, что в большинстве случаев получен ответ от Oracle, хотя некоторые из Проблем касались Apple и IBM. Последняя запись от 24 апреля 2013 г. гласит:
Oracle подтверждает проблему 61. Компания сообщает, что она будет решена в будущем обновлении критического исправления Java SE.
Остались два других, проблемы 54 и 56, в настоящее время нерешенными.
В целом Oracle быстро реагирует на уведомления об уязвимостях. Проблема 54 была одним исключением. Oracle задерживает расследование проблемы, а затем постановляет, что это не ошибка безопасности, заявляя:
«получение дескриптора метода для защищенного метода из суперкласса является допустимым поведением»
привел к обнародованию Security Explorations с подробностями об эксплойте.
Что касается проблемы 56, которая возникает в средстве проверки байт-кода и дает возможность создать допустимый класс, который не вызывает недоступный конструктор, если его суперкласс, в журнале записывает:
Анализ [Oracle] подтверждает утверждение, что проблема 56 демонстрирует поведение, не запрещенное спецификацией JVM.
Означает ли это, что это ошибка или допустимое поведение? К счастью, мы можем положиться на Security Explorations, чтобы решить этот вопрос.