Rencanana pikeun Nguatkeun Mékanisme Kaamanan W^X OpenBSD

Theo De Raadt dibageakeun rencana pikeun nguatkeun W ^ X (Tulis XOR Execute) mékanisme panyalindungan memori. Intina mékanisme nyaéta yén halaman mémori prosés henteu tiasa diaksés sakaligus pikeun tulisan sareng palaksanaan. Ku kituna, kodeu bisa dieksekusi ngan sanggeus tulisan ditumpurkeun, jeung nulis ka kaca memori mungkin ngan sanggeus palaksanaan ditumpurkeun. Mékanisme W^X ngabantosan ngajagi aplikasi ruang-pamaké tina serangan buffer overflow umum, kalebet tumpukan tumpukan, sareng aktip dina OpenBSD. sacara standar.

Ti mimiti gawé dina W^X, éta jelas yén ieu jalan panjang, saprak aya sajumlah signifikan aplikasi maké JIT. Palaksanaan JIT tiasa dibagi kana tilu kategori:

• Ngalihkeun mémori antara nagara W sareng X, nampi "biaya" telepon sistem mproteksi.
• Nyiptakeun landian antara sapasang pemetaan W sareng X tina mémori anu sami.
• Pilihan anu paling "kotor" butuh modél mémori W | X anu ngamungkinkeun ngarékam sareng palaksanaan sakaligus.

Ayeuna, aya langkung seueur program anu nganggo pilihan katilu sareng langkung seueur anu nganggo anu kahiji sareng kadua. Sanajan kitu, saprak éta diperlukeun pikeun ngajalankeun program kalawan W|X JIT (utamana Chromium jeung Iridum), a "wxallowed" filesystem pilihan Gunung ditambahkeun, nu diwenangkeun memori bisa dipaké sakaligus pikeun duanana tulisan jeung palaksanaan, bisi lamun ELF executable. file ditandaan ku pananda "wxneeded", sareng aplikasi sorangan ogé ditangtayungan ku mékanisme jangji и unveil pikeun ngawates daptar telepon sistem anu dianggo sareng bagian tina sistem file anu sayogi pikeun aplikasi, masing-masing.

Pikeun langkung ngahesekeun eksploitasi kerentanan dina aplikasi sapertos kitu, tambahan pikeun mékanisme diusulkeun. MAP_STACK, nu mariksa naha panggero sistem keur dieksekusi tina kaca memori ditulis. Upami halamanna tiasa ditulis, prosésna kedah ditungtungan. Ku cara ieu, panyerang moal tiasa ngeksploitasi telepon sistem sareng bakal kapaksa nyobian milarian gadget anu diperyogikeun dina palaksanaan JIT atanapi bahkan ngalakukeun pagawéan anu langkung hese pikeun ngadeteksi stub telepon sistem langsung di jero. ngahaja numbu libc.

Prosés Chrome / Iridium geus rada reliably ditangtayungan maké ikrar jeung unveil, tapi nyoplokkeun kamampuhan pikeun ngagunakeun, Contona, nulis (2) Sistim nelepon écés sababaraha kaunggulan, saprak eta nyiptakeun kasusah tambahan pikeun lawan. Nanging, kasusah ogé tiasa timbul upami palaksanaan JIT nganggo telepon sistem asli tina mémori W|X. Sanajan kitu, aya alesan pikeun ngaharepkeun yén ieu moal jadi, sabab ABI geus sababaraha kali robah, tapi teu saurang ogé kungsi dilaporkeun masalah.

Parobihan parantos sayogi dina snapshot biasa tina cabang OpenBSD-Current, sadayana anu resep diondang pikeun nguji.

Warta anu aya hubunganana ngeunaan penampilan mode dina Chrome / Iridium pantes koméntar anu misah ti Theo JITless. Ti sudut pandang-Na, ieu téh bisa ditarima keur sababaraha model pamakéan, tapi meureun teu kabeh, saprak mode ieu écés bakal ningkatkeun beban dina processor. Ayeuna, Chrome lolobana bakal tiasa dianggo upami anjeun nganonaktipkeun "wxallowed" kanggo /usr/local, sanaos aya masalah sareng sababaraha ekstensi (ghostery mangrupikeun conto). Hiji cara atanapi anu sanés, Theo ngaharepkeun yén karya pinuh dina modeu JITless bakal dibawa ka kaayaan operasional pinuh dina waktos anu caket.

sumber: opennet.ru