Очень хорошая статья на Security Lab, объясняющая уязвимость и механизм ее эксплуатации и как ее частично пофиксили. Полезно для понимания как оно вообще бывает даже тем, кто не работает с Java.

Из-за чего весь сыр-бор: про уязвимость Text4Shell

За последнюю неделю в информационном поле инфобеза стали появляться новости о втором пришествии уязвимости Log4Shell, окрестившим себя Text4Shell. Первым об уязвимости сообщил Alvaro Muñoz, который рассказал о возможности удаленного выполнения произвольных скриптов в продуктах, использующих библиотеку Apache Commons Text.

Apache Commons Text — это open source компонент, используемый разработчиками для управления символьными строками. Уязвимость была выявлена в версиях 1.5-1.9 и связана с небезопасной реализацией функций интерполяции переменных. По данным сайта maven repository, библиотека Apache Commons Text используется в 2591 проекте, однако данная оценка не учитывает транзитивные зависимости библиотек.

Сама уязвимость была обнаружена еще в марте 2022 года, но команде Apache Commons потребовалось время на ее исправление и выпуск обновлений библиотеки.

Подробнее: https://www.securitylab.ru/analytics/534471.php

Здравствуйте, BlackEric, Вы писали:

BE>Очень хорошая статья на Security Lab, объясняющая уязвимость и механизм ее эксплуатации и как ее частично пофиксили. Полезно для понимания как оно вообще бывает даже тем, кто не работает с Java.

BE>Подробнее: https://www.securitylab.ru/analytics/534471.php
Как и в прошлом случае, публикуется масса малоинтересных подробностей (вроде фрагментов стека), и обходятся главные вопросы:
1. Для чего вообще используется интерполятор строк?
2. В каких сценариях может потребоваться применение небезопасных string-лукапов в интерполяции?
3. Зачем кому-то в голову приходит скармливать в интерполятор пользовательский ввод?
4. Как правильно пользоваться интерполяцией для сценариев, в которых нужна комбинация пунктов 1, 2 и 3?

Советы вроде "просто экранируйте пользовательский ввод" попахивают бесполезным капитанством.
Смотрите за руками: если кто-то передаёт в в interpolator.replace() пользовательский ввод, то ему это зачем-то нужно. Т.е. приложение спроектировано так, что пользователь может указывать какие-то строковые формулы с подстановками. Если мы "выкосим", т.е. заэкранируем все шаблоны для замены, то пользовательский ввод перестанет интерполироваться.
Нафига козе баян?
Просто заменяем output = interpolator.replace(input) на output = input и получаем тот же результат безо всякой интерполяции.
Если же нас интересует сохранение функциональности приложения, то надо понять, как же делать интерполяцию без риска исполнить произвольный код под привилегиями приложения или открыть иную дыру в неведомые измерения.

Здравствуйте, Sinclair, Вы писали:

BE>>Подробнее: https://www.securitylab.ru/analytics/534471.php
S>Как и в прошлом случае, публикуется масса малоинтересных подробностей (вроде фрагментов стека), и обходятся главные вопросы:
S>1. Для чего вообще используется интерполятор строк?
Допустим в интернет-магазине продавцы могут задавать шаблон письма покупателям. "Здравствуйте, ${username}! Спасибо за покупку ${order}".

S>2. В каких сценариях может потребоваться применение небезопасных string-лукапов в интерполяции?
Ну например, какие-нибудь внутренние конфиги хочешь шаблонизировать в том числе и env значениями или даже кусочками скриптов.

S>3. Зачем кому-то в голову приходит скармливать в интерполятор пользовательский ввод?
Там где пользователи могут задавать какие-нибудь шаблоны чего-нибудь.

S>4. Как правильно пользоваться интерполяцией для сценариев, в которых нужна комбинация пунктов 1, 2 и 3?
Требовать задавать явно что и как может интерполироваться.

S>Если же нас интересует сохранение функциональности приложения, то надо понять, как же делать интерполяцию без риска исполнить произвольный код под привилегиями приложения или открыть иную дыру в неведомые измерения.
Проблема text4shell в том, что либа втихушку добавляла возможности интерполяции чего угодно, в том числе и кусков кода.
Программист ожидал, что будет работать только ${username}, а оказывается можно и запихать ${script:<code>}.

Здравствуйте, ·, Вы писали:

S>>Если же нас интересует сохранение функциональности приложения, то надо понять, как же делать интерполяцию без риска исполнить произвольный код под привилегиями приложения или открыть иную дыру в неведомые измерения.
·>Проблема text4shell в том, что либа втихушку добавляла возможности интерполяции чего угодно, в том числе и кусков кода.
Спасибо за исчерпывающие объяснения.
·>Программист ожидал, что будет работать только ${username}, а оказывается можно и запихать ${script:<code>}.
Я так понял, что в жабе такие диверсии в порядке вещей. Возникает вопрос: а там вменяемые движки интерполяции вообще существуют, или каждый автор считает своим долгом впендюрить туда remote execution?

Здравствуйте, Sinclair, Вы писали:

S>·>Программист ожидал, что будет работать только ${username}, а оказывается можно и запихать ${script:<code>}.
S>Я так понял, что в жабе такие диверсии в порядке вещей.
Фиг знает причём тут жаба. Могу предположить, что жаба — основной язык больших ентерпрайзных монстров, которые пилятся десятилетиями толпами индусов и там такие решения подходят из-за своей простоты побыстрому всё наколбасить и свалить.

S>Возникает вопрос: а там вменяемые движки интерполяции вообще существуют, или каждый автор считает своим долгом впендюрить туда remote execution?
Существуют, конечно. Но это же нужно аккуратно выбирать. А тут apache commons, суют в каждый второй проект, т.к. практически стандартная свалка для всяких популярных фич уровня left-pad. Ну и запихали маленький всемогучий интерполятор...