Cynlluniau i gryfhau'r mecanwaith diogelwch W^X yn OpenBSD

Theo De Raadt wedi'i rannu cynlluniau i gryfhau'r mecanwaith diogelu cof W^X (Write XOR Execute). Hanfod y mecanwaith yw na ellir cyrchu tudalennau cof proses ar yr un pryd ar gyfer ysgrifennu a gweithredu. Felly, dim ond ar ôl i'r ysgrifen gael ei hanalluogi y gellir gweithredu'r cod, a dim ond ar ôl i'r weithred gael ei hanalluogi y gellir ysgrifennu at dudalen cof. Mae'r mecanwaith W^X yn helpu i amddiffyn cymwysiadau gofod defnyddwyr rhag ymosodiadau gorlif byffer cyffredin, gan gynnwys gorlifau stac, ac mae'n weithredol yn OpenBSD yn ddiofyn.

O ddechrau'r gwaith ar W^X, roedd yn amlwg bod hon yn ffordd hir, gan fod nifer sylweddol o geisiadau yn defnyddio JIT. Gellir rhannu gweithrediadau JIT yn dri chategori:

  • Mae newid cof rhwng cyflwr W ac X, gan dderbyn “cost” galwad system mprotect.
  • Creu arallenwau rhwng pâr o fapiau W ac X o'r un cof.
  • Yr opsiwn mwyaf “budr” yw'r rhai sydd angen model cof W | X sy'n caniatáu recordio a gweithredu ar yr un pryd.

Ar hyn o bryd, mae llawer llai o raglenni'n defnyddio'r trydydd opsiwn a mwy yn defnyddio'r cyntaf a'r ail. Fodd bynnag, gan fod angen rhedeg rhaglenni gyda W | X JIT (Chromium ac Iridum yn bennaf), ychwanegwyd opsiwn gosod system ffeiliau "wxallowed", a oedd yn caniatáu defnyddio cof ar yr un pryd ar gyfer ysgrifennu a gweithredu, rhag ofn y byddai'r ELF gweithredadwy. mae'r ffeil wedi'i marcio â'r marciwr “wxneeded”, a chafodd y cymwysiadau eu hunain eu diogelu hefyd gan ddefnyddio mecanweithiau addewid и dadorchuddio i gyfyngu ar y rhestr o alwadau system a ddefnyddir a rhannau o'r system ffeiliau sydd ar gael i'r rhaglen, yn y drefn honno.

Er mwyn cymhlethu ymhellach y defnydd o wendidau mewn cymwysiadau o'r fath, cynigir ychwanegiad at y mecanwaith MAP_STACK, sy'n gwirio a yw'r alwad system yn cael ei gweithredu o dudalen cof ysgrifenadwy. Os yw'r dudalen yn ysgrifenadwy, mae'r broses yn cael ei gorfodi i derfynu. Fel hyn, ni fydd ymosodwr yn gallu ecsbloetio galwadau system a bydd yn cael ei orfodi i geisio dod o hyd i'r teclynnau angenrheidiol wrth weithredu JIT neu hyd yn oed wneud y gwaith anoddach o ganfod bonion galwadau system yn uniongyrchol y tu mewn. libc sy'n gysylltiedig yn ddamweiniol.

Mae prosesau Chrome / Iridium eisoes wedi'u diogelu'n eithaf dibynadwy gan ddefnyddio addewid a dadorchuddio, ond mae dileu'r gallu i ddefnyddio, er enghraifft, mae'n amlwg bod gan alwad system ysgrifennu (2) rywfaint o fantais, gan ei fod yn creu anawsterau ychwanegol i'r ymosodwr. Fodd bynnag, gall anawsterau godi hefyd os yw gweithrediad JIT yn defnyddio galwadau system frodorol o gof W|X. Fodd bynnag, mae lle i obeithio na fydd hyn yn wir, gan fod yr ABI wedi'i newid sawl gwaith, ond nid oes neb erioed wedi adrodd am broblemau.

Mae'r newidiadau eisoes ar gael mewn cipluniau rheolaidd o'r gangen OpenBSD-Current, gwahoddir pawb sydd â diddordeb i brofi.

Mae newyddion cysylltiedig am ymddangosiad y modd yn Chrome / Iridium yn haeddu sylw ar wahân gan Theo JITless. O'i safbwynt ef, mae hyn yn dderbyniol ar gyfer rhai modelau defnydd, ond mae'n debyg nid i bawb, gan y bydd y modd hwn yn amlwg yn cynyddu'r llwyth ar y prosesydd. Ar hyn o bryd, bydd Chrome yn gweithio'n bennaf os byddwch yn analluogi "wxallowed" ar gyfer /usr/local, er y gallai fod problemau gyda rhai estyniadau (mae gostery yn enghraifft). Un ffordd neu'r llall, mae Theo yn gobeithio y bydd gwaith llawn yn y modd JITless yn dod i gyflwr cwbl weithredol yn y dyfodol agos.

Ffynhonnell: opennet.ru

Ychwanegu sylw