Theo De Raadt a W^X (Write XOR Execute) memóriavédelmi mechanizmus megerősítését tervezi. A mechanizmus lényege, hogy a folyamatmemória oldalaihoz nem lehet egyszerre hozzáférni íráshoz és végrehajtáshoz. Így a kód csak az írás letiltása után hajtható végre, és a memórialapra írás csak a végrehajtás letiltása után lehetséges. A W^X mechanizmus segít megvédeni a felhasználói terület alkalmazásokat a gyakori puffertúlcsordulási támadásoktól, beleértve a verem túlcsordulást, és aktív az OpenBSD-ben. .
A W^X-en végzett munka kezdete óta egyértelmű volt, hogy ez hosszú út volt, mivel jelentős számú alkalmazás volt JIT-t használva. A JIT megvalósítások három kategóriába sorolhatók:
- Memória váltása W és X állapotok között, elfogadva a rendszerhívás „költségét”. .
- Fedőnevek létrehozása ugyanazon memória W és X leképezései között.
- A leginkább „piszkos” opciók azok, amelyek egy W|X memóriamodellt igényelnek, amely lehetővé teszi az egyidejű rögzítést és végrehajtást.
Jelenleg lényegesen kevesebb program használja a harmadik lehetőséget, és több az elsőt és a másodikat. Mivel azonban a programokat W|X JIT-tel kellett futtatni (főleg Chromium és Iridum), egy "wxallowed" fájlrendszer beillesztési opcióval egészült ki, amely lehetővé tette a memória egyidejű használatát írásra és végrehajtásra, abban az esetben, ha a futtatható ELF fájlt a „wxneeded” jelölő jelöli, és magukat az alkalmazásokat is védték mechanizmusok segítségével и hogy korlátozza a használt rendszerhívások listáját és a fájlrendszer alkalmazás számára elérhető részeit, ill.
Az ilyen alkalmazásokban lévő sérülékenységek kihasználásának további bonyolítása érdekében javasolt a mechanizmus kiegészítése. , amely ellenőrzi, hogy a rendszerhívást írható memórialapról hajtják-e végre. Ha az oldal írható, a folyamat kénytelen leállni. Ily módon a támadó nem tudja kihasználni a rendszerhívásokat, és kénytelen lesz megkeresni a szükséges modulokat a JIT implementációban, vagy akár a rendszerhívás csonkjainak közvetlenül a belsejében történő észlelésének nehezebb feladatát is elvégezni. .
A Chrome/Iridium folyamatok már meglehetősen megbízhatóan védettek a pledge and unveil használatával, de például a write(2) rendszerhívás használatának megszüntetése nyilvánvalóan előnyt jelent, mivel további nehézségeket okoz a támadónak. Azonban nehézségek adódhatnak akkor is, ha a JIT implementáció natív rendszerhívásokat használ a W|X memóriából. Van azonban okunk remélni, hogy ez nem így lesz, hiszen az ABI-t többször módosították, de soha senki nem jelentett problémákat.
A változtatások már elérhetőek az OpenBSD-Current ág szokásos pillanatképeiben, minden érdeklődőt szeretettel várunk a tesztelésre.
A mód Chrome/Iridiumban való megjelenésével kapcsolatos kapcsolódó hírek külön megjegyzést érdemelnek Theotól . Az ő szemszögéből ez bizonyos használati modelleknél elfogadható, de valószínűleg nem mindegyiknél, hiszen ez a mód nyilvánvalóan megnöveli a processzor terhelését. Jelenleg a Chrome többnyire akkor fog működni, ha letiltja a "wxallowed"-et a /usr/local számára, bár problémák adódhatnak egyes bővítményekkel (például a ghostery). Így vagy úgy, Theo reméli, hogy a JITless módban végzett teljes értékű munka a közeljövőben teljesen működőképes állapotba kerül.
Forrás: opennet.ru