Theo de Raadt planet për forcimin e mekanizmit të mbrojtjes së memories W^X (Write XOR Execute). Thelbi i këtij mekanizmi është që faqet e memories së procesit nuk mund të jenë njëkohësisht të qasshme për shkrim dhe ekzekutim. Kështu, kodi mund të ekzekutohet vetëm pasi të ndalohet shkrimi, ndërsa shkrimi në një faqe memorieje është i mundur vetëm pasi të ndalohet ekzekutimi. Mekanizmi W^X ndihmon në mbrojtjen e aplikacioneve në hapësirën e përdoruesit nga sulmet tipike të kryera përmes mbushjes së buffer-it, përfshirë mbushjen e stack-ut, dhe është aktiv në OpenBSD .
Që nga fillimi i punës mbi W^X ishte e qartë se kjo do të ishte një rrugë e gjatë, pasi ekziston një numër i konsiderueshëm aplikacionesh që përdorin JIT. Zbatimet e JIT mund të ndahen në tri kategori:
- Ato qĂ« e kalojnĂ« memorien mes gjendjeve W dhe X, duke pranuar âkostonâ e thirrjes sĂ« sistemit .
- Ato që krijojnë pseudonime midis një çifti hartëzimesh W dhe X të së njëjtës memorie.
- Varianti mĂ« âi pistĂ«â Ă«shtĂ« ai qĂ« kĂ«rkon modelin e memories W|X, i cili lejon njĂ«kohĂ«sisht shkrimin dhe ekzekutimin.
Aktualisht ka dukshëm më pak programe që përdorin variantin e tretë dhe më shumë që përdorin të parin dhe të dytin. Megjithatë, meqë ishte e nevojshme të ekzekutoheshin edhe programe me W|X JIT (kryesisht Chromium dhe Iridum), u shtua opsioni i montimit të sistemit të skedarëve «wxallowed», i cili lejonte përdorimin e memories njëkohësisht për shkrim dhe ekzekutim nëse skedari ELF i ekzekutueshëm ishte shënuar me markerin «wxneeded», ndërsa vetë aplikacionet mbroheshin shtesë duke përdorur mekanizmat dhe për të kufizuar përkatësisht listën e thirrjeve të sistemit që përdoren dhe pjesët e sistemit të skedarëve të qasshme për aplikacionin.
Për ta vështirësuar më tej shfrytëzimin e cenueshmërive në aplikacione të tilla, është propozuar një shtesë e mekanizmit , e cila kontrollon nëse thirrja e sistemit po ekzekutohet nga një faqe memorieje e qasshme për shkrim. Nëse faqja është e qasshme për shkrim, procesi përfundon me forcë. Kështu, një sulmues nuk do të mund të përdorë thirrje sistemi dhe do të detyrohet të përpiqet të gjejë gadget-et e nevojshme në zbatimin e JIT ose madje të bëjë punën edhe më të vështirë të zbulimit të stub-eve të thirrjeve të sistemit drejtpërdrejt brenda .
Proceset e Chrome/Iridium tashmë janë të mbrojtura mjaftueshëm në mënyrë të besueshme me pledge dhe unveil, por heqja e mundësisë për të përdorur, për shembull, thirrjen e sistemit write(2), padyshim ka një përparësi të caktuar, pasi i krijon vështirësi shtesë sulmuesit. Megjithatë, vështirësi mund të shfaqen edhe nëse implementimi i JIT përdor thirrje natyrore të sistemit nga memoria W|X. Sidoqoftë, ka arsye për të shpresuar se nuk do të përballemi me diçka të tillë, pasi ABI ka ndryshuar disa herë, por askush nuk ka raportuar ndonjëherë probleme.
Ndryshimet tashmĂ« janĂ« tĂ« disponueshme nĂ« snapshot-et e rregullta tĂ« degĂ«s OpenBSD-Current dhe tĂ« gjithĂ« tĂ« interesuarit ftohen tâi testojnĂ«.
Theo bëri gjithashtu një koment të veçantë për lajmet lidhur me shfaqjen në Chrome/Iridium të modalitetit . Sipas tij, kjo është e pranueshme për disa modele përdorimi, por ndoshta jo për të gjitha, pasi në këtë regjim ngarkesa mbi procesorin do të rritet dukshëm. Aktualisht, Chrome në përgjithësi do të funksionojë nëse çaktivizohet «wxallowed» për /usr/local, megjithëse janë të mundshme probleme me disa zgjerime (si shembull përmendet ghostery). Sido që të jetë, Theo shpreson që funksionimi i plotë në modalitetin JITless të sillet në një gjendje plotësisht funksionale në të ardhmen e afërt.
Burimi: opennet.ru
