Прежде всего, давайте проясним, что это НЕ новая уязвимость Log4Shell или Spring4Shell.
Хотя это проблема удаленного выполнения кода, ее последствия не столь серьезны и не так легко эксплуатируются, как проблема в Log4j от декабря 2021 года.
Как и в случае с Log4j, суть проблемы заключается в том, что вы можете выполнить поиск, который затем может быть использован не по назначению.
Однако уязвимость Log4shell было очень легко использовать, что не обязательно произойдет в этот раз.
На самом деле эта проблема очень похожа на CVE-2022-33980, о которой мы писали в начале этого года.
Объяснение проблем безопасности Apache commons-text
В библиотеке Apache Commons Text вы можете выполнять интерполяцию переменных. Это позволяет загружать свойства, которые можно динамически оценивать.
Проблема заключается в StringLookup, который выполняет поиски строк. Эти поиски представляют собой выражения, которые могут разрешать DNS записи, загружать значения из URL-адресов и выполнять сценарии с использованием механизма выполнения сценариев JVM.
Эти URL-адреса и сценарии могут исходить из удаленных источников и вызывать удаленное выполнение кода, если используются ненадежные значения. Об этом сообщается в CVE-2022-42889 как об уязвимости высокой степени опасности, которая встречается в версиях с 1.5.x по 1.9.x.
Примеры CVE-2022-42889
Ниже приведены два примера такого рода сценариев, использующих движок Nashorn или JavaScript. Использование interpolatorStringLookup напрямую или через StringSubstitutor (что, вероятно, более распространено) даст тот же результат.
Обратите внимание, что механизм сценариев Nashorn больше не доступен по умолчанию в Java 15 и более поздних версиях. Таким образом, эти сценарии будут выполняться только в том случае, если вы сами предоставите механизм сценариев. Однако, поскольку многие предприятия по-прежнему зависят от более старых версий, таких как Java 8, это может стать серьезной проблемой.
Если вы используете последнюю LTS-версию Java 17, ни скрипты JavaScript, ни скрипты Nashorn не будут выполняться, поскольку по умолчанию движок недоступен.
Исправление для CVE-2022-42889
Позвольте мне еще раз подчеркнуть, что это не Log4Shell снова.
Скорее всего, вы сами не используете StringLookup, но вы не знаете, используют ли его какие-либо из ваших транзитивных библиотек.
Самый простой решения этой проблемы — обновление commons-text до версии 1.10 (или более поздней), которая по умолчанию отключает префиксы URL, DNS и script и делает невозможным выполнение произвольного кода этим путем.
Сканирование с помощью Snyk может помочь определить, присутствует ли эта уязвимость в вашем стеке. Если уязвимость обнаружена, обновите ее до версии 1.10 и запустите snyk monitor в CLI, чтобы продолжить мониторинг в рабочей среде.
Сканируйте свой код бесплатно
Создайте учетную запись Snyk сегодня, чтобы защитить свой код от CVE-2022-42889 и миллионов других уязвимостей.
sshikov
Вот честно говоря, не очень понимаю такие формулировки. Мы и для Log4Shell тоже не использовали уязвимые версии, и тоже они использовались нашими транзитивными зависимостями.
Может быть это эксплуатировать и сложнее, но с точки зрения анализа мало что меняется — мы не знаем достоверно, где и в каких сценариях транзитивные зависимости используют эту функциональность, и можно ли там безболезненно заменить условную версию 1.6 на 1.10.
То есть, чтобы проверить что мы не подвержены, мне нужно не просто собрать свой проект с 1.10, а еще и проверить транзитивные зависимости — мне нужно не только собрать условный Apache Spark 3, что как минимум никогда не делал, мне еще нужно его и протестировать с этой новой зависимостью. Иными словами — я знаю точно, что уязвимая версия используется, но я не знаю вообще, можно ли ее безопасно заменить новой — потому что она не в моем проекте.