Planet për përmirësimin e mekanizmit të mbrojtjes W^X në OpenBSD

Theo De Raadt ndau planet për forcimin e mekanizmit të mbrojtjes së memories W^X (Write XOR Execute). Thelbi i mekanizmit është se faqet e memories së procesit nuk mund të jenë njëkohësisht të aksesueshme për shkrim dhe ekzekutim. Kështu, kodi mund të ekzekutohet vetëm pas ndalimit të shkrimit, dhe shkrimi në faqe të memories është i mundur vetëm pas ndalimit të ekzekutimit. Mekanizmi W^X ndihmon në mbrojtjen e aplikacioneve në hapësirën e përdoruesit nga sulmet tipike që kryhen përmes mbushjes së tamponëve, përfshirë mbushjet e stack-ut dhe është aktiv në OpenBSD në mënyrë default.

Që në fillim të punës mbi W^X, ishte e qartë se kjo është 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:

• Ndryshimi i memories midis gjendjeve W dhe X, duke pranuar 'koston' e thirrjes së sistemit mprotect.
• Krijimi i aliasëve midis një çifti W dhe X të kartelave të memories së njëjtë.
• Variantet më 'të pisët' - ato që kërkojnë modelin e memories W|X, duke lejuar njëkohësisht shkrimin dhe ekzekutimin.

Aktualisht ka një numër të konsiderueshëm më të vogël programesh që përdorin variantin e tretë dhe më shumë që përdorin të parin dhe të dytin. Megjithatë, pasi ishte e nevojshme të ekzekutoheshin edhe programet me W|X JIT (kryesisht, Chromium dhe Iridium), u shtua opsioni i montimit të sistemit të skedarëve 'wxallowed', i cili lejonte përdorimin e memories për shkrim dhe ekzekutim njëkohësisht, në rast se skedari ekzekutues ELF shënohej me markerin 'wxneeded', dhe aplikacionet vetë mbronin më tej, duke përdorur mekanizmat pledge dhe unveil për të kufizuar listën e thirrjeve të sistemit të përdorura dhe pjesët e sistemit të skedarëve të aksesueshme për aplikacionin përkatës.

Për të komplikuar më tej shfrytëzimin e vulnerabiliteteve në aplikacione të tilla, është propozuar një shtesë e mekanizmit MAP_STACK, e cila kontrollon nëse thirrja e sistemit kryhet nga një faqe memory e aksesueshme për shkrim. Nëse faqja është e aksesueshme për shkrim, procesi përfundohet me forcë. Kështu, një sulmues nuk do të jetë në gjendje të përdorë thirrjet e sistemit dhe do të jetë i detyruar të provojë të gjejë gjysmë-pjesët e nevojshme në zbatimin e JIT ose madje të kryejë punë më të vështirë për të zbuluar zëvendësimet e thirrjeve të sistemit drejtpërdrejt brenda libc gjithashtu të lidhur rastësisht.

Proceset Chrome/Iridium janë mjaft të mbrojtura me ndihmën e pledge dhe unveil, por ndalimi i përdorimit, për shembull, të thirrjes së sistemit write(2), ka disa përfitime, pasi krijon vështirësi shtesë për sulmuesin. Megjithatë, vështirësitë mund të shfaqen edhe në rast se zbatimi i JIT përdor thirrjet natyrale të sistemit nga memoria W|X. Megjithatë, ka arsye për të shpresuar që me një gjë të tillë nuk do të përballemi, pasi ABI ka ndryshuar shpesh, por askush nuk ka raportuar ndonjëherë për probleme.

Ndryshimet tashmë janë të disponueshme në snapshotet e rregullta të degës OpenBSD-CURRENT, të gjithë ata që janë të interesuar ftohen të testojnë.

Një koment i veçantë nga Theo meritohet edhe lidhur me lajmet mbi shfaqjen në Chrome/Iridium të modit JITless. Nga perspectiva e tij, kjo është e pranueshme për disa modele përdorimi, megjithatë, ndoshta jo për të gjithë, pasi në këtë mod kostoja për procesorin do të rritet qartazi. Tani Chrome do të funksionojë kryesisht nëse 'wxallowed' është çaktivizuar për /usr/local, megjithëse priten probleme me disa shtesa (vini re ghostery si shembull). Në çdo rast, Theo shpreson që funksionimi i plotë në modin JITless do të arrijë të stabilizohet plotësisht në një të ardhme të afërt.

Burimi: opennet.ru