Тысячи их https://www.imagemagick.org/discourse-server/
Такое сильное некромантство, что свежая версия на этой неделе вышла https://www.imagemagick.org/download/
In May 2016, it was reported that ImageMagick had a vulnerability through which an attacker can execute arbitrary code on servers that use the application to edit user-uploaded images.
Один крупный баг за 25+ лет использования - это в мире СПО практически рекорд стабильности и надежности.
Тем более, что альтернатив-то не особо. Почти все библиотеки обработки изображений на PHP, Perl или Python опираются на ImageMagick
Это не просто крупный баг, это возможность выполнения произвольного постороннего кода на сервере. Из-за, библиотеки для работы с изображениями!
Не знаю как там с PHP и Perl (в PHP коде я действительно часто видел использование ImageMagick, так как там ничего другого нету), но я не припомню ни одну библиотеку для Python, чтобы она опиралась на ImageMagick, кроме как PythonMagick, который просто python обертка для API ImageMagick. Все часто используемые библиотеки, такие как PIL, Pillow, scikit-image никак не зависят от ImageMagick.
Возможность выполнения произвольного кода на сервере - это, к сожалению, часто встречающаяся проблема, причем сразу на всех уровнях. Shellshock работал просто на Apache, да что там, он даже на DHCP-клиентах работал, что позволяло получать доступ к VPS серверам находящимся в той же сети.
Но нет худа без добра. Все это безобразие очень ускорило развитие защитных мер на уровне самой OS - grsec, apparmor, selinux...
Все так, часто встречающаяся проблема. Но воспользоваться уязвимостью не всегда просто. В случае с упомянутым Shellshock, до bash'а еще добраться как-то надо. На apache, если верить вики, работал эксплоит связанный с CGI, что при определенных обстоятельствах давало возможность выполнить произвольный код. DHCP эксплоит на клиентах работал, ну ок, им можно воспользоваться если есть доступ к роутеру, а с клиента ничего не сделаешь. Т.е. такая уязвимость не дает лего и просто доступ к удаленному серверу.
Но в случае с ImageMagick достаточно было загрузить специальную картинку.
Хотя я не безопасник, могу ошибаться.
Ну да, на Апаче работал эксплойт в mod_cgi, который включен почти везде. DHCP-атака более сложная, но более коварная - она позволяет атаковать сервера в той же сети, т.е. нужно посмотреть у кого хостится потенциальная жертва и заказать там себе хостинг. А для атаки через ImageMagick нужно чтобы на сервере была, собственно, обработка изображений.
Потому следует предполагать, что любые сервисы потенциально уязвимы. И должны быть ограничены своей песочницей так жестко, как только вообще возможно. В случае apache, к примеру, у пользователя, под которым он работает, не должно быть прав на чтение/выполнение чего бы то ни было вне папки со скриптами сайта. Тогда доступ к bash из под Апача не дал бы ничего, кроме кучи записей в логи, вне зависимости от того, воспользовались бы злоумышленники уязвимостью в ImageMagick или mod_cgi.
>> Ну да, на Апаче работал эксплойт в mod_cgi, который включен почти везде.
И где он почти везде включен? По дефолту, cgi модуль выключен. И в apache2.conf нужно еще разрешить выполнение cgi скриптов. A CGI сейчас почти нигде не используется.
Ну самое главное, ну ок, mod_cgi включен, для того, чтобы воспользоваться уязвимостью этого мало, нужно чтобы cgi скрипт был, причем handler должен быть bash. Иначе от этой уязвимости не холодно не жарко. Я ведь ничего не путаю?
>> нужно посмотреть у кого хостится потенциальная жертва и заказать там себе хостинг
И нужно, что бы заказанный хостинг был в одной локальной сети с жертвой, и нужно каким-то образом притворится DHCP сервером (чего в большинстве случаев сделать не удастся из-за ограничений хостинга). Чтобы притворится DHCP сервером, нужно ответить на широковещательное UDP сообщение клиента о service discovery раньше настоящего DHCP сервера. И когда клиент решит запросить IP адрес у DHCP сервера тоже совсем не ясно.
Слишком много "и", "но" и "если". Сделать все это можно только в специфических условиях, и то очень сложно. В случае с ImageMigick достаточно было чтобы был сервис, который обрабатывает изображения...
Почти все, что не PHP - суть CGI: перл, питон, руби, джава и т.д., с поправкой на фреймворки, которые работают с mod_perl или mod_fcgi, но последний подвержен той же самой уязвимости.
Хендлер не важен, шелшок срабатывает при установке переменных окружения, обычно используется кука или реферер.
> Слишком много "и", "но" и "если"
Да не, никто же не рассчитывает на мгновенный эффект. Включат свой допиленный DHCP-сервер, начнут рассылать ответы и конфликты (чтобы повторный запрос прошел), через некоторое время все получится.
Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень, особенно с учетом большого количества говнокодеров на PHP, достаточно вспомнить PHPbb, кажется версии 1.7, который пол-рунета раком поставил из-за уязвимости.
То, что все суть CGI то понятно. Я сам, было дело, имплементил wsgi для python по PEP 333 для специфической хрени, которая отвечала на http-подобные реквесты и запускала встроенный python.
На вики речь шла именно о mod_cgi, и если хэндлер bash. Я не уверен, что оно распространяется на все остальное.
>> Хендлер не важен, шелшок срабатывает при установке переменных окружения
Как я понимаю, при выполнении вредоносного реквеста, apache (или другой http сервер) устанавливает эту вредоносную переменную окружения, затем вызывает хэндлер. Если хэндлер bash, то эти переменные окружения попадут в bash и тот выполнит код из переменной. Если они в bash не попадут, то ничего и не произойдет.
Так или нет? Баг существовал сугубо в bash, а переменные окружения существуют на уровне OS, если переменные ставятся, но bash не вызывается, то ничего не происходит. Если хэндлер java или Python, то никакого bash там не будет, если его не вызовут из того же java и python кода.
Есть опыт применения подобных эксплоитов? У меня нету.
>> Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень,
Я согласен на 100%. Я лишь хотел сказать, что в случае с ImageMigick эксплоитится в разы проще.
Если я правильно помню, то mod_cgi - это хендлер, вызывающий bash с указанием запуска конкретного файла, будет ли это бинарник, байткод для явы или же скрипт, которому требуется интерпретатор питона - это bash сам разберется. Конечно же за исключением фреймворков, которые висят в памяти постоянно и общаются с апачем через fcgi.
> Есть опыт применения
Только на своей машине. Проверил. Ужаснулся. Обновил bash.
>> Если я правильно помню, то mod_cgi - это хендлер, вызывающий bash с указанием запуска конкретного файла, будет ли это бинарник, байткод для явы или же скрипт, которому требуется интерпретатор питона - это bash сам разберется
Да, но питон так не запускают, для питона существует wsgi интерфейс, и для апача отдельный модуль mod_wsgi. wsgi модуль выполняет внутри встроенный интерпретатор питона и вызывает напрямую функции питона из С. Т.е. никакой bash не вызывается. С PHP та же история, есть mod_php, который запускает напрямую интерпретатор PHP. С perl то же самое - mod_perl. Никто не будет запускать bash, просто потому, что это не безопасно и медленно.
Я это к тому, я сомневаюсь, что уязвимости были подвержено что-то помимо mod_cgi, так как только он запускает bash. Чистый mod_cgi я как-то не видел, чтобы где-то использовался, он даже по дефолту выключен. Может так java'у запускают, я не знаю, с java в web не работал.
> Только на своей машине. Проверил. Ужаснулся. Обновил bash.
Просто из bash-a через env, или поднимал apache и слал вредоносный реквест?
Для PHP это в основном справедливо, хотя mod_cgi может работать и с PHP.
А вот mod_perl был популярен где-то в нулевых, но потом его вытеснил mod_fcgi за счет универсальности. Собственно, кроме фреймворка Catalyst я вот так с ходу не могу вспомнить ничего, что использовало бы mod_perl. Впрочем, и mod_fcgi используется нечасто - это решение для высоких нагрузок, подразумевающее работу скрипта в цикле запрос-ответ, а не запрос-запуск-ответ-завершение.
Насчет Питона не скажу, я с ним работал мало и вообще не понимаю, зачем он существует в вебе.
> Чистый mod_cgi я как-то не видел, чтобы где-то использовался
У меня ровно противоположный опыт - mod_cgi используется везде и есть везде, где есть Апач. Это базовый и универсальный модуль для работы с любым динамическим контентом. Вот типичная цитата из описания: mod_cgi is responsible for handling all requests for programs which should be executed on the server. This includes shell/Perl/Python/PHP scripts but it is not limited only to these. It is also responsible for sending the proper error pages to the clients when a problem is encountered.
Насчет проверки: оба варианта. Когда шелшок только опубликовали, я просто его проверил. А когда попалась на глаза статья про использование его в Apache, то поднял на виртуалке двухлетний бэкап системы и проверил на Апаче. Использование через ping и dhcp не проверял, но второе для меня очевидно - dhcp запускает конфигурационные утилиты через bash - тот же ip или ifconfig в зависимости от настроек.
Такое сильное некромантство, что свежая версия на этой неделе вышла https://www.imagemagick.org/download/
А разве этот имейджмэджик как-то связан с майкрософтом (ну или предком от майкрософта)?
Из вики:
In May 2016, it was reported that ImageMagick had a vulnerability through which an attacker can execute arbitrary code on servers that use the application to edit user-uploaded images.
https://arstechnica.com/security/2016/05/exploits-gone-wild-hackers-target-critical-image-processing-bug/
Тем более, что альтернатив-то не особо. Почти все библиотеки обработки изображений на PHP, Perl или Python опираются на ImageMagick
Не знаю как там с PHP и Perl (в PHP коде я действительно часто видел использование ImageMagick, так как там ничего другого нету), но я не припомню ни одну библиотеку для Python, чтобы она опиралась на ImageMagick, кроме как PythonMagick, который просто python обертка для API ImageMagick. Все часто используемые библиотеки, такие как PIL, Pillow, scikit-image никак не зависят от ImageMagick.
Но нет худа без добра. Все это безобразие очень ускорило развитие защитных мер на уровне самой OS - grsec, apparmor, selinux...
Но в случае с ImageMagick достаточно было загрузить специальную картинку.
Хотя я не безопасник, могу ошибаться.
Потому следует предполагать, что любые сервисы потенциально уязвимы. И должны быть ограничены своей песочницей так жестко, как только вообще возможно. В случае apache, к примеру, у пользователя, под которым он работает, не должно быть прав на чтение/выполнение чего бы то ни было вне папки со скриптами сайта. Тогда доступ к bash из под Апача не дал бы ничего, кроме кучи записей в логи, вне зависимости от того, воспользовались бы злоумышленники уязвимостью в ImageMagick или mod_cgi.
И где он почти везде включен? По дефолту, cgi модуль выключен. И в apache2.conf нужно еще разрешить выполнение cgi скриптов. A CGI сейчас почти нигде не используется.
Ну самое главное, ну ок, mod_cgi включен, для того, чтобы воспользоваться уязвимостью этого мало, нужно чтобы cgi скрипт был, причем handler должен быть bash. Иначе от этой уязвимости не холодно не жарко. Я ведь ничего не путаю?
>> нужно посмотреть у кого хостится потенциальная жертва и заказать там себе хостинг
И нужно, что бы заказанный хостинг был в одной локальной сети с жертвой, и нужно каким-то образом притворится DHCP сервером (чего в большинстве случаев сделать не удастся из-за ограничений хостинга). Чтобы притворится DHCP сервером, нужно ответить на широковещательное UDP сообщение клиента о service discovery раньше настоящего DHCP сервера. И когда клиент решит запросить IP адрес у DHCP сервера тоже совсем не ясно.
Слишком много "и", "но" и "если". Сделать все это можно только в специфических условиях, и то очень сложно. В случае с ImageMigick достаточно было чтобы был сервис, который обрабатывает изображения...
Хендлер не важен, шелшок срабатывает при установке переменных окружения, обычно используется кука или реферер.
> Слишком много "и", "но" и "если"
Да не, никто же не рассчитывает на мгновенный эффект. Включат свой допиленный DHCP-сервер, начнут рассылать ответы и конфликты (чтобы повторный запрос прошел), через некоторое время все получится.
Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень, особенно с учетом большого количества говнокодеров на PHP, достаточно вспомнить PHPbb, кажется версии 1.7, который пол-рунета раком поставил из-за уязвимости.
На вики речь шла именно о mod_cgi, и если хэндлер bash. Я не уверен, что оно распространяется на все остальное.
>> Хендлер не важен, шелшок срабатывает при установке переменных окружения
Как я понимаю, при выполнении вредоносного реквеста, apache (или другой http сервер) устанавливает эту вредоносную переменную окружения, затем вызывает хэндлер. Если хэндлер bash, то эти переменные окружения попадут в bash и тот выполнит код из переменной. Если они в bash не попадут, то ничего и не произойдет.
Так или нет? Баг существовал сугубо в bash, а переменные окружения существуют на уровне OS, если переменные ставятся, но bash не вызывается, то ничего не происходит. Если хэндлер java или Python, то никакого bash там не будет, если его не вызовут из того же java и python кода.
Есть опыт применения подобных эксплоитов? У меня нету.
>> Я это, в общем, к тому, что удаленное выполнение кода - достаточно распространенная хрень,
Я согласен на 100%. Я лишь хотел сказать, что в случае с ImageMigick эксплоитится в разы проще.
> Есть опыт применения
Только на своей машине. Проверил. Ужаснулся. Обновил bash.
Да, но питон так не запускают, для питона существует wsgi интерфейс, и для апача отдельный модуль mod_wsgi. wsgi модуль выполняет внутри встроенный интерпретатор питона и вызывает напрямую функции питона из С. Т.е. никакой bash не вызывается. С PHP та же история, есть mod_php, который запускает напрямую интерпретатор PHP. С perl то же самое - mod_perl. Никто не будет запускать bash, просто потому, что это не безопасно и медленно.
Я это к тому, я сомневаюсь, что уязвимости были подвержено что-то помимо mod_cgi, так как только он запускает bash. Чистый mod_cgi я как-то не видел, чтобы где-то использовался, он даже по дефолту выключен. Может так java'у запускают, я не знаю, с java в web не работал.
> Только на своей машине. Проверил. Ужаснулся. Обновил bash.
Просто из bash-a через env, или поднимал apache и слал вредоносный реквест?
А вот mod_perl был популярен где-то в нулевых, но потом его вытеснил mod_fcgi за счет универсальности. Собственно, кроме фреймворка Catalyst я вот так с ходу не могу вспомнить ничего, что использовало бы mod_perl. Впрочем, и mod_fcgi используется нечасто - это решение для высоких нагрузок, подразумевающее работу скрипта в цикле запрос-ответ, а не запрос-запуск-ответ-завершение.
Насчет Питона не скажу, я с ним работал мало и вообще не понимаю, зачем он существует в вебе.
> Чистый mod_cgi я как-то не видел, чтобы где-то использовался
У меня ровно противоположный опыт - mod_cgi используется везде и есть везде, где есть Апач. Это базовый и универсальный модуль для работы с любым динамическим контентом. Вот типичная цитата из описания: mod_cgi is responsible for handling all requests for programs which should be executed on the server. This includes shell/Perl/Python/PHP scripts but it is not limited only to these. It is also responsible for sending the proper error pages to the clients when a problem is encountered.
Насчет проверки: оба варианта. Когда шелшок только опубликовали, я просто его проверил. А когда попалась на глаза статья про использование его в Apache, то поднял на виртуалке двухлетний бэкап системы и проверил на Апаче. Использование через ping и dhcp не проверял, но второе для меня очевидно - dhcp запускает конфигурационные утилиты через bash - тот же ip или ifconfig в зависимости от настроек.
прон в бмп формате.
моник от MAG с колесиком, котэ спящее на нем...
даже, трава была зеленее...