Theo De Raadt is van plan om het W^X (Write XOR Execute) geheugenbeschermingsmechanisme te versterken. De essentie van het mechanisme is dat procesgeheugenpagina's niet tegelijkertijd toegankelijk zijn voor schrijven en uitvoeren. Code kan dus alleen worden uitgevoerd nadat het schrijven is uitgeschakeld, en schrijven naar een geheugenpagina is alleen mogelijk nadat de uitvoering is uitgeschakeld. Het W^X-mechanisme helpt toepassingen in de gebruikersruimte te beschermen tegen algemene buffer-overflow-aanvallen, inclusief stack-overflows, en is actief in OpenBSD .
Vanaf het begin van de werkzaamheden aan W^X was het duidelijk dat dit een lange weg was, aangezien er een aanzienlijk aantal toepassingen was die JIT gebruikten. JIT-implementaties kunnen worden onderverdeeld in drie categorieën:
- Het geheugen schakelen tussen de W- en X-status, waarbij de “kosten” van de systeemoproep worden geaccepteerd .
- Aliassen creëren tussen een paar W- en X-toewijzingen van hetzelfde geheugen.
- De meest “vuile” optie vereist een W|X-geheugenmodel dat gelijktijdige opname en uitvoering mogelijk maakt.
Momenteel zijn er aanzienlijk minder programma's die de derde optie gebruiken en meer die de eerste en tweede gebruiken. Omdat het echter nodig was om programma's uit te voeren met W|X JIT (voornamelijk Chromium en Iridum), werd een "wxallowed" mount-optie voor het bestandssysteem toegevoegd, waardoor het geheugen gelijktijdig kon worden gebruikt voor schrijven en uitvoeren, voor het geval dat het uitvoerbare ELF bestand is gemarkeerd met de markering “wxneeded” en de applicaties zelf zijn bovendien beschermd met behulp van mechanismen и om respectievelijk de lijst met gebruikte systeemaanroepen en delen van het bestandssysteem die beschikbaar zijn voor de toepassing te beperken.
Om de exploitatie van kwetsbaarheden in dergelijke applicaties verder te compliceren, wordt een aanvulling op het mechanisme voorgesteld , die controleert of de systeemaanroep wordt uitgevoerd vanaf een beschrijfbare geheugenpagina. Als de pagina beschrijfbaar is, wordt het proces gedwongen beëindigd. Op deze manier zal een aanvaller geen misbruik kunnen maken van systeemoproepen en zal hij gedwongen worden om te proberen de benodigde gadgets in de JIT-implementatie te vinden of zelfs het moeilijkere werk uit te voeren door systeemoproepen rechtstreeks in het systeem te detecteren. .
Chrome/Iridium-processen zijn al behoorlijk betrouwbaar beschermd met behulp van belofte en onthulling, maar het verwijderen van de mogelijkheid om bijvoorbeeld de write(2)-systeemaanroep te gebruiken heeft duidelijk een voordeel, omdat het extra problemen voor de aanvaller creëert. Er kunnen zich echter ook problemen voordoen als de JIT-implementatie native systeemaanroepen uit het W|X-geheugen gebruikt. Er is echter reden om te hopen dat dit niet het geval zal zijn, aangezien de ABI meerdere keren is gewijzigd, maar niemand ooit problemen heeft gemeld.
De veranderingen zijn al beschikbaar in reguliere snapshots van de OpenBSD-Current branch; iedereen die geïnteresseerd is, wordt uitgenodigd om deze te testen.
Gerelateerd nieuws over het verschijnen van de modus in Chrome/Iridium verdient een apart commentaar van Theo . Vanuit zijn standpunt is dit acceptabel voor sommige gebruiksmodellen, maar waarschijnlijk niet voor alle, aangezien deze modus uiteraard de belasting van de processor zal verhogen. Momenteel zal Chrome vooral werken als u "wxallowed" uitschakelt voor /usr/local, hoewel er met sommige extensies problemen kunnen optreden (ghostery is een voorbeeld). Hoe dan ook hoopt Theo dat volwaardig werk in de JITless-modus in de nabije toekomst naar een volledig operationele staat zal worden gebracht.
Bron: opennet.ru