Прежде всего, давайте проясним, что это НЕ новая уязвимость 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
(что, вероятно, более распространено) даст тот же результат.
![](https://habrastorage.org/getpro/habr/upload_files/074/8e9/7e5/0748e97e5f95f6dfad0914959bc583ca.jpeg)
Обратите внимание, что механизм сценариев 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, что как минимум никогда не делал, мне еще нужно его и протестировать с этой новой зависимостью. Иными словами — я знаю точно, что уязвимая версия используется, но я не знаю вообще, можно ли ее безопасно заменить новой — потому что она не в моем проекте.