Рэліз WordPress 5.2 з падтрымкай праверкі абнаўленняў па лічбавым подпісе

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

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

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

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

Укараненню праверкі крыніцы абнаўленняў па лічбавым подпісе замінала тое, што падтрымка неабходных крыптаграфічных алгарытмаў з'явілася ў штатнай пастаўцы PHP адносна нядаўна. Патрэбныя крыптаграфічныя алгарытмы з'явіліся дзякуючы інтэграцыі бібліятэкі Лібнатрый у асноўны склад 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-кодам з выкарыстаннем вэб-пакет и Гамарня;
  • Дададзены новы шаблон 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

Дадаць каментар