Theo De Raadt planas plifortigi la W^X (Write XOR Execute) memorprotektan mekanismon. La esenco de la mekanismo estas ke procesmemorpaĝoj ne povas esti samtempe aliritaj por skribo kaj ekzekuto. Tiel, kodo povas esti efektivigita nur post kiam skribo estas malŝaltita, kaj skribi al memorpaĝo estas ebla nur post kiam ekzekuto estas malŝaltita. La W^X-mekanismo helpas protekti uzantspacaplikojn de oftaj bufrosuperfluaj atakoj, inkluzive de stakaj superfluoj, kaj estas aktiva en OpenBSD. .
De la komenco de laboro sur W^X, estis klare ke tio estis longa vojo, ĉar ekzistis signifa nombro da aplikoj uzantaj JIT. JIT-efektivigoj povas esti dividitaj en tri kategoriojn:
- Ŝanĝante memoron inter W kaj X-ŝtatoj, akceptante la "koston" de la sistemvoko .
- Kreante kaŝnomojn inter paro de W kaj X-mapadoj de la sama memoro.
- La plej "malpura" opcio postulas modelon de memoro W|X, kiu permesas samtempan registradon kaj ekzekuton.
Nuntempe, estas signife malpli da programoj uzantaj la trian opcion kaj pli uzantaj la unuan kaj la duan. Tamen, ĉar estis necese ruli programojn kun W|X JIT (ĉefe Chromium kaj Iridum), "wxallowed" dosiersistemo munta opcio estis aldonita, kio permesis al memoro esti uzata samtempe por kaj skribo kaj ekzekuto, en la okazo se la rulebla ELF. dosiero estas markita per la markilo "wxneeded", kaj la aplikaĵoj mem estis aldone protektitaj per mekanismoj и limigi la liston de sistemvokoj uzataj kaj partoj de la dosiersistemo disponeblaj al la aplikaĵo, respektive.
Por plue malfaciligi la ekspluaton de vundeblecoj en tiaj aplikoj, aldono al la mekanismo estas proponita , kiu kontrolas ĉu la sistemvoko estas ekzekutita de skribebla memorpaĝo. Se la paĝo estas skribebla, la procezo estas devigita finiĝi. Tiel, atakanto ne povos ekspluati sistemajn vokojn kaj estos devigita provi trovi la necesajn aparatojn en la efektivigo de JIT aŭ eĉ fari la pli malfacilan laboron detekti sistemajn alvokojn rekte enen. .
Chrome/Iridium-procezoj jam estas sufiĉe fidinde protektataj per promeso kaj malkovro, sed forigi la kapablon uzi, ekzemple, la skrib(2) sistemvoko evidente havas iun avantaĝon, ĉar ĝi kreas pliajn malfacilaĵojn por la atakanto. Tamen, malfacilaĵoj ankaŭ povas ekesti se la JIT-efektivigo uzas indiĝenajn sistemvokojn de W|X-memoro. Tamen, estas kialo por esperi, ke tio ne estos la kazo, ĉar la ABI estis ŝanĝita plurajn fojojn, sed neniu iam raportis problemojn.
La ŝanĝoj jam haveblas en regulaj momentfotoj de la OpenBSD-Nuna branĉo, ĉiuj interesatoj estas invitataj testi.
Rilata novaĵo pri la apero de la reĝimo en Chrome/Iridium meritas apartan komenton de Theo . Laŭ lia vidpunkto, ĉi tio estas akceptebla por iuj uzmodeloj, sed verŝajne ne por ĉiuj, ĉar ĉi tiu reĝimo evidente pliigos la ŝarĝon sur la procesoro. Nuntempe, Chrome plejparte funkcios se vi malŝaltas "wxallowed" por /usr/local, kvankam povas esti problemoj kun kelkaj etendaĵoj (fantomo estas ekzemplo). Unumaniere aŭ alie, Theo esperas, ke plenrajta laboro en JITless-reĝimo estos alportita al plene funkcia stato en proksima estonteco.
fonto: opennet.ru