Theo De Raadt plannen om het geheugenbeschermingsmechanisme W^X (Write XOR Execute) te versterken. Het idee achter dit mechanisme is dat geheugenpagina's van een proces niet gelijktijdig toegankelijk mogen zijn voor schrijfbewerking en uitvoering. Hierdoor kan de code alleen worden uitgevoerd nadat schrijven is verboden, en schrijven naar een geheugenpagina is alleen mogelijk nadat de uitvoering is verboden. Het W^X-mechanisme helpt applicaties in de gebruikersruimte te beschermen tegen typische aanvallen die plaatsvinden via bufferoverlopen, waaronder stackoverlopen, en is actief in OpenBSD. .
Vanaf het begin van het werk aan W^X was het duidelijk dat dit een lange weg zou zijn, gezien het aanzienlijke aantal applicaties dat JIT gebruikt. JIT-implementaties kunnen in drie categorieƫn worden verdeeld:
- Die het geheugen tussen W en X-statussen schakelen, met de 'prijs' van een systeemaanroep in het achterhoofd. .
- Die aliassen creƫren tussen een paar W- en X-mappingen van hetzelfde geheugen.
- De meest 'vuile' variant - die een W|X-geheugenmodel vereist, wat gelijktijdig schrijven en uitvoeren mogelijk maakt.
Tegenwoordig zijn er aanzienlijk minder programma's die de derde variant gebruiken en meer die de eerste en tweede gebruiken. Niettemin, aangezien het noodzakelijk was om ook programma's met W|X JIT (vooral Chromium en Iridium) uit te voeren, werd de optie voor het mounten van een bestandssysteem 'wxallowed' toegevoegd, die het mogelijk maakte om geheugen gelijktijdig voor schrijven en uitvoering te gebruiken, indien de uitvoerbare ELF-bestanden met de marker 'wxneeded' waren gemarkeerd, en de applicaties zelf bovendien werden beschermd met behulp van mechanismen. en om de lijst van gebruikte systeemaanroepen en de delen van het bestandssysteem die voor de applicatie beschikbaar zijn, te beperken.
Om het exploiteren van kwetsbaarheden in dergelijke applicaties verder te bemoeilijken, werd een aanvulling op het mechanisme voorgesteld. , wat controleert of de systeemaanroep afkomstig is van een schrijfbare geheugenpagina. Als de pagina schrijfbaar is, wordt het proces geforceerd beƫindigd. Hierdoor kan een aanvaller geen systeemaanroepen gebruiken en zal hij gedwongen zijn om de benodigde gadgets in de JIT-implementatie te vinden of zelfs het moeilijkere werk te doen om de stubs van systeemaanroepen rechtstreeks binnen. .
De processen van Chrome/Iridium zijn redelijk goed beveiligd met pledge en unveil, maar het wegnemen van bijvoorbeeld de mogelijkheid om systeemoproepen zoals write(2) te gebruiken, heeft duidelijk enkele voordelen, omdat het extra complicaties voor de aanvaller creƫert. Het is echter ook mogelijk dat er complicaties ontstaan als de JIT-implementatie gebruikmaakt van native systeemoproepen uit W|X-geheugen. Er zijn echter redenen om te geloven dat we met dit soort problemen niet geconfronteerd hoeven te worden, aangezien de ABI meerdere keren is veranderd, maar niemand heeft ooit melding gemaakt van problemen.
De wijzigingen zijn al beschikbaar in de reguliere snapshots van de OpenBSD-CURRENT tak, iedereen die geĆÆnteresseerd is, wordt uitgenodigd voor het testen.
Theo heeft speciale opmerkingen gemaakt over het nieuws dat er een modus in Chrome/Iridium beschikbaar komt . Vanuit zijn perspectief is dit acceptabel voor sommige gebruiksmodellen, maar waarschijnlijk niet voor allemaal, aangezien de belasting voor de processor in deze modus duidelijk zal toenemen. Momenteel werkt Chrome voornamelijk als je 'wxallowed' voor /usr/local uitschakelt, al zijn er waarschijnlijk problemen met sommige extensies (ghostery wordt als voorbeeld genoemd). Hoe dan ook, Theo hoopt dat volledige werking in de JITless-modus binnenkort tot een volledig functionele staat zal worden gebracht.
Bron: opennet.ru
