Сторонние библиотеки, которые Atlassian использует в Jira Data Center и Jira Service Management, содержат уязвимости. Часть проблем ведёт к отказу в обслуживании, часть - к обходу аутентификации, раскрытию данных или выполнению кода. Вендор перечислил затронутые выпуски и подготовил исправленные сборки для Data Center. Для серверных сборок исправление в уведомлении не указано: рекомендованные версии помечены как предназначенные только для Data Center.
Состав уведомления и затронутые версии
Уведомление охватывает Jira Data Center и Server, а также Jira Service Management Data Center и Server. В нём указаны ветки 11.3 и 10.3, включая выпуски с долгосрочной поддержкой (LTS), и более старые поддерживаемые ветки. Затронуты выпуски ранее 11.3.12 и 10.3.26; исправленные - 11.3.12 LTS и 10.3.26 LTS. Эти сборки предназначены только для Data Center, поэтому для Server отдельных исправлений документ не приводит.
Проблемы криптографии и сетевого обмена
Основная часть проблем относится к библиотекам для криптографии, сетевого обмена и разбора данных. В Bouncy Castle (набор криптографических функций для Java) отмечена ошибка проверки OCSP (протокол проверки статуса сертификата). Ответ OCSP принимается без привязки к проверяемому сертификату. Поэтому проверка статуса может опираться на ответ, не связанный с сертификатом.
Оценка этой проблемы - 9.3 из 10 по CVSS (общая система оценки уязвимостей). Атака идёт по сети, учётные данные и участие пользователя не нужны. Atlassian отдельно указывает, что риск для своих продуктов оценивает ниже и не считает его критическим.
В Netty (сетевой фреймворк для Java) ошибки затрагивают TLS (протокол шифрования соединений). Одна из них при особой настройке позволяет обойти обязательную взаимную аутентификацию по сертификатам. Обход возможен, если проверка клиентских сертификатов задана только для отдельного имени сервера. Контекст по умолчанию при этом её не требует. Атака идёт по сети, учётные данные и участие пользователя не нужны.
Другая ошибка отключает проверку имени хоста в OpenSSL-клиенте на Java 25 и новее. Она проявляется при простом менеджере доверия, который проверяет сертификаты. Это открывает путь атаке "человек посередине". Ещё одна проблема заставляет сервер многократно пересобирать данные приветствия TLS и нагружает процессор. Для этих атак нужен сетевой доступ, учётные данные и участие пользователя не требуются.
Ошибки в Tomcat и зависимостях на JavaScript
В Apache Tomcat (сервер приложений для Java) отмечены неправильная авторизация из-за обработки ролей и ошибка аутентификации. Ошибка затрагивает вход по клиентскому сертификату и через SPNEGO (согласование методов входа). Отдельно есть состояние гонки при создании локального сокета. Это значит, что проверка условия и его использование разнесены по времени.
В этом случае локальный пользователь может получить доступ к сокету. Ещё одна проблема в правиле перезаписи приводит к отказу в обслуживании. Она срабатывает по сети, учётные данные и участие пользователя не нужны.
В axios (клиент для сетевых запросов на JavaScript) часть проблем приводит к отказу в обслуживании. Одна из них позволяет направить запрос на узел атакующего. Для этого нужна другая ошибка загрязнения прототипа (подмена общих свойств объекта) в том же процессе. Атака идёт по сети, учётные данные не требуются, участие пользователя не нужно.
Проблемы в jackson, jsoup, js-yaml, undici и nanoid исчерпывают память или процессор. Для этого достаточно разбора специально собранных данных. Отдельно http-cache-semantics позволяет получить из общего кеша ответ с учётными данными другого пользователя. Библиотека fast-uri даёт возможность подменить хост при сборке адреса.
Версии исправления и действия администратора
Для Data Center рекомендованы 11.3.12 LTS и 10.3.26 LTS; они указаны для Jira Data Center и Jira Service Management Data Center. Администраторам Server-сборок нужно отслеживать обновление уведомления, потому что отдельных сборок для Server в нём нет. Обходных мер Atlassian не приводит. Сведений об эксплуатации этих уязвимостей в реальных атаках уведомление не содержит. Публикация технических деталей означает, что они доступны, а не то, что проблемы уже используют.
Для Data Center обновление заменяет уязвимые зависимости исправленными, поэтому откладывать его нежелательно. Для Server ясности меньше. Без отдельной сборки остаётся следить за уведомлением и проверять, какие версии вендор добавит дальше.