Plány na posílení bezpečnostního mechanismu W^X v OpenBSD

Theo De Raadt sdílené plánuje posílit mechanismus 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 lze tedy spustit pouze po zakázání zápisu a zápis na stránku 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 běžnými útoky přetečením vyrovnávací paměti, včetně přetečení zásobníku, a je aktivní v OpenBSD ve výchozím nastavení.

Od začátku práce na W^X bylo jasné, že to je dlouhá cesta, protože JIT používalo značné množství aplikací. Implementace JIT lze rozdělit do tří kategorií:

  • Přepínání paměti mezi stavy W a X, přijetí „ceny“ systémového volání mprotect.
  • Vytváření aliasů mezi dvojicí W a X mapování stejné paměti.
  • Nejvíce „špinavá“ možnost vyžaduje model paměti W|X, který umožňuje simultánní záznam a spuštění.

V současnosti výrazně méně programů využívá třetí možnost a více využívá první a druhou. Protože však bylo nutné spouštět programy s W|X JIT (hlavně Chromium a Iridum), byla přidána možnost připojení souborového systému „wxallowed“, která umožňovala používat paměť současně pro zápis i spouštění v případě, že by spustitelný ELF soubor je označen značkou „wxneeded“ a samotné aplikace byly navíc chráněny pomocí mechanismů zástava и odhalit omezit seznam použitých systémových volání a částí souborového systému dostupných pro aplikaci, resp.

Aby se dále zkomplikovalo využívání zranitelností v takových aplikacích, navrhuje se doplnění mechanismu MAP_STACK, který kontroluje, zda se systémové volání provádí ze stránky zapisovatelné paměti. Pokud je stránka zapisovatelná, je proces nucen ukončit. Útočník tak nebude moci zneužít systémová volání a bude nucen zkoušet najít potřebné gadgety v implementaci JIT nebo dokonce vykonávat náročnější práci spočívající v detekci pahýlů systémových volání přímo uvnitř omylem připojený libc.

Procesy Chrome/Iridium jsou již celkem spolehlivě chráněny pomocí pledge and unveil, ale odstranění možnosti používat například systémové volání write(2) má samozřejmě určitou výhodu, protože to útočníkovi vytváří další potíže. Potíže však mohou také nastat, pokud implementace JIT používá nativní systémová volání z paměti W|X. Existuje však důvod doufat, že tomu tak nebude, protože ABI bylo několikrát změněno, ale nikdo nikdy nehlásil problémy.

Změny jsou již k dispozici na běžných snímcích větve OpenBSD-Current, všichni zájemci jsou zváni k testování.

Související novinky o vzhledu režimu v Chrome/Iridium si zaslouží samostatný komentář od Thea JITless. Z jeho pohledu je to přijatelné pro některé modely použití, ale pravděpodobně ne pro všechny, protože tento režim zjevně zvýší zatížení procesoru. V současné době bude Chrome většinou fungovat, pokud zakážete "wxallowed" pro /usr/local, i když mohou nastat problémy s některými rozšířeními (příkladem je gostery). Tak či onak Theo doufá, že plnohodnotná práce v režimu JITless bude v blízké budoucnosti uvedena do plně funkčního stavu.

Zdroj: opennet.ru

Přidat komentář