Релиз WordPress 5.2 с поддержкой проверки обновлений по цифровой подписи

Представлен релиз системы управления web-контентом WordPress 5.2. Выпуск примечателен завершением шестилетней эпопеи по реализации возможности проверки обновлений и дополнений по цифровой подписи.

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

С учётом того, что по данным проекта w3techs платформа WordPress используется на 33.8% сайтов в сети, инцидент принял бы масштаб катастрофы. При этом опасность компрометации инфраструктуры была не гипотетической, а вполне реальной. Например, несколько лет назад один из исследователей безопасности продемонстрировал уязвимость, позволявшую атакующему выполнить свой код на стороне сервера api.wordpress.org.

В случае применения цифровых подписей получение контроля над сервером распространения обновлений не приведёт к компрометации пользовательских систем, так как для проведения атаки дополнительно понадобиться получить отдельно хранящийся закрытый ключ, при помощи которого осуществляется подпись обновлений.

Внедрению проверки источника обновлений по цифровой подписи мешало то, что поддержка необходимых криптографических алгоритмов появилась в штатной поставке PHP относительно недавно. Нужные криптографические алгоритмы появились благодаря интеграции библиотеки Libsodium в основной состав PHP 7.2. Но в качестве минимально поддерживаемой в WordPress версии PHP заявлен выпуск 5.2.4 (начиная с WordPress 5.2 — 5.6.20). Включение поддержки цифровых подписей привело бы к существенному повышению требований к минимально поддерживаемой версии PHP или добавлению внешней зависимости, на что не могли пойти разработчики с учётом распространённости версий PHP в системах хостинга.

Выходом стала разработка и включение в состав WordPress 5.2 компактного варианта Libsodium — Sodium Compat, в котором на языке PHP реализован минимальный набор алгоритмов для проверки цифровых подписей. Реализация оставляет желать лучшего в плане производительности, но полностью решает проблему с совместимостью, а также позволяет разработчикам плагинов начать внедрение современных криптографических алгоритмов.

Для формирования цифровых подписей задействован алгоритм Ed25519, разработанный при участии Дэниеля Бернштейна (Daniel J. Bernstein). Цифровая подпись формируется для значения хэша SHA384, вычисленного от содержимого архива с обновлением. Ed25519 обладает более высоким уровнем безопасности, чем ECDSA и DSA, и демонстрирует очень высокую скоростью верификации и создания подписей. Стойкость к взлому для Ed25519 составляет порядка 2^128 (в среднем для атаки на Ed25519 потребуется совершить 2^140 битовых операций), что соответствует стойкости таких алгоритмов, как NIST P-256 и RSA с размером ключа в 3000 бит или 128-битному блочному шифру. Ed25519 также не подвержен проблемам с коллизиями в хэшах, не чувствителен к атакам через анализ оседания данных в кэше (cache-timing) и атакам по сторонним каналам.

В выпуске WordPress 5.2 проверка цифровой подписи пока охватывает только основные обновления платформы и не приводит по умолчанию к блокированию обновления, а лишь информирует пользователя о возникшей проблеме. Блокировку по умолчанию решено не включать сразу из-за необходимости полной проверки и обхода возможных проблем. В будущем проверку по цифровой подписи также планируется добавить для версификации источника установки тем оформления и плагинов (производители смогут подписывать релизы своим ключом).

Кроме поддержки цифровых подписей в WordPress 5.2 можно отметить следующие изменения:

• В раздел «Site Health» добавлены две новые страницы для отладки типовых проблем с настройкой, а также предоставлена форма, через которую разработчики могут оставлять отладочную информацию администраторам сайта;
• Добавлена реализация «белого экрана смерти», выводимого в случае фатальных проблем и помогающая администратору самостоятельно исправить проблемы, связанные с плагинами или темами, перейдя в специальный режим восстановления после сбоя;
• Реализована система проверки совместимости с плагинами, автоматически проверяющая возможность использования плагина в текущей конфигурации с учётом применяемой версии PHP. Если для работы плагина нужна более новая версия PHP, система автоматически заблокирует включение данного плагина;
• Добавлена поддержка включения модулей с JavaScript-кодом с использованием webpack и Babel;
• Добавлен новый шаблон privacy-policy.php, позволяющий настроить содержимое страницы с условиями соблюдения конфиденциальности;
• Для тем оформления добавлен обработчик wp_body_open hook, позволяющий вставить код сразу после тега body;
• Требования к минимальной версии PHP подняты до 5.6.20, в плагинах и темах оформления появилась возможность использования пространств имён и анонимных функций;
• Добавлено 13 новых пиктограмм.

Дополнительно можно упомянуть выявление критической уязвимости в WordPress-плагине WP Live Chat (CVE-2019-11185). Уязвимость позволяет выполнить произвольный PHP-код на сервере. Плагин используется на более чем 27 тысячах сайтов для организации интерактивного чата с посетителем, в том числе на сайтах таких компаний, как IKEA, Adobe, Huawei, PayPal, Tele2 и McDonald’s (Live Chat часто используется для реализации всплывающих назойливых чатов на сайтах компаний с предложением пообщаться с сотрудником).

Проблема проявляется в коде загрузки файлов на сервер и позволяет обойти проверку допустимых типов файлов и загрузить а сервер PHP-скрипт, после чего выполнить его прямым обращением через web. Интересно, что в прошлом году в Live Chat уже была выявлена похожая уязвимость (CVE-2018-12426), позволявшая загрузить PHP-код под видом изображения, указав иной тип контента в поле Content-type. В рамках исправления проблемы были добавлены дополнительные проверки по белым спискам и MIME-типу содержимого. Как оказалось эти проверки реализованы некорректно и их легко можно обойти.

В частности, прямая загрузка файлов с расширением «.php» запрещена, но в чёрный список не было добавлено расширение «.phtml», на многих серверах связанное с интерпретатором PHP. Белый список допускает только загрузку изображений, но обойти его можно указав двойное расширение, например, «.gif.phtml». Для обхода проверки MIME-типа в начале файла, до открытия тега с кодом PHP, достаточно было указать строку «GIF89a».

Источник: opennet.ru