Comments 52
Спасибо
Вот за что я не люблю бесплатные CMSки… Их никак не могут допилить, а когда находят дыру — ломаются абсолютно все копии в инете :-(
Даю пример сайта на проприетарных технологиях (IIS, VB.NET)
Здесь не проверяется переменная кол-ва записей на странице и делается выборка во всю таблицу.
Точно то же на сайте Adobe (коммерческий ColdFusion)
Разруха не в сортирах.
Займитесь прямым своим делом и вершите неуязвимое.
А в описанном случае тот файл роли не играет — его можно стереть и забыть, ничего не ломается.
P. S.
топик бы уместно пошел в блог ИБ или WordPress
Здесь не проверяется переменная кол-ва записей на странице и делается выборка во всю таблицу.
Точно то же на сайте Adobe (коммерческий ColdFusion)
Разруха не в сортирах.
Займитесь прямым своим делом и вершите неуязвимое.
А в описанном случае тот файл роли не играет — его можно стереть и забыть, ничего не ломается.
P. S.
топик бы уместно пошел в блог ИБ или WordPress
В вашем «примере сайта на проприетарных технологиях», во-первых, используется не VB.NET, а что-то из обычного ASP (vbscript или javascript), а во-вторых, проприетарность технологии слабо коррелирует с криворукостью разработчика.
Просто тенденция такова, что на php больше бесплатного кода, чем на том же asp. Соответственно, и косяков там больше.
Просто тенденция такова, что на php больше бесплатного кода, чем на том же asp. Соответственно, и косяков там больше.
UFO just landed and posted this here
Как уже подметили выше — в платных проблем не меньше, я даже скажу более того: разнообразные студии со своими CMS подвергают опасности своих клиентов, т.к. достаточно часто ихние системы уязвимы и взломав один сайт студии можно пойти на сайт этой студии и посмотреть её портфолио со всеми уязвимыми сайтами. То что исходный код системы закрыт — это не значит, что она менее уязвима, просто в ней труднее найти уязвимости.
UFO just landed and posted this here
всё просто, теория ошибок — «В любой программе содержится хотя бы одна ошибка»
Есть теория, к которой я всё больше в последнее время склоняюсь, что соотношение количества багов к объему кода — число постоянное, т.к. это тот самый человеческий фактор, и без устранения причины — не устранишь следствие.
Вот когда кодить будут роботы, написанные роботами, тогда и можно надеяться на отсутствие багов, а пока терпите. Так то!
Вот когда кодить будут роботы, написанные роботами, тогда и можно надеяться на отсутствие багов, а пока терпите. Так то!
MS DOS или DDOS? :)
Как-то все по-пионерски.
1. Судя по exploit это buffer overflow и проблема в php — следовательно нужна его версия, ссылка на баг и так далее
2. Если баг в php не исправлен, то опасности подвержен не только WP.
1. Судя по exploit это buffer overflow и проблема в php — следовательно нужна его версия, ссылка на баг и так далее
2. Если баг в php не исправлен, то опасности подвержен не только WP.
Скорее это таки уязвимость WP, либо «любые данные нужно проверять!».
Не в курсе насколько быстро php выполняет операции с очень большими строками, но идущие:
Не в курсе насколько быстро php выполняет операции с очень большими строками, но идущие:
$charset = strtoupper( trim($charset) );
strpos($charset, 'UTF-7')
if ( function_exists('mb_convert_encoding') ) { // For international trackbacks
$title = mb_convert_encoding($title, get_option('blog_charset'), $charset);
$excerpt = mb_convert_encoding($excerpt, get_option('blog_charset'), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option('blog_charset'), $charset);
}
с километровой $charset уложит на лопатки кого угодно.либо:=ибо;
Я согласен что косяк у WP есть, но например у меня этот кусок вместе с данными из приведенного эксплоита проблем ни на сервере ни на девелоперской тачке не вызвали. Да и в общем-то не должны были вызвать имхо.
А у некоторых вот так бывает:
Here’s the results from a quick test against my server:
21:30:29 up 21 days, 1:06, 19 users, load average: 49.06, 27.11, 19.24
Here’s the results from a quick test against my server:
21:30:29 up 21 days, 1:06, 19 users, load average: 49.06, 27.11, 19.24
за комментарии, трэкбэки, регистрацию и xmlrpc отвечает по отдельному файлу
что из списка отрублено в настройках — устраняю вопрос вместе с файлом
сам протокол делает меня мнительным — у меня в корне лежит файл с известным всему миру названием,
любой может независимо от меня пустить некешируемый скрипт, дергающий базу, и создать нагрузку
что из списка отрублено в настройках — устраняю вопрос вместе с файлом
сам протокол делает меня мнительным — у меня в корне лежит файл с известным всему миру названием,
любой может независимо от меня пустить некешируемый скрипт, дергающий базу, и создать нагрузку
у меня полностью проц съело, тотестил блин на себе )
по ссылке автора есть эксплоит )
p.s. кстати по логам уже видно что что проверял кроме меня…
по ссылке автора есть эксплоит )
p.s. кстати по логам уже видно что что проверял кроме меня…
UFO just landed and posted this here
А если трекбеки отключены?
Я у себя на всякий случай запер /wp-admin под http basic авторизацию. Хак конечно, но уж очень часто именно там находят дырьки в безопасности.
Спасибо! Пофиксился…
Предлагаю слегка модифицировать патч.
Заменить
Заменить
Предлагаю слегка модифицировать патч. Заменить строку 7
с
if ( strlen($charset) > 50 ) { die; }
на
if ( strlen($charset) > 50 ) { die(«Holy shit! I'm dieing....»); }
Все надо делать с юмором :)
с
if ( strlen($charset) > 50 ) { die; }
на
if ( strlen($charset) > 50 ) { die(«Holy shit! I'm dieing....»); }
Все надо делать с юмором :)
Спасибочки ;-)
эхх побегу изучать php :-D
С каждуй сборкой все более интересные дырки :-/
эхх побегу изучать php :-D
С каждуй сборкой все более интересные дырки :-/
Wordpress — это ужаснейшее сочетание php4 и php5 кода. Пока разработчики не найдут в себе силы переписать его с нуля на php5 и держа в уме возможные варианты атак мы будем видеть как находят в вордпрессе новые дырки и пишут уродливые хаки чтобы их заткнуть…
UFO just landed and posted this here
Debian 4, php-fpm 5.3.0 за nginx, WP версии 2.8.4. Эксплоит работает.
На wordpress.org уже дают скачать 2.8.5 версию с исправленным багом.
wordpress.org/development/2009/10/wordpress-2-8-5-hardening-release/
wordpress.org/development/2009/10/wordpress-2-8-5-hardening-release/
UFO just landed and posted this here
Насколько я понимаю при работе с Wordpress файлы движка вообще не должны меняться. Для работы достаточно менять файлы шаблона блога, и пользоваться файликом functions.php если чего-то не хватает, ну и плагины конечно.
А вот файлы движка изменять не нужно. Я не особо ковырялся в WPMU, но думаю что там такая же концепция.
А вот файлы движка изменять не нужно. Я не особо ковырялся в WPMU, но думаю что там такая же концепция.
На счет изменённых файлов движка не знаю, но может вам поможет вот эта статья?
i1t2b3.com/2009/05/19/sites-on-single-wp-install/
i1t2b3.com/2009/05/19/sites-on-single-wp-install/
Sign up to leave a comment.
Новая уязвимость Wordpress — возможна DOS атака