Планови за јачање ОпенБСД-овог В^Кс безбедносног механизма

Тхео Де Радт поделио планира да ојача механизам заштите меморије В^Кс (Врите КСОР Екецуте). Суштина механизма је да се страницама процесне меморије не може истовремено приступити за писање и извршење. Дакле, код се може извршити тек након што је уписивање онемогућено, а писање на меморијску страницу могуће је тек након што је извршење онемогућено. Механизам В^Кс помаже у заштити апликација корисничког простора од уобичајених напада прекорачења бафера, укључујући прекорачење стека, и активан је у ОпенБСД-у подразумевано.

Од почетка рада на В^Кс, било је јасно да је ово дуг пут, пошто је постојао значајан број апликација које користе ЈИТ. ЈИТ имплементације се могу поделити у три категорије:

  • Пребацивање меморије између В и Кс стања, прихватање „трошка“ системског позива мппротецт.
  • Креирање алијаса између пара В и Кс мапирања исте меморије.
  • Најпрљавија опција је она за коју је потребан В|Кс меморијски модел који омогућава истовремено снимање и извршавање.

Тренутно постоји знатно мање програма који користе трећу опцију и више који користе прву и другу. Међутим, пошто је било неопходно покретати програме са В|Кс ЈИТ-ом (углавном Цхромиум и Иридум), додата је опција монтирања система датотека „вкалловед“, која је омогућавала да се меморија користи истовремено и за писање и за извршавање, у случају да извршни ЕЛФ датотека је означена маркером „вкнеедед“, а саме апликације су додатно заштићене помоћу механизама залога и унвеил да ограничите листу коришћених системских позива и делова система датотека доступних апликацији, респективно.

Да би се додатно закомпликовало искоришћавање рањивости у таквим апликацијама, предложен је додатак механизму МАП_СТАЦК, који проверава да ли се системски позив извршава са меморијске странице на коју се може писати. Ако се на страницу може писати, процес се мора прекинути. На овај начин, нападач неће моћи да искористи системске позиве и биће приморан да покуша да пронађе потребне гаџете у ЈИТ имплементацији, или чак да уради тежи посао откривања стубова системског позива директно унутар случајно повезан либц.

Цхроме/Иридиум процеси су већ прилично поуздано заштићени коришћењем пледге анд унвеил-а, али уклањање могућности коришћења, на пример, врите(2) системског позива очигледно има неку предност, јер ствара додатне потешкоће за нападача. Међутим, потешкоће такође могу настати ако ЈИТ имплементација користи изворне системске позиве из В|Кс меморије. Међутим, постоји разлог за наду да то неће бити случај, пошто је АБИ неколико пута мењан, али нико никада није пријавио проблеме.

Промене су већ доступне у редовним снимцима ОпенБСД-Цуррент гране, сви заинтересовани су позвани да тестирају.

Повезане вести о изгледу режима у Цхроме/Иридиум-у заслужују посебан коментар Теа ЈИТлесс. Са његове тачке гледишта, ово је прихватљиво за неке моделе употребе, али вероватно не за све, јер ће овај режим очигледно повећати оптерећење процесора. Тренутно, Цхроме ће углавном радити ако онемогућите „вкалловед“ за /уср/лоцал, иако може бити проблема са неким екстензијама (пример је гхостери). На овај или онај начин, Тео се нада да ће пуноправни рад у ЈИТлесс режиму бити доведен у потпуно оперативно стање у блиској будућности.

Извор: опеннет.ру

Додај коментар