Еще один недостаток безопасности Java 7


Oracle недавно выпустила апрельское обновление 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, чтобы решить этот вопрос.


Добавить комментарий