Внимание, серьезнейшая уязвимость во всех версиях Revolution
Ну что ребята, дождались. Евгений Борисов откапал 2 просто чудовищных дыры безопасности в MODX Revolution.
Подвержены все сайты на Revo.
Первая: функция eval() в фильтре math. Позволяет вызывать произвольный php код. Багрепорт. Модыксеры сказали, что это не ошибка, мол так и надо. Хотя, на мой взгляд, там где есть eval() — всегда есть потенциальная уязвимость.
Тогда Женя нарыл вторую ошибку, в функции очистки тегов $modx->stripTags() — багрепорт.
Смысл в том, что движок парсит теги на определенную глубину, а потом просто отдает, что осталось. И ему можно подсунуть что угодно. Например:
При более подробных раскопках мы выяснили, что виновата даже не функция, а регулярное выражение, которое чистит строки от тегов MODX (232 строка в классе):
Вот консольная команда, для GNU/Linux серверов:
Вы делаете это на свой страх и риск и я не несу никакой ответственности, если у вас что-то сломается.
Здесь было видео с демонстрацией взлома сайтов при помощи этих уязвимостей. Команда MODX попросили удалить его — смотри update внизу
Выражаю огромную благодарность Евгению Борисову за нахождение этой баги. Надеюсь, ее быстро прикроют.
Написал полезный плагин для очистки системных плейсхолдеров, которые вам не нужны, а злоумышленнику — очень даже:
Оказывается, такие баги нужно постить не на публичный трекер, а сразу на почту support@modx.com или security@modx.com. Кто ж знал?
А то, что на трекере баг признали «не ошибкой» — ошибка. Поэтому, видео попросили удалить, пока команда с нашей помощью активно разбирается с проблемой.
С нашей стороны — Евгений Борисов, Валентин Расулов и я. С их — Mark Hamstra и некая MODX core team.
Ошибка подтверждена, скоро будет официальный фикс.
Смотрим историю изменений.
Подвержены все сайты на Revo.
Первая: функция eval() в фильтре math. Позволяет вызывать произвольный php код. Багрепорт. Модыксеры сказали, что это не ошибка, мол так и надо. Хотя, на мой взгляд, там где есть eval() — всегда есть потенциальная уязвимость.
Тогда Женя нарыл вторую ошибку, в функции очистки тегов $modx->stripTags() — багрепорт.
Смысл в том, что движок парсит теги на определенную глубину, а потом просто отдает, что осталось. И ему можно подсунуть что угодно. Например:
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[]]]]]]]]]]]]]]]]]]]]*id]]
Если скрестить эти 2 ошибки, то можно вломать практически любой сайт на MODX Revolution.При более подробных раскопках мы выяснили, что виновата даже не функция, а регулярное выражение, которое чистит строки от тегов MODX (232 строка в классе):
@\[\[(.[^\[\[]*?)\]\]@si
Нужно заменить его на любое другое, более надежное. Например:@\[\[(.*?)\]\]@si
Через эту регулярку проходят все $_GET запросы, ее же использует $modx->stripTags(), которая обеззараживает данные в очень многих расширениях. Поэтому вам нужно срочно пролечить свой modx.class.php, пока авторы MODX делают вид, будто ничего не происходит.Вот консольная команда, для GNU/Linux серверов:
find -type f -name modx.class.php -exec sed -i 's#\[^\\\[\\\[]##g' {} \;
Заходим в директорию, где у вас лежат сайты и вызываем ее от суперюзера. Она найдет все modx.class.php и заменит выражение на более простое и надежное.Вы делаете это на свой страх и риск и я не несу никакой ответственности, если у вас что-то сломается.
Здесь было видео с демонстрацией взлома сайтов при помощи этих уязвимостей. Команда MODX попросили удалить его — смотри update внизу
Выражаю огромную благодарность Евгению Борисову за нахождение этой баги. Надеюсь, ее быстро прикроют.
Кстати
Написал полезный плагин для очистки системных плейсхолдеров, которые вам не нужны, а злоумышленнику — очень даже:
if ($modx->event->name == 'OnLoadWebDocument') {
$arr = array('+connections0dsn','+connections0username','+connections0password','+dsn');
foreach ($arr as $v) {
unset($modx->placeholders[$v]);
}
}
Можно посмотреть, что еще опасного выводится у вас на сайте, просто вызвав в любом сниппете print_r($modx->placeholders);
Все что вам не нужно, но может быть использовано злоумышленником — засовывайте в плагин, не помешает.Обновление от 12.11.2012
Оказывается, такие баги нужно постить не на публичный трекер, а сразу на почту support@modx.com или security@modx.com. Кто ж знал?
А то, что на трекере баг признали «не ошибкой» — ошибка. Поэтому, видео попросили удалить, пока команда с нашей помощью активно разбирается с проблемой.
С нашей стороны — Евгений Борисов, Валентин Расулов и я. С их — Mark Hamstra и некая MODX core team.
Ошибка подтверждена, скоро будет официальный фикс.
Обновление от 13.11.2012
Смотрим историю изменений.
[#9080] В modX::$sanitizePatterns теперь сначала удаляются теги, потом все лишние открывающие и закрывающие скобки. [#9080] В modX::stripTags() лимит соседних скобок стал 99, вместо 10 - modX::sanitizeRequest прогоняет массивы значений из $_GET - Системный параметр allow_tags_in_post установлен в false. По умолчанию все теги MODX будут вычищены из $_POST! [#9069] Долбанный фильтр math с eval() удален.
Комментарии: 24
Спасибо
Для этого есть раздел «Спасибо мне» вот тут: bezumkin.ru/contacts.html
Шикарно. Правда у меня на своем сайте через поиск SimpleSearch не получилось повторить с math… И с phpinfo() в чанке тоже не вышло…
Дайте ссылку — Евгений быстро покажет, как надо.
C phpinfo через чанк получилось. А вот в SimpleSearch все-таки регулярка другая используется же:
А mSearch использует эту бажную функцию:
Автор SimpleSearch splittingred разве не в команде разработчиков? Получается использует для одного и того же нормальную и бажную функцию)
public function sanitize($text) {
$text = strip_tags($text);
$text = preg_replace('/(\[\[\+.*?\]\])/i', '', $text);
return $this->modx->stripTags($text);
}
А mSearch использует эту бажную функцию:
$text = $this->modx->stripTags($text);
Автор SimpleSearch splittingred разве не в команде разработчиков? Получается использует для одного и того же нормальную и бажную функцию)
В mSearch давно фикс был, но я не выпускал новую версию некогда.
Сегодня выпустил, обновляйтесь.
Сегодня выпустил, обновляйтесь.
На гитхабе обновился только docs 5 часов назад
На гитхабе фикс был уже давно
Тоже проверил на двух сайтах, сначало ничего не вышло, писал сам теги. Скорпировал пример — вывело id ресурса и сразу заменил регулярку и установил плагин)
Спасибо, Василий!
Спасибо, Василий!
я заменил на
'tags' => '@[\[|\]]@si',
— просто скобок не стало, а то раздрожают меня они.
Просто нет слов!
Это наша супер надежная Рево))
И модификатор math который по словам Коварда совсем не баг!
Жени респект!
Это наша супер надежная Рево))
И модификатор math который по словам Коварда совсем не баг!
Жени респект!
Примерно это я и хотел показать, когда ковырял движок
Бага реально серьезная. А с таким отношением разработчиков я уже пожалел, что отправил эту инфомрацию в паблик.
Да уж, это очень печалит, отзывчивостью и не пахнет.
Подобное в паблик — жестко, да еще и инструкцией для скрипт-киди
Дык это ж не бага: «This is not a bug.»
конечно не бага, это так, ладошкой по попке))
Ну а как еще?
Разработчики проигнорировали.
Разработчики проигнорировали.
По поводу бага #9069, ответ opengeek был, что это не баг: ведь в бэкенде MODXа, все могут делать то, что хотят. Это вопрос доверия, он говорил. Ответ показывает, что есть разногласия насчет менеджера.
После небольшого знакомства с MODX, у меня есть впечатление, что создатели колеблются между двумя идеями по поводу бэкенда:
1. Бэкенд — это место только для админов, у них есть свой контекст, закрыт для всех остальных. Это не место для редакторов или менеджеров. Для последних надо построить собственные закрытые структуры с авторизацией (например через новый контекст). Поэтому существуют такие плагины как Login и другие. Может поэтому у создателей нет проблем с тем, что менеджер очень сложно написан, его очень сложно изменять графически.
2. Бэкенд — это для всех редакторов. Любые публикации на сайте делаются через бэкенд. Любой редактор заходит с определенными правами.
И тут некий конфликт. Например: любой менеджер, который может создать новый юзер, может его назначить sudo user. Он может изменить свои собственные права и права людей по-выше. Это понятно только, если бэкенд понимается как очень узкое место только для узкого круга админов. Ответ opengeek идет в это направление.
А другие создатели говорят: нет! нужные развернутые права в менеджере! Нужны form customization для менеджера! Чтобы можно было многогранно определить полномочия и видимость каждого юзера в менеджере!
Поэтому такая неразбериха, как мне кажется.
После небольшого знакомства с MODX, у меня есть впечатление, что создатели колеблются между двумя идеями по поводу бэкенда:
1. Бэкенд — это место только для админов, у них есть свой контекст, закрыт для всех остальных. Это не место для редакторов или менеджеров. Для последних надо построить собственные закрытые структуры с авторизацией (например через новый контекст). Поэтому существуют такие плагины как Login и другие. Может поэтому у создателей нет проблем с тем, что менеджер очень сложно написан, его очень сложно изменять графически.
2. Бэкенд — это для всех редакторов. Любые публикации на сайте делаются через бэкенд. Любой редактор заходит с определенными правами.
И тут некий конфликт. Например: любой менеджер, который может создать новый юзер, может его назначить sudo user. Он может изменить свои собственные права и права людей по-выше. Это понятно только, если бэкенд понимается как очень узкое место только для узкого круга админов. Ответ opengeek идет в это направление.
А другие создатели говорят: нет! нужные развернутые права в менеджере! Нужны form customization для менеджера! Чтобы можно было многогранно определить полномочия и видимость каждого юзера в менеджере!
Поэтому такая неразбериха, как мне кажется.
«его очень сложно изменять графически»))) порадовало)
Кстати, из-за плагина приведенного выше не работает плагин miniShop, если кому интересно.
Не знаете, сейчас эти дыры прикрыты (2.2.7-pl)? Или постоянно надо «патчить» до сих пор?
Давно прикрыты.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.