Plaani W^X kaitse mehhanismi tugevdamiseks OpenBSD-s

Theo de Raadt videosid, kus ta näitas XQEMU emulaatori (emuleerib originaal Xbox konsooli) käivitamist Nintendo Switch'il. Samuti demonstreeris Voxel9, et süsteem suudab käivitada mitmeid mänge, sealhulgas Halo: Combat Evolved. plaanidest mälu kaitsemehhanismi W^X (Write XOR Execute) tugevdamiseks. Mehhanismi sisuks on see, et protsessi mälulehed ei saa olla samaaegselt kirjutamiseks ja täitmiseks kättesaadavad. Seega saab koodi täitmist teha alles pärast kirjutamise keelamist, ja kirjutamine mälulehte on võimalik alles pärast täitmise keelamist. W^X mehhanism aitab kaitsta kasutajaruumi rakendusi tüüpiliste rünnakute eest, mida teostatakse mälu ülevoolu kaudu, sealhulgas virna ülevoolude eest ja on aktiivne OpenBSD-s. vaikimisi.

W^X-i tööde algusest oli selge, et see on pikk tee, kuna on olemas märkimisväärne hulk rakendusi, mis kasutavad JIT-i. JITi rakendusi saab jagada kolme kategooriasse:

• Mälu vahetamine W ja X olekute vahel, leppides süsteemikutse "kuluga". mprotect.
• Loovad pseudonüümid sama mälu W ja X kaardistuste paarile.
• Kõige "räpasem" variant - nõuab W|X mälumudelit, mis võimaldab samaaegset kirjutamist ja täitmist.

Praegu on oluliselt vähem programme, mis kasutavad kolmandat varianti, ja rohkem, mis kasutavad esimest ja teist. Sellegipoolest, kuna tuli käivitada ka W|X JIT-programme (peamiselt Chromium ja Iridium), anti võimalus mountida failisüsteem "wxallowed", mis võimaldas kasutada mälu samaaegselt nii kirjutamiseks kui ka täitmiseks, juhul kui käivitatav ELF-fail on märgitud märgisega "wxneeded", ja ise rakendusi kaitsti, kasutades mehhanisme. pledge ja unveil süsteemikutsude ja rakendusele saadaval olevate failisüsteemi osade nimekirja piiramiseks vastavalt.

Vulnerabiliteedi ärakasutamise veelgi keerukamaks muutmiseks taheti täiendada mehhanismi. MAP_STACK, mis kontrollib, kas süsteemikutse toimub kirjutamises oleva mälu lehelt. Kui leht on kirjutamiseks kättesaadav, lõpetatakse protsess sundlikult. Nii ei saa kurjategija kasutada süsteemikutsesid ja peab proovima leida vajalikud seadmed JIT rakenduse teostuses või isegi tegema keerulisemat tööd, et tuvastada süsteemikutsede silumisvahendeid otse. juhuslikult seotud libc.

Chrome'i/Iridiumi protsessid on piisavalt turvalised, kasutades pledge ja unveil, kuid süsteemikõne write(2) kasutamise võimaluse piiramine annab ründajale ilmselgelt mõningaid eeliseid, kuna loob täiendavaid raskusi. Siiski võivad raskused tekkida ka juhul, kui JIT realiseerimine kasutab natiivseid süsteemikõnesid W|X mälust. Siiski on põhjust loota, et sellise olukorraga ei pea kokku puutuma, kuna ABI on korduvalt muutunud, kuid keegi ei ole kunagi teatatud probleemidest.

Muutused on juba saadaval regulaarsetes OpenBSD-Current harude snapshots, kõik huvilised on kutsutud katsetama.

Teo sai eraldi kommentaari seoses Chrome'i/Iridiumi režiimi ilmumise uudistega JITless. Tema arvates on see vastuvõetav mõnede kasutusmudelite puhul, kuid ilmselt mitte kõigi jaoks, kuna sellel režiimil suureneb protsessori koormus. Praegu töötab Chrome peamiselt siis, kui keelata «wxallowed» /usr/local jaoks, kuigi teatud laiendustega võivad ilmneda probleemid (näiteks ghostery). Igal juhul loodab Teo, et JITless režiimi täielik toimimine viiakse peagi täiesti toimivasse olekusse.

Allikas: opennet.ru