frijlitting fan webynhâldbehearsysteem . De frijlitting is opmerklik foar syn foltôging op útfiering updates en tafoegings kontrolearje mei in digitale hantekening.
Oant no ta, by it ynstallearjen fan updates yn WordPress, wie de wichtichste feiligensfaktor fertrouwen yn 'e WordPress-ynfrastruktuer en servers (nei it downloaden waard de hash kontrolearre sûnder de boarne te ferifiearjen). As de tsjinners fan it projekt kompromittearre wiene, koene de oanfallers in update spoofje en kweade koade fersprieden ûnder WordPress-basearre siden dy't in automatysk update-ynstallaasjesysteem brûke. Yn oerienstimming mei it earder brûkte model foar levering fan fertrouwen soe sa'n ferfanging oan 'e kant fan' e brûkers ûngemurken gien wêze.
Mei it each op it feit dat fan it w3techs-projekt wurdt it WordPress-platfoarm brûkt op 33.8% fan siden op it netwurk, it ynsidint soe op 'e skaal fan in ramp nommen hawwe. Tagelyk wie it gefaar fan kompromis ynfrastruktuer net hypotetysk, mar frij reëel. Bygelyks, ferskate jierren lyn ien fan 'e feiligens ûndersikers in kwetsberens wêrtroch in oanfaller syn koade op 'e serverkant fan api.wordpress.org koe útfiere.
Yn it gefal fan digitale hantekeningen, it krijen fan kontrôle oer de fernijingsdistribúsjetsjinner sil net liede ta kompromis fan brûkerssystemen, om't om in oanfal út te fieren, moatte jo ek in apart opsleine privee kaai krije, wêrmei fernijings wurde tekene.
De ymplemintaasje fan it kontrolearjen fan de boarne fan fernijings mei in digitale hantekening waard hindere troch it feit dat stipe foar de nedige kryptografyske algoritmen relatyf koartlyn yn it standert PHP-pakket ferskynde. De nedige kryptografyske algoritmen ferskynden troch de yntegraasje fan 'e bibleteek oan it haadteam . Mar as de minimale stipe ferzje fan PHP yn WordPress release 5.2.4 (fan WordPress 5.2 - 5.6.20). It ynskeakeljen fan stipe foar digitale hantekeningen soe liede ta in signifikante ferheging fan 'e easken foar de minimale stipe ferzje fan PHP of de tafoeging fan in eksterne ôfhinklikens, wat ûntwikkelders net kinne dwaan sjoen de prevalens fan PHP-ferzjes yn hostingsystemen.
De oplossing wie en it opnimmen fan in kompakte ferzje fan Libsodium yn WordPress 5.2 - , wêryn in minimale set fan algoritmen foar it ferifiearjen fan digitale hantekeningen yn PHP ymplementearre is. De ymplemintaasje lit in protte te winskjen oer yn termen fan prestaasjes, mar lost it kompatibiliteitsprobleem folslein op, en lit ek plugin-ûntwikkelders begjinne mei it ymplementearjen fan moderne kryptografyske algoritmen.
In algoritme wurdt brûkt om digitale hantekeningen te generearjen , ûntwikkele mei de dielname fan Daniel J. Bernstein. In digitale hantekening wurdt oanmakke foar de SHA384-hashwearde berekkene út de ynhâld fan it fernijingsargyf. Ed25519 hat in heger nivo fan feiligens as ECDSA en DSA, en toant tige hege snelheid fan ferifikaasje en hântekening oanmeitsjen. De ferset tsjin hacking foar Ed25519 is sawat 2 ^ 128 (gemiddeld sil in oanfal op Ed25519 2 ^ 140 bit operaasjes fereaskje), wat oerienkomt mei it ferset fan algoritmen lykas NIST P-256 en RSA mei in kaaigrutte fan 3000 bits of 128-bit blok cipher. Ed25519 is ek net gefoelich foar problemen mei hash botsingen, en is net gefoelich foar cache-timing oanfallen of kant-kanaal oanfallen.
Yn 'e WordPress 5.2-release beslacht ferifikaasje fan digitale hantekening op it stuit allinich grutte platfoarmupdates en blokkeart de fernijing net standert, mar ynformearret allinich de brûker oer it probleem. It waard besletten om de standertblokkering net direkt yn te skeakeljen fanwege de needsaak foar in folsleine kontrôle en bypass . Yn 'e takomst is it ek pland om ferifikaasje fan digitale hantekening ta te foegjen om de boarne fan ynstallaasje fan tema's en plugins te ferifiearjen (fabrikanten sille releases mei har kaai kinne ûndertekenje).
Neist stipe foar digitale hantekeningen yn WordPress 5.2, kinne de folgjende wizigingen wurde opmurken:
- Twa nije siden binne tafoege oan 'e seksje "Site Health" foar it debuggen fan mienskiplike konfiguraasjeproblemen, en in formulier is ek levere wêrmei ûntwikkelders debuggen-ynformaasje kinne litte oan sidebehearders;
- Tafoegde ymplemintaasje fan it "wyt skerm fan 'e dea", werjûn yn gefal fan fatale problemen en helpt de behearder om selsstannich problemen te reparearjen yn ferbân mei plugins of tema's troch te wikseljen nei in spesjale crashherstelmodus;
- In systeem foar it kontrolearjen fan kompatibiliteit mei plugins is ymplementearre, dy't automatysk de mooglikheid kontrolearret om it plugin yn 'e hjoeddeistige konfiguraasje te brûken, rekken hâldend mei de brûkte ferzje fan PHP. As in plugin in nijere ferzje fan PHP fereasket om te wurkjen, sil it systeem automatysk it opnimmen fan dizze plugin blokkearje;
- Stipe tafoege foar it ynskeakeljen fan modules mei JavaScript-koade brûke и ;
- In nije privacy-policy.php-sjabloan tafoege wêrmei jo de ynhâld fan 'e side mei privacybelied kinne oanpasse;
- Foar tema's is in wp_body_open hook handler tafoege, sadat jo ynfoegje koade fuortendaliks nei it lichem tag;
- Easken foar de minimale ferzje fan PHP binne ferhege nei 5.6.20; plugins en tema's hawwe no de mooglikheid om nammeromten en anonime funksjes te brûken;
- 13 nije ikoanen tafoege.
Dêrneist kinne jo neame krityske kwetsberens yn WordPress-plugin (CVE-2019-11185). De kwetsberens kinne willekeurige PHP-koade wurde útfierd op 'e tsjinner. De plugin wurdt brûkt op mear as 27 tûzen siden om in ynteraktyf petear mei in besiker te organisearjen, ynklusyf op 'e siden fan bedriuwen lykas IKEA, Adobe, Huawei, PayPal, Tele2 en McDonald's (Live Chat wurdt faak brûkt om pop-up ferfelend te ymplementearjen petearen op bedriuwssiden mei aanbiedingen petear mei de meiwurker).
It probleem manifestearret him yn 'e koade foar it opladen fan bestannen nei de tsjinner en kinne jo de kontrôle fan jildige bestânstypen omgean en in PHP-skript oplade nei de tsjinner, en dan direkt fia it web útfiere. Ynteressant waard ferline jier in ferlykbere kwetsberens al identifisearre yn Live Chat (CVE-2018-12426), wêrtroch PHP-koade laden koe ûnder it mom fan in ôfbylding, en in oare ynhâldstype spesifisearje yn it fjild Ynhâldtype. As ûnderdiel fan 'e fix binne ekstra kontrôles tafoege foar whitelists en MIME-ynhâldtype. Sa't bliken docht, wurde dizze kontrôles ferkeard útfierd en kinne maklik wurde omgean.
Benammen it direkte opladen fan bestannen mei de ".php"-útwreiding is ferbean, mar de ".phtml"-útwreiding, dy't ferbûn is mei de PHP-tolk op in protte servers, waard net tafoege oan 'e swarte list. De whitelist lit allinich ôfbyldings uploaden, mar jo kinne it omgean troch in dûbele útwreiding oan te jaan, bygelyks ".gif.phtml". Om de MIME-typekontrôle oan it begjin fan it bestân te omgean, foardat de tag mei PHP-koade iepene waard, wie it genôch om de rigel "GIF89a" op te jaan.
Boarne: opennet.ru