Theo De Raadt beplan om die W^X (Write XOR Execute) geheuebeskermingsmeganisme te versterk. Die essensie van die meganisme is dat prosesgeheuebladsye nie gelyktydig vir skryf en uitvoering verkry kan word nie. Kode kan dus slegs uitgevoer word nadat skryf gedeaktiveer is, en skryf na 'n geheuebladsy is slegs moontlik nadat uitvoering gedeaktiveer is. Die W^X-meganisme help om gebruikersruimte-toepassings te beskerm teen algemene buffer-oorloop-aanvalle, insluitend stapeloorvloei, en is aktief in OpenBSD .
Van die begin van werk aan W^X was dit duidelik dat dit 'n lang pad was, aangesien daar 'n aansienlike aantal toepassings was wat JIT gebruik. JIT-implementerings kan in drie kategorieë verdeel word:
- Skakel geheue tussen W- en X-toestande, aanvaarding van die "koste" van die stelseloproep .
- Die skep van aliasse tussen 'n paar W- en X-afbeeldings van dieselfde geheue.
- Die mees "vuil" opsie vereis 'n W|X geheue model wat gelyktydige opname en uitvoering moontlik maak.
Tans is daar aansienlik minder programme wat die derde opsie gebruik en meer wat die eerste en tweede gebruik. Aangesien dit egter nodig was om programme met W|X JIT (hoofsaaklik Chromium en Iridum) te laat loop, is 'n "wxallowed" lêerstelsel-monteeropsie bygevoeg, wat toegelaat het dat geheue gelyktydig vir beide skryf en uitvoering gebruik word, ingeval die uitvoerbare ELF lêer is gemerk met die "wxneeded" merker, en die toepassings self is addisioneel beskerm met behulp van meganismes и om onderskeidelik die lys van stelseloproepe wat gebruik word en dele van die lêerstelsel beskikbaar vir die toepassing te beperk.
Om die uitbuiting van kwesbaarhede in sulke toepassings verder te bemoeilik, word 'n toevoeging tot die meganisme voorgestel , wat kontroleer of die stelseloproep vanaf 'n skryfbare geheuebladsy uitgevoer word. As die bladsy skryfbaar is, word die proses gedwing om te beëindig. Op hierdie manier sal 'n aanvaller nie stelseloproepe kan ontgin nie en sal gedwing word om die nodige toestelle in die JIT-implementering te probeer vind of selfs die moeiliker werk te doen om stelseloproepstompies direk binne-in op te spoor. .
Chrome/Iridium-prosesse word reeds redelik betroubaar beskerm deur gebruik te maak van belofte en onthulling, maar die verwydering van die vermoë om byvoorbeeld die skryf(2)-stelseloproep te gebruik, het natuurlik 'n mate van voordeel, aangesien dit bykomende probleme vir die aanvaller skep. Probleme kan egter ook ontstaan as die JIT-implementering inheemse stelseloproepe vanaf W|X-geheue gebruik. Daar is egter rede om te hoop dat dit nie die geval sal wees nie, aangesien die ABI verskeie kere verander is, maar niemand het ooit probleme aangemeld nie.
Die veranderinge is reeds beskikbaar in gereelde kiekies van die OpenBSD-Current-tak, almal wat belangstel, word uitgenooi om te toets.
Verwante nuus oor die voorkoms van die modus in Chrome/Iridium verdien 'n aparte opmerking van Theo . Vanuit sy oogpunt is dit aanvaarbaar vir sommige gebruiksmodelle, maar waarskynlik nie vir almal nie, aangesien hierdie modus natuurlik die las op die verwerker sal verhoog. Tans sal Chrome meestal werk as jy "wxallowed" vir /usr/local deaktiveer, alhoewel daar probleme met sommige uitbreidings kan wees (ghosty is 'n voorbeeld). Op die een of ander manier hoop Theo dat volwaardige werk in JITless-modus in die nabye toekoms tot 'n ten volle operasionele toestand gebring sal word.
Bron: opennet.ru