Theo De Raadt a memória W^X (Write XOR Execute) védelmi mechanizmusának megerősítésére irányuló tervekkel. A mechanizmus lényege, hogy a folyamat memóriájának oldala nem lehet egyszerre írási és végrehajtási hozzáféréssel elérhető. Így a kód csak írás tilalmának feloldása után futtatható, míg a memória oldalra való írás csak végrehajtás tilalmának feloldása után lehetséges. A W^X mechanizmus segít megvédeni a felhasználói térben lévő alkalmazásokat a tipikus támadásoktól, amelyeket puffertúlcsordulás útján hajtanak végre, beleértve a veremtúlcsordulásokat, és aktív az OpenBSD-ben. .
A W^X-ra vonatkozó munkálatok megkezdésekor nyilvánvaló volt, hogy ez hosszú út lesz, mivel jelentős számú JIT alkalmazás létezik. A JIT megvalósításokat három kategóriára lehet osztani:
- A memóriát W és X állapotok között váltogató, kiszolgálva a rendszervCalls költségeit. .
- Pseudonimokat létrehozó, amelyek ugyanazon memória pár W és X leképezésével összekapcsolódnak.
- A leg „koszosabb” lehetőség — a W|X memória modellt igénylő, amely lehetővé teszi az írás és végrehajtás egyidejű végrehajtását.
Jelenleg jelentősen csökkent az ilyen harmadik lehetőséget használó programok száma, és nőtt az első és második lehetőséget használóké. Ennek ellenére, mivel szükség volt W|X JIT programok (főként a Chromium és az Iridium) futtatására, bevezetésre került egy „wxallowed” fájlrendszer csatolási opció, amely lehetővé tette a memória egyidejű írását és végrehajtását, ha az ELF fájlok végrehajthatóságát a „wxneeded” jelzővel jelölték, míg maguk az alkalmazások további védelmet kaptak a mechanizmusok használatával. és a rendszervCalls felhasználásának és az alkalmazás számára elérhető fájlrendszer részeinek listájának korlátozására vonatkozóan.
A hasonló alkalmazások sebezhetőségeinek kihasználásának további bonyolítása érdekében javasolt egy kiegészítő mechanizmus bevezetése, , amely ellenőrzi, hogy a rendszervCalls végrehajtása egy írásra elérhető memóriából történik-e. Ha az oldal írásra elérhető, a folyamat kényszerítve leáll. Így a támadó nem tudja használni a rendszervCalls-t, és kénytelen lesz megpróbálni megtalálni a szükséges gadgeteket a JIT megvalósításában, vagy még nehezebb munkát végezni a rendszervCalls tüskék nyomozásával közvetlenül a .
A Chrome/Iron folyamatok már elegendően védettek a pledge és unveil segítségével, de a write(2) rendszerhívás használatának megtiltása nyilvánvalóan bizonyos előnyökkel jár, mivel további nehézségeket okoz a támadó számára. Mindazonáltal problémák merülhetnek fel, ha a JIT implementáció natív rendszerhívásokat használ W|X memóriából. Azonban van ok a reménykedésre, hogy ezzel nem kell találkozni, mivel az ABI többször is változott, de senki soha nem számolt be problémákról.
A változások már elérhetők az OpenBSD-CURRENT ágjaiban lévő rendszer snapshotjaiban, minden érdeklődőt szeretettel várunk a tesztelésre.
Theo a Chrome/Iron új üzemmódjával kapcsolatos hírekre kívánt külön megjegyzést tenni. . Nézete szerint ez bizonyos használati modellekhez elfogadható, azonban valószínűleg nem mindenki számára, mivel ebben az üzemmódban nyilvánvalóan növekszik a CPU terhelése. Jelenleg a Chrome főként működni fog, ha letiltják a 'wxallowed' beállítást a /usr/local számára, bár néhány kiegészítő (például a ghostery) problémákat okozhat. Akárhogy is, Theo reméli, hogy a JIT nélküli mód teljes működését a közeljövőben elérik.
Forrás: opennet.ru
