Plaadid W^X kaitsemehhanismi tugevdamiseks OpenBSD-s

Theo De Raadt jagatud W^X (Write XOR Execute) mälu kaitse mehhanismi tugevdamise plaanid. Mehhanismi olemus seisneb selles, et protsessi mälulehed ei saa olla samal ajal kirjutamiseks ja täitmiseks ligipääsetavad. Seega saab koodi täita ainult pärast kirjutamise lubamise lõpetamist ning kirjutamine mälu lehe sisse on võimalik ainult pärast täitmise keeldumist. W^X mehhanism aitab kaitsta kasutajaruumi rakendusi tüüpiliste rünnakute eest, mis on teostatud mälupuhverduste ülekoormuse kaudu, sealhulgas ka virna ülekoormuste eest ja on aktiivne OpenBSD-s. vaikimisi.

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

• Lülitavad mälu W ja X olekute vahel, leppides 'süsteemikutsumise' 'kuludega'. mprotect.
• Loovad pseudonüümid W ja X kahe sama mälu kaardistuse vahel.
• Kõige 'mustem' variant — nõuab W|X mälumudelit, mis lubab samaaegset kirjutamist ja täitmist.

Praegu on kolmandat varianti kasutavate programmide arv oluliselt vähenenud, samas kui esimese ja teise variandi kasutamine on suurenenud. Siiski, kuna oli vaja käivitada ka programe W|X JIT (peamiselt Chromium ja Iridium), lisati failisüsteemi ühendamise valik "wxallowed", mis võimaldas kasutada mälu samaaegselt nii kirjutamiseks kui ka käitamiseks, juhul kui käivitatav ELF-fail oli märgitud märgisega "wxneeded", samal ajal kui rakendusi kaitsti täiendavalt, kasutades mehhanisme. pledge ja unveil süsteemikõnede kasutamise loendi ja rakendusele kergesti ligipääsetavate failisüsteemi osade piiramiseks.

Haavatavuse ärakasutamise edasiseks keerukamaks muutmiseks sarnastes rakendustes on ette pandud mehhanismi täiendus. MAP_STACK, mis kontrollib, kas süsteemikõne toimub kirjutatavast mälulehest. Kui leht on kirjutatav, lõpetatakse protsess sunniviisiliselt. Nii ei saa ründaja kasutada süsteemikõnesid ja peab proovima leida vajalikke seadmeid JIT-i rakenduses või isegi tegema keerulisemat tööd, et avastada süsteemikõnede plokke otse. juhuslikult seotud libc.

Chrome/Iridium protsessid on piisavalt hästi kaitstud pledge ja unveil abil, kuid näiteks write(2) süsteemikõne kasutamise keelamine annab ilmselgelt teatud eelise, kuna see tekitab ründajale täiendavaid raskusi. Siiski võivad raskused tekkida ka juhul, kui JIT-i rakendus kasutab natiivseid süsteemikõnesid W|X mälust. Kuid on põhjust loota, et sellise probleemiga ei pea kokku puutuma, kuna ABI on korduvalt muutunud, kuid keegi pole kunagi probleemidest teatanud.

Muutused on juba saadaval OpenBSD-Ccurrent haru regulaarsetes snapshotides, kõik huvilised on kutsutud testima.

Teo on kommentaari võrra tähelepanuväärsed uudised Chrome'i/Iridiumi režiimi ilmumise kohta JITless. Tema arvates on see mõnede kasutusmudelite jaoks vastuvõetav, kuid tõenäoliselt mitte kõigi jaoks, kuna selle režiimi korral tõuseb protsessori koormus ilmselgelt. Praegu töötab Chrome peamiselt siis, kui „wxallowed“ on välja lülitatud /usr/local, kuigi mõningate laiendustega (näiteks ghostery) võivad esineda probleemid. Nii või teisiti loodab Teo, et JITless-režiimi täieõiguslik toimimine viiakse täieliku töökorrani peagi.

Allikas: opennet.ru