В конце апреля 2007 г. в Apple QuickTime Player'e всех версий, вплоть до 7.1.5, обнаружилась дырка, позволяющая Java-приложениям исполнять произвольный код на удаленной системе. Достаточно зайти на Web-страничку злоумышленника... Учитывая огромную распространенность Apple QuickTime Player'a и Microsoft Internet Explorer'a, произошло своеобразное перекрестное «опыление», в результате чего пострадали сразу обе системы: вся линейка Windows NT (включая Vista) и Mac OS.
Но сама Java-машина тут не при чем. Ошибка сидит во внешнем (по отношению к ней компоненте), и потому уязвимость распространяется не только на IE, но и FireFox.
Exploit, пробивающий практически любую Java-машину, при наличии установленного Apple QuickTime Player'a с версией 7.1.5 или более ранней // инициализирует Quick-Time QTSession.openO;
// получает обработчик, указывающий на что угодно
byte b[] = new byte[l Л здесь может быть любое число V];
QTHandle h = new QTHandle(b);
// превращает обработчик в указатель на объект
// огромное отрицательное значение обходит проверку диапазона QTPointerRef p = h.toQTPointer(-2000000000 /* смещение */, 10 /* размер */);
II перезаписывает объект p.copyFromArray(0 Л смещение V, b Л источник V, О, 1 /* длина V),'
Этот пример наглядно доказывает, что говорить о безопасности Java в отрыве от надежности всех остальных компонентов операционной системы и ее окружения— наивно. Java должна либо быть «вещью в себе» и не допускать никаких внешних вызовов (так вели себя некоторые диалекты Бейсика на 8-разрядных компьютерах, из лек-сикона которых были исключены операторы CALL, PEEK и РОКЕ), либо открыто признать, что на шатком фундаменте крепости не построишь и доверять Java-приложениям даже с учетом всей многоуровневой системы безопасности на 100% нельзя. Впрочем, отказ от внешних вызовов ничего не решает, поскольку системные библиотеки, поставляемые вместе с Java-машиной, ничем не лучше прочих компонентов и могут содержать различные дефекты проектирования. Хотите пример? В начале 2007 г. в Sun JRE 5.0 Update 9 (включая и более ранние версии) была обнаружена ошибка, связанная с обработчиком заголовков GIF-файлов и содержащая уязвимость, которая приводила к возможности передачи управления на shell-код, расположенный непосредственно в самом GIF-файле. Технические подробности можно найти нa www.securityfocus. com/archive/1/457159. а код exploit'a есть нa www.securitvfocus.сom/archive/1/457638. Для нас же важен сам факт небезупречной реализации Java-машины. Получается, что в то время как теоретики от программирования старательно выводят запутанные диаграммы, иллюстрирующие «продвинутую» модель безопасности Java с многоуровневой системой защиты, хакеры дизассемблируют библиотечные файлы на предмет поиска реальных уязвимостей.
Военная мудрость гласит—чем больше расставлено линий обороны, тем выше вероятность прорыва противника, ибо надежная линия обороны справляется со своей задачей и одна. Можно сколько угодно укреплять замок крепостными валами и рвами, но это не защитит его от пикирующего бомбардировщика. С «воздуха» (т. е. изнутри системных библиотек) Java не защищена. Ошибки там были и будут. Достаточно взглянуть на размер дистрибутива (полсотни мегабайтов в упакованном виде) и попытаться представить себе, сколько человеко-часов требуется для его тестирования и реально ли собрать такое количество высококвалифицированных специалистов под одной крышей. А ведь помимо стандартных библиотек общего назначения есть еще и нестандартные (например, JGL, используемая для обработки трехмерных объектов и широко применяемая в задачах моделирования).
Заключение
Интерес хакеров к Java-технологиям неуклонно растет. Отрабатываются исследовательские методики, создаются инструменты для анализа байт-кода и различные испытательные стенды для верификатора и т. п. Словом, ведутся интенсивные наступательные работы и в обозримом будущем, по всей видимости, следует ожидать взрывного роста атак на Java-машины, защищенность которых на практике оказывается значительно ниже, чем в теории.
Как этому противостоять? Универсальных рецептов нет. Однако эксплуатация Java-приложений ничем не отличается от остальных, написанных на Си/Си++, DELPHI, PHP. Залог здоровья — в своевременной установке заплаток и правильном выборе партнеров, реализация JVM от Sun по многим параметрам лучше, чем у IBM, но в силу своей огромной распространенности у Sun-машины гораздо больше шансов быть атакованной.
Список литературы
IT спец № 07 ИЮЛЬ 2007