WordPress rregullon defektin e ekzekutimit të kodit në distancë në Imagick

WordPress 7.0.4 përfshin një rregullim për një dobësi të ekzekutimit të kodit në distancë në bibliotekën e përpunimit të imazheve Imagick. Studiuesit e sigurisë në Patchstack, të udhëhequr nga Shefi i Kërkimit të Sigurisë Dave Jong, përshkruan se si një autor i regjistruar mund të ngarkonte një skedar që duket si imazh, por në fakt është një program PostScript, duke çuar në ekzekutimin e kodit në serverin web. Dobësia prekte versionet e bërthamës së WordPress 4.7 deri në 7.0, dhe njoftimi i WordPress.org konfirmon lëshimin e mirëmbajtjes. Për pronarët e faqeve, ky është një përditësim prioritar sepse mbyll një rrugë që mund ta kthejë një ngarkim rutinë të medias në një komprometim të plotë të serverit.

WordPress përdor ImageMagick, një mjet i fuqishëm me burim të hapur për përpunimin e imazheve, përmes një zgjerimi PHP të quajtur Imagick për të trajtuar ndryshimin e madhësisë dhe përpunimin e imazheve në Bibliotekën e Medias. Problemi është se ImageMagick kupton shumë më tepër sesa formatet e zakonshme si JPEG dhe PNG. Ai gjithashtu mund të hapë skedarë PostScript, EPS dhe PDF, dhe për t'i dhënë ato, thërret Ghostscript, një program që interpreton PostScript dhe PDF dhe ka një histori të gjatë të mashtrimit për të ekzekutuar komanda që nuk duhet. Kjo është e njëjta familje problemesh si defektet e vjetra ImageTragick. Thelbi i problemit është një mospërputhje: ImageMagick vendos se çfarë është një skedar duke lexuar përmbajtjen e tij, jo ekstensionin e tij, ndërsa WordPress kryesisht i besonte ekstensionit të skedarit. Pra, një skedar i quajtur holiday.png që në fakt përmban kod PostScript do të kalonte kontrollet e ngarkimit, do t'i dorëzohej Imagick, i cili njeh PostScript-in brenda dhe ndez Ghostscript për të ekzekutuar kodin.

Kodi i prekshëm ndodhet në metodën WP_Image_Editor_Imagick::load() të WordPress. Kjo metodë vendoste se si t'i kalonte një skedar të ngarkuar ImageMagick bazuar vetëm në ekstensionin e skedarit, pa inspektuar kurrë përmbajtjen e skedarit. Kodi fillimisht kontrollonte nëse ekstensioni është pdf, dhe nëse jo, thërriste readImage() ose readImageBlob(), të cilat nuhasin bajtet magjike të skedarit dhe injorojnë emrin e skedarit. Pra, përmbajtja që fillon me nënshkrimet %!, \x04%!, \xC5\xD0\xD3\xC6, ose \xFFWPC zgjedh dekoderin PostScript, EPS ose WPG të ImageMagick, i cili më pas thërret Ghostscript për të ekzekutuar skedarin si një program PostScript. Gjatë një fluksi normal të ngarkimit të skedarëve, funksioni wp_check_filetype_and_ext() i WordPress e kap këtë mospërputhje dhe parandalon sulmin. Por jo çdo rrugë ngarkimi kalon nëpër atë kontroll. Metoda wp.uploadFile e XML-RPC dhe rutina e nxjerrjes së kopertinës për MP3-të e ngarkuara të dyja i shkruajnë bajtet e tyre me wp_upload_bits(), e cila kurrë nuk inspekton përmbajtjen, kështu që ngarkesa keqdashëse zbret në disk dhe arrin te kodi i prekshëm.

