Comments 33
Автоматическая рассылка уведомлений об обновлениях, которая появится в версии 3.5, будет как нельзя кстати.
все важные секьюрити патчи должны ставится автоматом
Как раз нет. Ибо тот, кто скомпрометирует сервер обновлений — автоматически пропатчит всех пользователей.
Так работает вордпресс и как то… спокойнее, зная что он хором по всей планете автопатчит серьезные уязвимости.
Так работает винда, антивирусы и куча другого софта. Этож нормально. А чтобы не скомпрометировали надо делать так чтобы не скомпрометировали :-)
Так работает винда, антивирусы и куча другого софта. Этож нормально. А чтобы не скомпрометировали надо делать так чтобы не скомпрометировали :-)
У меня как-то на древней-древней серверной убунте стояло автообновление. Много лет назад. И была там грустная история, когда вышла новая версия с опечаткой в ядре (или не в ядре, но в чём-то очень критичном). Опечатку оперативно испраили и образ новый перезалили минут через 40, но те у кого стояло автообновление его выкачать успели и уронили себе системы. С тех пор — лучше руками.
Вы описали момент в памяти.
Ну это же вид суеверия, при котором мы ожидаем ошибки и обходим её казалось бы правильным способом. Так проблема зачастую ошибок в их непредсказуемости. Ну не пользоваться чтоли теперь автообновлением али кто то когда то где то раз испортил ощущение безопасности сего функционала. Вы могли бы обновить руками в эти 40 мин. и получить тот же результат. Кто то наверняка так и сделал и теперь только добавил уровень стресса в работе с обновлением в ручную.
Не, касаемо обновлений бубунты каждый сам решает как ему удобнее. В принципе если вы не цель хакера номер 1который так и ждёт как бы подловить ваш сайт то снижение уровня стресса от непредсказуемости при автообновлении дело хорошее. Однако для cms это крайне важно.
Лучше случайно положить, чем дать дорогу спаму, массовых хаков, иддос атак. для тысяч серверов. То есть в случае прокола с автообновлением ответственный есть. И его можно страховать и побить). В случае новых дырок в старых системах поделать уже мало чего можно.
Ну это же вид суеверия, при котором мы ожидаем ошибки и обходим её казалось бы правильным способом. Так проблема зачастую ошибок в их непредсказуемости. Ну не пользоваться чтоли теперь автообновлением али кто то когда то где то раз испортил ощущение безопасности сего функционала. Вы могли бы обновить руками в эти 40 мин. и получить тот же результат. Кто то наверняка так и сделал и теперь только добавил уровень стресса в работе с обновлением в ручную.
Не, касаемо обновлений бубунты каждый сам решает как ему удобнее. В принципе если вы не цель хакера номер 1который так и ждёт как бы подловить ваш сайт то снижение уровня стресса от непредсказуемости при автообновлении дело хорошее. Однако для cms это крайне важно.
Лучше случайно положить, чем дать дорогу спаму, массовых хаков, иддос атак. для тысяч серверов. То есть в случае прокола с автообновлением ответственный есть. И его можно страховать и побить). В случае новых дырок в старых системах поделать уже мало чего можно.
В случае прокола с автообновлением как раз ответственного нет. Тот же wordpress «не несёт ответственности за…» и дальше по тексту. Если обновляться руками — то оператор как минимум должен убедиться, что всё будет работать до и после и весь процесс — под его ответственность. Если оператор бездумно клацает «NEXT-NEXT-NEXT», то это исключительно его проблемы, но не нужно пытаться доказать, что автоматическое обновление — это тот же процесс, только автоматизированный, тем самым приравнивая всех к таким вот операторам.
аналогичный баг был с CentOS в январе этого года, правда не с ядром, а с несовместимостью стандартных пакетов после установки одного из них.
UFO just landed and posted this here
В Joomla! тоже уже несколько лет есть уведомления на главной странице админки, правда, не RSS.
Вот только показываются они (и кнопка обновления) только тем пользователям, у кого есть на обновление права.
Как часто вы заходите в админку сайта, если «все работает», а особенно — если наполняете сайт не вы, а редакторы, которым это уведомление не приходит?
Здесь же достаточно указать e-mail, который точно есть у каждого, и который и так указывается при конфигурации сайта, и получать обновления вместе с другими письмами с сайта. Не нужно никаких дополнительных подписок на рассылки ИБ на сайтах, настройки новостных лент (к тому же RSS пользуются не все).
Другой вопрос, что такую функциональность надо было сделать еще в версии 1.0 десять лет назад, а не вводить сегодня.
Вот только показываются они (и кнопка обновления) только тем пользователям, у кого есть на обновление права.
Как часто вы заходите в админку сайта, если «все работает», а особенно — если наполняете сайт не вы, а редакторы, которым это уведомление не приходит?
Здесь же достаточно указать e-mail, который точно есть у каждого, и который и так указывается при конфигурации сайта, и получать обновления вместе с другими письмами с сайта. Не нужно никаких дополнительных подписок на рассылки ИБ на сайтах, настройки новостных лент (к тому же RSS пользуются не все).
Другой вопрос, что такую функциональность надо было сделать еще в версии 1.0 десять лет назад, а не вводить сегодня.
А можно ли привести пример временной меры для nginx?
Я правильно понимаю что это специфично для MySQL? Если у меня постгрес, мне бояться нечего?
Во вторник 14 декабря команда разработки Joomla выпустила срочное обновление безопасности, закрывающее 0-day уязвимость
Как уязвимость может быть 0-day если компания уже выпустила закрывающее ее обновление?
https://ru.wikipedia.org/wiki/%D0%A3%D1%8F%D0%B7%D0%B2%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D1%8C_%D0%BD%D1%83%D0%BB%D0%B5%D0%B2%D0%BE%D0%B3%D0%BE_%D0%B4%D0%BD%D1%8F
0-day — это такое модное нынче слово для привлечения внимания, если в продукте есть 0-day — то все пропало, нужно срочно покупать дорогие межсетевые экраны типа PT Application Firewall, да и вообще лучше купить коммерческий Bitrix или NetCat, в них же типа нет дыр.
Экспертам из Positive Technologies следует обратить внимание и на коммерческие CMS, в которых зачастую за приличные деньги существует приличное количество дыр о которых умалчивается.
Экспертам из Positive Technologies следует обратить внимание и на коммерческие CMS, в которых зачастую за приличные деньги существует приличное количество дыр о которых умалчивается.
Это была 0-day уязвимость, пока не выпустили исправления.
Судя по описанию о уязвимости стало известно аж 12-го декабря.
Уязвимость становиться не 0-day на следующий день после появления.
Уязвимость становиться не 0-day на следующий день после появления.
Судя по тому, что ей подвержены все версии, начиная с 1.5, она могла пробыть в статусе 0-day очень долго. Это сейчас нам стало о ней известно, но не факто что кто-то не знал о ней раньше…
Специфика современного интернета такова, что он напичкан ханипотами, ids различного уровня, waf`ами, поэтому массовая эксплуатация данной уязвимости годами маловероятна. Для примера — эксплуатацию этой уязвимости нашли Securi, они зафиксировали первую попытку эксплуатации как минимум за 2 дня до официального патча:
Уязвимость была в статусе 0-day долгие годы, другое дело, знал ли кто о ней, эксплуатировал ли. Для этого нужно грепать старые логи.
That is very concerning is that this vulnerability is already being exploited in the wild and has been for the last 2 days. Repeat: This has been in the wild as a 0-day for 2 days before there was a patch available.
Уязвимость была в статусе 0-day долгие годы, другое дело, знал ли кто о ней, эксплуатировал ли. Для этого нужно грепать старые логи.
При вставке строки, в конце которой присутствует такой символ, MySQL обрежет данные.Коротко: MySQL в очередной раз ведет себя не как база данных, а как херня, написанная школьником. На этот раз это привело к критической уязвимости.
При STRICT_TRANS_TABLES=1 MySQL будет выдавать ошибку. Начиная с версии 5.7.5 строгий режим включен по умолчанию. И нельзя не отметить разработчиков Joomla, использующих неправильную кодировку для таблиц. Кстати, похожий баг был в WordPress: vagosec.org/2013/09/wordpress-php-object-injection
При STRICT_TRANS_TABLES=1 MySQL будет выдавать ошибку. Начиная с версии 5.7.5 строгий режим включен по умолчанию.Это должно было быть поведением по-умолчанию с самого рождения MySQL. Я не большой специалист по базам данных, но даже мне это очевидно.
И нельзя не отметить разработчиков Joomla, использующих неправильную кодировку для таблиц.Какую они использовали кодировку и какая правильная?
Кстати, похожий баг был в WordPressЯ боюсь, что «похожий баг» был не только в Wordpress, а вообще везде где используется MySQL. Просто где-то уже нашли как применить такое поведение MySQL, а где-то еще нет.
В Joomla используется кодировка utf8, нужно использовать utf8mb4. Мой посыл в том, что необходимо знать, как правильно пользоваться инструментами, которые ты выбрал; сам инструмент не виноват, если его используют неправильно.
Чесно вам скажу, я пользуюсь MySQL не первый год, и я вообще первый раз слышу, что есть такая кодировка как utf8mb4. Конечно, это я мудак, «неправильно пользуюсь инструментом», но черт возьми, нахрена мне инструмент, который на каждом шагу подкладывает мне грабли под ноги?
Виноват MySQL. И разработчики MySQL тоже виноваты. Нужно всегда исходить из того, что разработчик не может знать все сразу, так что нечего на них спихивать проблему.
Виноват MySQL. И разработчики MySQL тоже виноваты. Нужно всегда исходить из того, что разработчик не может знать все сразу, так что нечего на них спихивать проблему.
Ждумля — это, вообще, кладезь дыр. От самого двигла, заканчивая шаблонами и модулями.
После выхода новости мы успели спасти ~15 проектов, но еще несколько успели заразиться… Самое интересное что часть взломов прошла через визуальный редактор JCE. Но заражение пошло не по плану, и обрушилась Mysql с ошибкой MySQL server has gone away
Зловред закопался в активный шаблон. Аккуратно добавив в начало index.php (шаблона) <?php include_once('ob_cache.php'); ?> и в конец <?php ob_end_flush(); ?>
Собственно сам код ob_cache.php http://pastebin.com/GUJc1vj8
Красиво сделали…
Зловред закопался в активный шаблон. Аккуратно добавив в начало index.php (шаблона) <?php include_once('ob_cache.php'); ?> и в конец <?php ob_end_flush(); ?>
Собственно сам код ob_cache.php http://pastebin.com/GUJc1vj8
Красиво сделали…
Был найден сам файл, который добавил эту гадость (исходник): pastebin.com/sWXYFng1
Это позволяет сформировать и записать в таблицу сессий строку без нарушения синтаксиса.
Синтаксис нарушается. Джумла пишет в таблицу сессии сериализованный массив __default|a:7:{...}, а при использовании данной уязвимости можно записать в свойство session.client.browser пайлоад, который начинается с }__test, чтобы закрыть массив default и открыть объект test, синтаксис которого валиден. Но при этом массив default получается невалидным по 3 причинам: количество его элементов(a:7) уже меньше 7, во-вторых параметр s:22:«session.client.browser»;s:435:" остаётся не закрытым, но и самая большая проблема, которую никак не обойти, в отличии от двух предыдущих, длина этого параметра равна длине нашей полезной нагрузки, то есть, в данном случае, 435.
Это чревато тем, что при попытке стартануть сессию PHP выдаст предупреждение:
session_start(): Failed to decode session object. Session has been destroyed
И, как вы можете видеть, уничтожит сессию.
Честно говоря, я не понимаю, от чего это зависит. Я думал, что это как-то связанно с версией PHP и уязвимостями CVE-2015-0231 или CVE-2014-8142, но собрав PHP 5.5.18 и попробовав на ней эксплоит не пришел ни к какому результату.
Может, кто-нибудь знает, почему иногда PHP забивает на невалидную сессию, а иногда нет?
Скорее всего это связанно с CVE-2015-6835, но всё равно остаётся загадкой, почему php 5.5.18 остался непобежденным. Хотя соседний мак с мампом и такой же версией php пал с первой попытки.
Sign up to leave a comment.
В CMS Joomla обнаружена критическая 0-day уязвимость