Max Home IndustryУязвимость в оболочке Bash вызывает полную тревогу в Интернете, и, как и все хорошие дыры в безопасности, у нее даже есть запоминающееся название — Shell Shock. Как это работает?
Комментаторы называют это либо самой важной дырой в безопасности со времен Heartbleed, либо более разрушительной, чем Heartbleed. Если вы задерживаете дыхание из-за чего-то действительно тонкого и сложного, сделайте вдох еще раз. Это вопиющая и очень очевидная уязвимость, связанная с инъекцией кода, о которой мы предупреждали пользователей SQL почти до того, как был изобретен SQL.
Bash и большинство оболочек nix ближе к макропроцессорам, чем к статическим языкам, но не позволяйте этому поверить в то, что они не являются мощными.
В этом случае проблема возникает из-за того, что Bash использует переменные среды для передачи экспортируемых функций, чтобы дочерние процессы могли их использовать. Обычно переменные среды хранят простые данные, такие как строка, определяющая текущий рабочий каталог. Некоторые приложения используют переменные среды для передачи данных в сценарии Bash и в другие программы. Например, CGI хранит заголовки HTTP как переменные среды.
То есть переменные среды используются для передачи данных между приложениями, и тот факт, что переменная среды также может содержать код, теперь должен вызывать мигание красного света, потому что, если вы можете передавать данные и / или код, это потенциальная инъекция кода. отверстие.
Так, например, в оболочке Bash вы можете определить функцию:
myFun () {echo «функция»;}
и вы можете вызвать функцию, написав:
myFun
который создаст текст:
функция
Проблема в том, что когда вы определяете функцию, Bash не может определить, когда строка, определяющая функцию, выполнила свою задачу, поэтому он интерпретирует строку до самого конца.
Например, если вы добавите команду в конец функции, она будет выполняться, когда функция определена:
myFun () {echo «функция»;}; echo уязвим
это печатает
уязвимый
и функция также определена.
Это кажется опасной причудой, пока вы не вспомните, что функции могут быть экспортированы как переменные среды для использования дочерними оболочками. В этом случае становится совершенно очевидно, что это способ выполнения команды в дочерней оболочке.
Сначала нам нужно экспортировать набор переменных в строку, которая представляет функцию с дополнительной полезной нагрузкой команды, помеченной в конце.
export myFun = ‘() {echo «функция»;}; эхо уязвимо’
Теперь myFun существует как строка в среде, как вы можете доказать, используя:
эхо myFun
который отображает строку.
Если вы сейчас запустите дочернюю оболочку, которая выполняет функцию, которую она наследует через среду:
bash -c myFun
ты увидишь
уязвимая функция
То, что здесь происходит, неуловимо. «Уязвимый» отображается, когда функция определена, и «функция», когда функция вызывается. Вот почему две строки отображаются в неправильном порядке.
Теперь мы подошли к финальной части головоломки. Когда вы запускаете дочернюю оболочку, все функции среды определяются, даже если они не используются. То есть, если вы попробуете:
bash -c «эхо, привет, мир»
ты увидишь
уязвимый привет мир
То есть полезная нагрузка была выполнена, даже если функция не была вызвана дочерней оболочкой.
Это означает, что вы можете создать новую переменную окружения, которая хранит функцию, то есть функцию окружения с любым именем, которое вы хотите выбрать, и дополнительная полезная нагрузка будет выполнена, даже если дочерняя оболочка не вызывает эту новую функцию.
То есть вы реализовали внедрение кода.
Учитывая, что HTTP CGI, OpenSSH и другие приложения взаимодействуют со сценариями оболочки и т. Д. Через переменные среды, вы можете видеть, что можно ввести код во время стандартной транзакции.
Например, заголовок HTTP вроде:
http-заголовок [Хост] = () {:; }; эхо уязвимое
вызовет полезную нагрузку, в данном случае эхо, при загрузке любой оболочки, унаследовавшей среду.
Насколько серьезна проблема?
Как всегда, трудно сказать, потому что любую дыру в безопасности можно со временем расширить.
В его нынешнем виде полезная нагрузка выполняется на уровне безопасности процесса, который вряд ли будет иметь привилегии root. Это должно ограничить ущерб, если не может быть реализован способ поднять статус полезной нагрузки.
Поступали сообщения об обнаружении эксплойтов в дикой природе, но пока что не так много определенной информации.
Учитывая тот простой факт, что любой веб-сайт Linux, использующий любой сценарий CGI, размещенный на Bash, уязвим для атаки, это проблема, которая требует немедленного внимания.
Был выпущен патч для Bash, но, похоже, некоторые проблемы остались после его применения.
Кажется безумным, что на этом позднем этапе оболочка Bash не является новым программным обеспечением, мы все еще становимся жертвами внедрения кода. Реальной причиной проблемы является использование одного и того же транспортного механизма, то есть переменных среды как для внешних данных, так и для внутреннего кода. Кажется вероятным, что решение можно найти, ограничив форму функций среды, чтобы не было возможности присоединять дополнительную полезную нагрузку, но реальное решение — найти другой механизм для совместного использования кода между экземплярами оболочки.