Hacker first change value in user preference generic_message_footer to any file allowed to read roundcube (config/db.inc.php config/main.inc.php), after send herself message (with included config file). This allow view session crypto key, and db user and password. If at hosting installed phpmyadmin (mysql) or pgmyadmin (pgsql) and session saved in db, hacker get user mail login and password.
Finded in Russian tech blog (http://habrahabr.ru/post/174423/).
POST /?_task=settings&_action=save-pref&check_request=&_check_request= HTTP/1.1" 200 1133 "http://mail.ddos-guard.net/?_task=mail" "Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0" "_token=0f7c9ae8a387cb0bc5ce563fa09fe172&_session=generic_message_footer&_name=generic_message_footer&_value=config/db.inc.php
index.php:
else if ($RCMAIL->action == 'save-pref') { include INSTALL_PATH . 'program/steps/utils/save_pref.inc'; }
program/steps/utils/save_pref.inc:
$name = get_input_value('_name', RCUBE_INPUT_POST); $value = get_input_value('_value', RCUBE_INPUT_POST);
// save preference value
$RCMAIL->user->save_prefs(array($name => $value));
//<--------- rewrite value
// update also session if requested if ($sessname = get_input_value('_session', RCUBE_INPUT_POST)) { // Support multidimensional arrays... $vars = explode('/', $sessname);
// ... up to 3 levels
if (count($vars) == 1)
$_SESSION[$vars[0]] = $value;
else if (count($vars) == 2)
$_SESSION[$vars[0]][$vars[1]] = $value;
else if (count($vars) == 3)
$_SESSION[$vars[0]][$vars[1]][$vars[2]] = $value;
}
$OUTPUT->reset(); $OUTPUT->send();
program/steps/mail/sendmail.inc
// generic footer for all messages
if ($isHtml && !empty($CONFIG['generic_message_footer_html'])) {
$footer =
file_get_contents(realpath($CONFIG['generic_message_footer_html']));
//<----- load file from value path
$footer = rcube_charset_convert($footer, RCMAIL_CHARSET,
$message_charset);
}
else if (!empty($CONFIG['generic_message_footer'])) {
$footer =
file_get_contents(realpath($CONFIG['generic_message_footer']));
//<----- load file from value path
$footer = rcube_charset_convert($footer, RCMAIL_CHARSET,
$message_charset);
if ($isHtml)
$footer = '<pre>'.$footer.'</pre>';
}
We already fixed the issue in git branches: master, release-0.9, release-0.8, release-0.7. We'll release updated packages soon.
This path https://github.com/roundcube/roundcubemail/commit/0fcb2b139bf0c50dec3b828984... not secure because only limit read file by extension php,ini,conf and folder /etc. Allowed read /usr/local/etc logs and other file (if hosting not limit open_basedir).
A.L.E.C писал 2013-03-27 20:11:
We already fixed the issue in git branches: master, release-0.9, release-0.8, release-0.7. We'll release updated packages soon.
On Wed, Mar 27, 2013 at 5:47 PM, Sergey Sidlyarenko roundcube@lefoyer.ru wrote:
This path https://github.com/roundcube/roundcubemail/commit/0fcb2b139bf0c50dec3b828984... not secure because only limit read file by extension php,ini,conf and folder /etc. Allowed read /usr/local/etc logs and other file (if hosting not limit open_basedir).
This isn't the main patch but only an additional sanity check. I'm well aware that this check isn't bullet proof but it covers the worst cases in the local Roundcube directory. And on shared hosting environments, openbasedir is mostly installed which would then avoid syste-wide access.
The more important fix is to avoid overwriting arbitrary user prefs. This is fixed in https://github.com/roundcube/roundcubemail/commit/648fcf5709
~Thomas
The more important fix is to avoid overwriting arbitrary user prefs. This is fixed in https://github.com/roundcube/roundcubemail/commit/648fcf5709
If we pull the new code, do we need to modify plugins that change prefs?
Cor
On 03/27/2013 08:24 PM, Cor Bosman wrote:
If we pull the new code, do we need to modify plugins that change prefs?
Yes, if plugin uses save-pref command, it should define $allowed_prefs variable in plugin class. The variable should contain a list of option names.
On Mar 27, 2013, at 8:35 PM, "A.L.E.C" alec@alec.pl wrote:
On 03/27/2013 08:24 PM, Cor Bosman wrote:
If we pull the new code, do we need to modify plugins that change prefs?
Yes, if plugin uses save-pref command, it should define $allowed_prefs variable in plugin class. The variable should contain a list of option names.
Just to be absolutely sure, this is not related to the preferences_save hook?
Cor
On 03/27/2013 08:54 PM, Cor Bosman wrote:
Yes, if plugin uses save-pref command, it should define $allowed_prefs variable in plugin class. The variable should contain a list of option names.
Just to be absolutely sure, this is not related to the preferences_save hook?
No. Preferences available (only) via Settings > Preferences don't need to be listed there.
Am 27.03.2013 20:35, schrieb A.L.E.C:
On 03/27/2013 08:24 PM, Cor Bosman wrote:
If we pull the new code, do we need to modify plugins that change prefs?
Yes, if plugin uses save-pref command, it should define $allowed_prefs variable in plugin class. The variable should contain a list of option names.
Alec,
could you please clarify.
Do we need $allowed_prefs, if we are using the preferences_save hook, or do we need the definition if we are using rcmail::get_instance()->user->save_prefs(...), or is it needed for both?
Will the patches be included in git branches? Will it be included in official downloads from sourceforge for 0.8.5 and 0.9-rc?
Regards, Rosali
On 03/28/2013 08:16 AM, Rosali wrote:
Do we need $allowed_prefs, if we are using the preferences_save hook, or do we need the definition if we are using rcmail::get_instance()->user->save_prefs(...), or is it needed for both?
None of these. Only if plugin uses save-pref request from javascript, e.g. rcmail.command('save-pref',....) or rcmail.save_pref(...) or rcmail.http_post('save-pref',...). It's because utils/save_pref.inc is the only place where we check this whitelist. User preferences saved by Settings/Preferences interface are validated in other places.
Will the patches be included in git branches? Will it be included in official downloads from sourceforge for 0.8.5 and 0.9-rc?
New releases are available.
Am 27.03.2013 17:04, schrieb Sergey Sidlyarenko:
Hacker first change value in user preference generic_message_footer to any file allowed to read roundcube (config/db.inc.php config/main.inc.php), after send herself message (with included config file). This allow view session crypto key, and db user and password. If at hosting installed phpmyadmin (mysql) or pgmyadmin (pgsql) and session saved in db, hacker get user mail login and password.
else if (!empty($CONFIG['generic_message_footer'])) { $footer = file_get_contents(realpath($CONFIG['generic_message_footer']));
ouch - realpath is completly useless for safety
the only safe way for such things is INSTALL_PATH_CONSTANT . basename($CONFIG['generic_message_footer']) or COMPLETLY avoid let a USER definie which files are used to display and store the text in the database OR use a fixed path fpr default