Patchstack raporton se rregullimi është në commit 7daaa50 në bërthamën e WordPress. Funksioni i përditësuar load() tani kontrollon përmbajtjen reale të skedarit përpara se të ndërtojë objektin Imagick, kështu që asgjë nuk i kalon kurrë një dekoderi të familjes PostScript. Konkretisht, arnimi nuhashet pjesën e parë të çdo skedari dhe refuzon skedarët PostScript dhe EPS sipas nënshkrimeve të tyre, sipas ekstensionit ose sipas parashtesave të specifikuesit të formatit ImageMagick. Ai gjithashtu refuzon PDF-të false, që do të thotë skedarë që pretendojnë një ekstension PDF, por nuk fillojnë me shenjën reale %PDF-. Ai bllokon skedarët e ngjeshur që ImageMagick do t'i shpaketonte në heshtje, si arkivat gzip dhe bzip2, të cilat ishin një mënyrë tjetër për të kontrabanduar përmbajtje përtej kontrolleve. Ekziston gjithashtu një pjesë më delikate: ImageMagick ju lejon të detyroni një trajtues të veçantë duke parashtesuar një emër skedari, si EPS:innocent.png. Kodi i ri i heq dhe inspekton këto parashtesa, duke qenë i kujdesshëm që të mos pengohet nga shkronjat e diskut të Windows si C:, kështu që një sulmues nuk mund të përdorë emrin e skedarit për ta drejtuar Imagick drejt Ghostscript. Për shkak se i njëjti mashtrim mund të vijë përmes një URL-je në distancë ose një rrjedhe, rregullimi analizon emrat e skedarëve nga ato burime përpara se t'i vërtetojë ato.

Për ta shfrytëzuar këtë dobësi, një sulmues duhet të jetë në gjendje të ngarkojë media, që do të thotë një llogari në nivel Autor ose më e lartë në WordPress. Ky nuk është një sulm anonim, i rastësishëm që çdokush mund ta nisë. Por shumë faqe u japin llogari Autori më lirshëm sesa mendojnë. Nëse drejtoni një publikim me shumë autorë, një faqe anëtarësie, një faqe klienti me kontribues ose ndonjë gjë me regjistrim të hapur ose të menaxhuar lirshëm, ai pengesë aksesi është shumë më e ulët se sa tingëllon. Në ato faqe, një Autor që ngarkon një imazh të kurthuar është një kërcënim vërtet realist, jo teorik. Nëse faqja juaj ka vetëm ju dhe një grup të ngushtë redaktorësh të besuar, ekspozimi juaj është më i vogël, por përditësimi është ende i rëndësishëm sepse një llogari redaktori e komprometuar mund të përdoret në të njëjtën mënyrë.

Veprimi i menjëhershëm është përditësimi i WordPress në versionin 7.0.4 ose më të ri. Nëse keni aktivizuar përditësimet automatike në sfond, mund të jeni tashmë të mbuluar, kështu që ia vlen të kontrolloni shpejt versionin tuaj aktual. Nëse përditësoni manualisht, jepini përparësi këtij, veçanërisht në çdo faqe ku llogaritë shpërndahen përtej ekipit tuaj kryesor. Ky incident është gjithashtu një kujtesë e dobishme për trajtimin e medias në përgjithësi: pjesa e rrezikshme zakonisht nuk është vetë imazhi, por gjithçka tjetër që biblioteka e imazheve është e gatshme të hapë në heshtje. Për pronarët e faqeve që duan të zvogëlojnë dritaren e ekspozimit midis një lëshimi sigurie dhe aplikimit të tij, pritja e menaxhuar e WordPress si AEU Hosting ofron mirëmbajtje të fokusuar në siguri, duke përfshirë përditësimet e automatizuara të bërthamës dhe shtojcave si pjesë e platformës së saj të siguruar nga fundi në fund. Ky lloj përditësimi i menaxhuar ndihmon të sigurohet që arnime të tilla të instalohen menjëherë pa kërkuar ndërhyrje manuale.

Së fundi, rishikoni rolet e përdoruesve në faqen tuaj. Hiqni aksesin në nivel Autor nga kushdo që nuk ka nevojë për të, dhe konsideroni përdorimin e një shtojce sigurie që inspekton përmbajtjen e skedarëve gjatë ngarkimit, jo vetëm ekstensionet. Mësimi kryesor nga ky defekt është se emrat e skedarëve nuk janë një tregues i besueshëm i asaj që përmban në të vërtetë një skedar, dhe kontrollet e sigurisë duhet të shikojnë vetë të dhënat.