Найдена
уязвимость всей линейки DLE - PHPMailer (осуществляет отправку писем с вложением и массовой рассылки с вложением). Потенциальная уязвимость всей линейки
DLE использует PHPMailer 5.2.16 версии (в файле uploadengineclassesmailclass.phpmailer.php 39 строка). Это хоть и новая версия PHPMailer, но она имеет критическую уязвимости, более подробном читаем далее.
О трех отчёта связанных с уязвимости упоминается в фреймворке Yii наряду и с другими PHP фреймворками как уязвимый код, цель статьи — прояснить, какие сайты подвержен данной уязвимости и что вам необходимо сделать, чтобы обезопасить себя.
Касаемо PHPMailer - Yii официально не предоставлял никаких компонентов, связанных с PHPMailer'ом. К тому же Yii никогда не включал PHPMailer в какой-либо код, который официально выпускался командой Yii.
Упоминание Yii скорее всего в отчётах является копи-пастой из README PHPMailer'a, где говорится, что он может быть применен вместе с фреймворком Yii. Для PHPMailer уже создан патч, достаточно обновиться до версии как минимум 5.2.20.
Однако SwiftMailer отличается, для него мы предоставляем расширение yii2-swiftmailer. SwiftMailer также выпустил патч, нужно обновиться до версии как минимум 5.4.5.
Скачать PHPMailer патч вы можете по следующей ссылке
Внимание! У Вас нет прав для просмотра скрытого текста.
, однако настоятельно рекомендую обновиться до версии 5.2.21
Совместимость с
DataLife Engine 112 версии не проверялась! Беглый осмотр обновленной версии PHPMailer показал, что функции и код сильно не претерпели значимых изменений, вероятней всего всё должно работать хорошо.
Стоит помнить, что class.phpmailer.php в DataLife Engine состоит из 2 файлов: class.phpmailer.php и class.smtp.php, идущими друг за другом.
Кто соберёт файл и протестирует на DLE удачно - не лишним будет выложить в топик.
P.s. во избежание воплей "Да DLE экранирует всё, не критична дыры и баги". Использование библиотеки в которой есть дыра, даже если ты этот кусок не используешь - зло!
p.s. удивляет, что разработчики DLE решили не выпускать промежуточный фикс данной уязвимости.
Так как PHP-функция mail() не предоставляет отдельного параметра для указания адреса отправителя, единственным способом сделать это — является передача строки пятым аргументом ($additional_parameters). Строка должна содержать флаг -f, следом за которым идёт email отправителя (например
[email protected]).
Это приводит к вызову /usr/bin/sendmail со списком параметров, сформированным из вызова PHP-функции mail(). Например:
/usr/sbin/sendmail -t -i [email protected]
Когда разработчик самостоятельно передаёт 5-й аргумент в функцию mail(), подразумевается, что он читает документацию и знает, что email нужно проверить и экранировать, чтобы он был безопасен для использования в командной строке. В случае, если это не сделано, очевидно, что вся ответственность лежит на разработчике, который допустил инъекцию параметров командной строки.
Однако, библиотеки PHPMailer и SwiftMailer предоставляют удобный API, который скрывает факт передачи email в командную строку опасным способом. Разработчик надеется, что библиотеки выполняют достаточное экранирование для обеспечения безопасности вызова программы sendmail.
Обнаруженные уязвимости указывают на то, что библиотеки PHPMailer и SwiftMailer не выполняли достаточного экранирования. Это значит, что если адрес отправителя будет сформирован специальным образом, он будет передан в пятый параметр PHP-функции mail() и выполнен как дополнительные параметры при вызове программы sendmail.
Например, передача следующей строки, как email адреса, позволяет внедрить в параметры -oQ и -X, которые будут обработаны программой sendmail:
-f"attacker" -oQ/tmp/ -X/var/www/cache/phpcode.php some"@email.com
// Приведет к выполнению
/usr/sbin/sendmail -t -i -f"attacker" -oQ/tmp/ -X/var/www/cache/phpcode.php [email protected]
Более подробную информацию по воспроизведению уязвимости можно прочесть по ссылке статьи в Внимание! У Вас нет прав для просмотра скрытого текста.
Кто подвержен опасности?
В первую очередь пользователи, которые используют классы Swift_MailTransport или PHPMailer для отправки сообщений. Эти классы, к свою очередь, используют PHP-функцию mail().
Что нужно сделать, чтобы обезопасить приложение?
Учитывая, что уязвимости касаются только поля "От", вам нужно вспомнить, где в ваших приложениях пользователь может указать собственное значение для адреса отправителя. Чаще всего это используется в контактных формах и скриптах гостевых книг.
Если вы корректно валидируете email на этапе приёма его от пользователя, то эта уязвимость вас скорее всего и не коснётся.
Хорошей практикой является валидация данных сразу при приёме от пользователя, что помогает избежать обработки невалидных данных в других частях приложения, в том числе передачи сторонним библиотекам, которые могут оказаться уязвимыми.
Для Yii существует EmailValidator, который не пропускает адреса по примеру тех, которые использовались в данной уязвимости
Кроме того, в PHP существует нативная функцию filter_var(), которой можно проверить email. Например:
public function validateEmail() {
if (filter_var($this->email, FILTER_VALIDATE_EMAIL) === false) {
throw new InvalidParamException('The email contains characters that are not allowed');
}
}
