Java zero-day в браузере: отключить нельзя, оставить опасно

Начало года выдалось беспокойным. В первые три недели января Oracle закрыл несколько критических уязвимостей в Java Runtime Environment, эксплойты к части из них появились до выхода патчей, а Министерство внутренней безопасности США выпустило рекомендацию: отключить Java-плагин в браузере вообще. Не обновить, не ограничить - отключить. Для тех, кто следит за индустриальными предупреждениями, это довольно резкий сигнал.

У нескольких клиентов мы в тот же день пошли смотреть, что именно у них с Java.

Почему это сложнее, чем кажется

В отличие от истории с IE6 три года назад, здесь проблема не в том, что компоненты устарели и их просто не обновляли. Java RE свежей версии - тоже уязвима. Вектор атаки - браузерный плагин, который исполняет апплеты при открытии страницы. Без пользовательского взаимодействия, без инсталляторов - просто открыл страницу, и всё.

Рекомендация DHS логична: если плагин не нужен, его незачем держать включённым. Но на практике корпоративный парк - это не домашние машины, где можно смело убрать всё лишнее.

У одного из клиентов Java-плагин использовался в трёх точках:

• Внутренний портал мониторинга - старая система на базе Java Web Start, консоль управления оборудованием открывалась именно через браузер.
• Банковский клиент - да, один из банков в тот момент использовал Java-апплет для подписи документов. Не редкость для 2013 года.
• Система документооборота - веб-интерфейс с Java-компонентом для работы с ЭЦП.

Всё это - рабочий инструмент, не опциональный. Отключить плагин глобально - значит остановить часть бизнес-процессов.

Что решили делать

Отключать Java в браузере везде и сразу - не вариант. Оставлять как есть - тоже. Нашли промежуточный путь через механизм, который в Windows существует давно, но используется реже чем стоило бы: зоны безопасности Internet Explorer и групповые политики.

Логика простая: Java-апплеты нужны только для конкретных внутренних адресов и одного внешнего банковского сайта. Остальной интернет апплеты запускать не должен.

Настроили через GPO следующее:

• Зона «Надёжные узлы» - добавили только те адреса, где Java реально нужна: адрес внутреннего портала, адрес банковского клиента, адрес системы документооборота.
• Зона «Интернет» и «Ограниченные узлы» - Java-компоненты заблокированы, апплеты не запускаются.
• Запрет изменения настроек зон пользователями - чтобы никто не мог самостоятельно добавить какой-нибудь сайт в надёжные.

Политики разъехались по машинам через стандартный GPO. Из неочевидного: пришлось отдельно проверить, что настройки зон применяются именно через HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings, а не через HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings - иначе пользователь может перебить их через настройки IE.

Контроль версий Java - отдельная история

Пока разбирались с зонами, выяснилось ещё одно: на парке стоят три разные версии Java RE. Часть машин - Java 6, часть - Java 7 Update 10 (та самая уязвимая), пара машин - вообще Java 7 Update 6 двухлетней давности.

Это отдельный симптом. Не злой умысел - просто Java обновляется через собственный механизм, который по умолчанию предлагает обновление пользователю, а не принудительно разъезжается по парку. Часть пользователей кликала «Напомни позже» до бесконечности.

Решение здесь стандартное - управление Java через GPO с фиксацией версии и запретом самостоятельного обновления. Для корпоративного парка это значит: IT контролирует, какая версия стоит, тестирует обновление перед раскаткой и раскатывает через SCCM или тот же GPO. Пользователи не участвуют в этом процессе.

На аудите мы зафиксировали состояние до и после - конкретные версии по машинам, список адресов в доверенных зонах, конфигурацию GPO. Не потому что это кому-то нужно для отчёта, а потому что через полгода без этой записи непонятно, что именно настроено и почему.

Где сейчас

Полностью убрать Java из браузера пока не получается - зависимые системы живут, и вендоры не торопятся. Зонирование снимает основной риск: апплеты исполняются только там, где это реально нужно, и только с известных адресов. Случайно открытая страница с эксплойтом ничего не сделает - плагин в зоне «Интернет» выключен.

Это не идеально. Зависимость от Java в браузере - это технический долг, который нужно отрабатывать с владельцами систем. Но «идеально» и «прямо сейчас» редко совпадают, а рабочее промежуточное решение лучше, чем выбор между двумя крайностями.

Oracle, кстати, выпустил Java 7 Update 11 с исправлением критических уязвимостей через несколько дней после рекомендации DHS. Обновление разъехалось по парку в течение суток. Но уязвимость закрыта, а архитектурная проблема с Java в браузере - нет.