Teo De Raadt plány na posílení mechanismu ochrany paměti W^X (Write XOR Execute). Podstatou mechanismu je, že stránky paměti procesu nemohou být současně přístupné pro zápis a provádění. Kód může být tedy proveden pouze po zakázání zápisu, a zápis do stránky paměti je možný pouze po zakázání provádění. Mechanismus W^X pomáhá chránit aplikace v uživatelském prostoru před typickými útoky prováděnými pomocí přetečení bufferu, včetně přetečení zásobníku a je aktivní v OpenBSD. .
Od začátku práce na W^X bylo jasné, že to bude dlouhá cesta, jelikož existuje značné množství aplikací využívajících JIT. Implementace JIT lze rozdělit do tří kategorií:
- Přepínající paměť mezi stavy W a X, smiřující se s "náklady" systémového volání. .
- Vytvářející aliasy mezi dvojicí W a X mapování téže paměti.
- Nejvíce "špinavá" varianta — vyžadující model paměti W|X, který povoluje současné provádění zápisu a provádění.
V současnosti je mnohem méně programů využívajících třetí variantu a více těch, které využívají první a druhou. Nicméně, jelikož bylo potřebné spouštět i programy s W|X JIT (zejména Chromium a Iridium), byla přidána možnost montování souborového systému "wxallowed", která umožnila používat paměť současně pro zápis i provádění, pokud byl prováděný ELF soubor označen značkou "wxneeded", a samotné aplikace byly navíc chráněny pomocí mechanismů a pro omezení seznamu používaných systémových volání a dostupných částí souborového systému pro aplikaci.
Pro další ztížení využívání zranitelností v takových aplikacích bylo navrženo doplnění mechanismu , které kontroluje, zda je systémové volání vykonáváno z dostupné stránky paměti pro zápis. Pokud je stránka dostupná pro zápis, proces je násilně ukončen. Tímto způsobem útočník nebude schopen používat systémová volání a bude nucen se snažit najít potřebné gadgety v implementaci JIT nebo dokonce vykonávat složitější práci při odhalování zástupců systémových volání přímo uvnitř .
Procesy Chrome/Iridium jsou dostatečně chráněny pomocí pledge a unveil, ale omezení možnosti používat například systémový volání write(2) má zřejmé výhody, protože vytváří pro útočníka další komplikace. Nicméně komplikace mohou nastat i v případě, že implementace JIT používá nativní systémové volání z W|X paměti. Existují však důvody věřit, že se s tímto nebudeme muset potýkat, protože ABI se opakovaně měnilo, ale nikdo nikdy nehlásil žádné problémy.
Změny jsou již dostupné v pravidelných snímcích větve OpenBSD-CURRENT, všichni zájemci jsou zváni k testování.
Samostatného komentáře od Thea si zasloužily související novinky o zavedení režimu v Chrome/Iridium . Z jeho pohledu je to přijatelné pro některé modely použití, ale pravděpodobně ne pro všechny, protože v tomto režimu se zjevně zvýší zátěž na procesor. Nyní bude Chrome většinou fungovat, pokud se zakáže "wxallowed" pro /usr/local, i když je pravděpodobné, že dojde k problémům s některými rozšířeními (např. ghostery). Tak či onak, Theo doufá, že plnohodnotná funkčnost v režimu JITless bude brzy dosažena.
Zdroj: opennet.ru
