The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

08.05.2019 14:41

Представлен релиз системы управления 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".

  1. Главная ссылка к новости (https://paragonie.com/blog/201...)
  2. OpenNews: В WordPress 5.1.1 устранена уязвимость, позволяющая получить контроль над сайтом
  3. OpenNews: Раскрыты детали уязвимости в WordPress 5.0.0
  4. OpenNews: Релиз системы управления web-контентом WordPress 5.0 с новым web-редактором
  5. OpenNews: Создан ClassicPress, форк WordPress с классическим web-редактором
  6. OpenNews: Библиотека Sodium Compat поможет реализовать верификацию обновлений в WordPress
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50649-wordpress
Ключевые слова: wordpress, cms
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 15:22, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > В случае применения цифровых подписей получение контроля над сервером распространения обновлений не приведёт к компрометации пользовательских систем, так как для проведения атаки дополнительно понадобиться получить отдельно хранящийся закрытый ключ, при помощи которого осуществляется подпись обновлений.

    Как это реализуется?
    Если взломать инфраструктуру и послать хеш архива с бекдором на подпись, то юзеры также получат такое обновление.

     
     
  • 2.6, Аноним (6), 15:54, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как бы все пакетные системы, использующие цифровые подписи, основаны на том, что доступ к приватному ключу ограничен.
     
     
  • 3.10, Аноним (2), 17:23, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так и как это реализуется? Поделись, если знаешь. Можно ссылкой.
     
     
  • 4.12, Ключевский (?), 18:04, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Могу рассказать как это реализовано у меня.
    У меня есть репозиторий с пакетами для неких проектов.
    Есть виртуалка на которой все собирается, эта виртуалка не имеет выхода в инет, он ей просто не сделан, ее никто туда не пустит. Она получает все свои обновления c одного из двух серверов в локалке к которым может обращаться(там у меня apt-cacher-ng обслуживающий всю локалку), с него же она получает исходники того, что должна собирать. Виртуалка включается только на время, когда ей нужно собрать пакеты, собирает их и выгружает на сервер с репозиторием внутри локалки(а это вторая точка с которой она может общаться по сети, все остальное ей запрещено). Из тестового репозитория на этом сервере тестовые виртуалки ставят все к себе и тестируют обнову, если все нормально, то пакеты переносятся в основной репозиторий в локалке, к которому по VPN имеют доступ все сервера и с которого они накатывают обновления.

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

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

     
     
  • 5.18, Аноним (18), 21:00, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А если репозиторий один (тут ведь один?), то чем не хватает HTTPS?
     
     
  • 6.19, Онаним (?), 21:06, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что получив доступ к файловому хранилищу репозитория, любой школьник может залить туда свой "контент".
    Сервер подписей на то и сервер подписей, что он отделён от основной инфраструктуры.
     
  • 6.20, Аноним (20), 22:00, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Онаним верно глаголит, что по всем стандартам сервер подписывающий должен быть отделен, а товарищ выше очень правильно описал пример своей инфраструктуры, хотя мне кажется, что для фрилансера админящего несколько мелких проектов он слишком заморочился, но все сделал идеологически верно.

    Сервер собирающий и подписывающий должен быть изолирован полностью на случай взлома сервера раздающего, они не должны даже знать друг о друге, все через посредника и сервер собирающий должен быть недоступен при взломе сервера раздающего, что бы не впарили людям левые пакеты и что бы при взломе можно было быстрым движением вернуть правильные пакеты взад, сразу после перестановке сервера раздающего(перестановка, так как взломанный сервер считается скомпроментированным и подлежит только чистой перестановке)

     
  • 5.27, Аноним (27), 05:04, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Побольше бы таких фрилансеров, как вы. Без иронии.

    Я уже устал всем объяснять очевидные, казалось бы, вещи.

     
     
  • 6.32, Ключевский (?), 15:19, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да я просто считаю это нормой. У меня так было давным давно в офисе, когда ушел на фриланс организовал для себя аналогичную инфраструктуру. Клиенты с которыми работаю на постоянной основе подключаются к VPNу для мониторинга основного работающего в моей сети и для обновлений того что я собираю, внешний мониторинг следит только за доступностью всякого веба снаружи, на случай каких-то недоразумений(мало ли что, вдруг изнутри будет доступно, а снаружи нет, надо такое проверять). С подписями пакетов считаю возможным только так работать, потому что мало ли какая фигня, мало ли мою машину как-то смогут взломать(вряд ли, но всегда надо допускать), подписываться должны на отдельной изолированой только так подписи можно доверять.
     

  • 1.3, Груст (?), 15:33, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ещё одни.
     
     
  • 2.5, мурзилла (?), 15:52, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ага. Проект г-но и из г-на, ломают раз в три дня - но их больше всего заботит, ну надо же ж, чтоб злые хакеры не подсунули неправильное обновление.

    результат будет примерно как у нас - через пару лет всеми забытый ключ поэкспайрится, или его просто проимеют вместе с плохо читавшейся флэшкой, и как раз когда надо будет заткнуть всеми уже имеемую дырку на всех этих миллионах инстансов - ой, оно не работает, вам надо вон там скачать (по http) непойми что, подсунуть вон туда, запустить в шелле (ваш хостер не дает шелл? ну мы даже и не знаем) вот это, и тогда автообновление легко и просто установится!

     

  • 1.4, Аноним (4), 15:50, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Шо творится! Эдак ведь и до pip с npm дойдёт. А может быть, чем чёрт не шутит, и до альтлинукса.
     
     
  • 2.13, Антон (??), 19:28, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну если там чето про webpack то ноду они уже прикрутили, теперь надо потихоньку начинать выкидывать php код
     
     
  • 3.16, Онаним (?), 19:44, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Больше лефтпадов, хороших и разных.
     
     
  • 4.25, Наноним (?), 01:43, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никто не забыт, ничто не забыто
     

  • 1.7, BlackRot (?), 15:59, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Хороший движок. Спасибо разработчикам! 🙂
     
     
  • 2.15, Онаним (?), 19:43, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да. Очень хороший для всяких мейлеров, майнеров и прочих ботов. Спасибо разработчикам!
     
     
  • 3.22, BlackRot (?), 23:30, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Значит вы неудачник! А вообще забавно читать коменты от тех кто никогда не юзал WP
     

  • 1.8, Аноним (8), 16:12, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Ed25519 обладает более высоким уровнем безопасности, чем ECDSA и DSA, и демонстрирует очень высокую скоростью верификации и создания подписей

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

     
  • 1.11, аноним11 (?), 18:02, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    хз надо ли оно, но по крайней мере ничего не поломало.
     
     
  • 2.17, Онаним (?), 19:45, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это временно. опыт мозиллы зарамозителлен
     

  • 1.14, Онаним (?), 19:42, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Белый список допускает только загрузку изображений, но обойти его можно указав двойное расширение, например, ".gif.phtml

    Плагины от безграмотных такие плагины.

     
  • 1.28, Какаянахренразница (ok), 07:29, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Опять что-то сломалось. Я понимаю, что я жопорукий и мой плагин отражает это, но как же я задолбался чинить его после каждого релиза...
     
  • 1.29, iCat (ok), 10:51, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот когда же эта древнючая архаика (определение типа файла по трём буковкам в конце имени файла) уйдёт в прошлое?
     
     
  • 2.30, FreeStyler (ok), 15:17, 09/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что собственно в этом плохого? Всё равно он не выполнится, если расширение не соответствует.
     

  • 1.31, FreeStyler (ok), 15:17, 09/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    но обойти его можно указав двойное расширение, например, ".gif.phtml"
    Это не уровень вебмакак, это уровень вебамёб! -__-
    Пи3е3, дно пробито... facepalm
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру