Гоогле-ов пројекат Зеро открио је како да заобиђе Самсунгов Кнок хипервизор (поправљен у јануарској закрпи)

click fraud protection

У најновијем блог посту Пројецт Зеро, тим је открио начин да заобиђе Самсунгову заштиту кернела у реалном времену, названу Кнок Хипервисор.

Гооглеов Пројецт Зеро тим је верификовао бројне експлоатације које омогућавају нападе на Самсунгове телефоне који користе наводно безбедни Самсунг Кнок безбедносни пакет. Блог напомиње да су све рањивости прослеђене Самсунгу који је заправо објавио исправке за њих у јануарском ажурирању софтвера.


Позадина

Као део безбедносног софтвера Самсунг Кнок који је представио Самсунг, постоји део софтвера који се налази између Андроид апликација и кернела који се зове Хипервизор. Ово се може користити као додатни слој за даље осигурање Андроид уређаја. Самсунг Кнок хипервизор се зове "Заштита кернела у реалном времену“ или скраћено РКП, како ћу га референцирати у наставку овог чланка.

Кернел се налази испод РКП-а у Андроид софтверском стогу, а апликације које се покрећу на уређају се налазе на врху. Идеја иза РКП-а је да обезбеди додатни ниво безбедности за уређај пошто сви захтеви (меморија и други ресурси) буду апликације до кернела морају прво да прођу кроз Кнок, који покушава да открије да ли апликација нешто ради не би требало. РКП такође обезбеђује сигурност кроз нејасност са додатним слојем за сакривање осетљивих информација које би апликација могла да користи да угрози уређај.

Пост на блогу иде прилично дубоко у то како Андроид меморија, РКП и оперативни системи уопште функционишу, тако да сам га сажето и поједноставио да дам брзи преглед онога што је откривено. Охрабрујем вас да прочитате цео чланак ако имате времена, јер је веома просветљујући.


Експлоатација #1:

КАСЛР или Рандомизација адресног простора језгра је процес промене локације кода кернела у меморији насумичном количином при покретању. Сваки пут када се уређај покрене, кернел се учитава у други адресни простор (област у меморији). Идеја је да се отежа проналажење где се налази код кернела да би се напао јер се после сваког покретања код кернела „помера“ за насумични износ у меморији. Ово звучи као одличан корак за спречавање потенцијалних нападача, али недавно истраживања је показао да ово заправо можете победити без потребе за софтверском грешком или рањивости, јер је КАСЛР заправо веома тешко имплементирати на робустан начин против локалних нападача.

У случају РКП софтвера, могућност заобилажења КАСЛР-а је заправо једноставнија од истраживања које је горе наведено. Меморија свих андроид уређаја је референцирана показивачима и како би се уређаји заштитили од напада, кад год андроид уређаји штампају или излазе (било да се приказују на екрану или датотеке за евиденцију или отклањање грешака), референце показивача су анонимизоване, што онемогућава да се открије где показивач заправо показује када читате излаз.

Замислите меморијске показиваче као улични знак који указује на локацију и замислите да анонимизација то замагљује. Слично као на телевизији, анонимизација се ради након снимања, Андроид такође примењује ову анонимизацију у време излаза и само ако је анонимизација исправно конфигурисана, а аутор наводи да је сваки уређај са којим се сусрео имао исправно конфигурисану анонимизацију показивача. Ово може звучати као да је веома тешко разбити, али све што треба да урадите је да пронађете један показивач (мислите на улични знак) који није био анониман (замагљен) програмер кернела (пазите да ово није ваш просечан програмер Андроид апликације) када је показивач уписан у евиденцију или другу локацију, нпр. екран или а фајл.

Дакле, ако можете пронаћи показивач који није био анониман, онда можете израчунати случајни помак адресе језгра као разлику између њих. Занимљиво је да аутор није могао да пронађе показивач који се може искористити у кернелу, али га је нашао унутар РПК-а где су програмери заборавили да анонимизирају показивач у излазу за отклањање грешака (записивање дневника), до чега је дошло путем типо. Да бисте анонимизирали показиваче у Андроиду, морате користити посебан код и испоставило се да су програмери РПК грешком користили мала слова 'к' уместо ан велико слово 'К'. Стога је било релативно једноставно открити количину случајног померања кода кернела и напасти га.


Експлоатација #2:

Следећи подвиг је мало сложенији: Самсунг Кнок штити ваш уређај применом скупа правила на меморију уређаја како би зауставио злонамерни код. Правила су следећа:

  1. Све странице (код у меморији), са изузетком кода кернела, означене су као „Привилеговано никада не извршавај“ (што значи да се код овде никада не може покренути)
  2. Странице са подацима кернела (подаци које програм користи у меморији) никада нису означени као извршни (тако да се код овде никада не може покренути)
  3. Кодне странице кернела (код у меморији) никада нису означене за писање (тако да их ниједан злонамерни код не може променити)
  4. Све странице кернела су означене као само за читање у табели превода фазе 2 (табела која се налази између апликације и кернела како би се додатно спречило да апликације знају о стварним меморијским локацијама)
  5. Сви уноси за превод меморије су означени као само за читање за апликације.

Фокусираћемо се на правило 3 јер је овде аутор пронашао проблем са применом горе наведених правила. РПК заправо означава меморију за кернел као само за читање, међутим као превид КАСЛ-а откривена је рупа, што је довело до уписивање кода у наводно одељак „само за читање“.. Да би се прикрила локација језгра у време покретања, меморија се додељује кернелу, али ова количина меморије је много већа од текстуалног сегмента језгра. Додељивањем веће количине меморије много је теже пронаћи стварни код кернела који би могао бити било где, а као што смо видели изнад, помера се насумично при сваком покретању уређаја.

_тект и _етект означавају заштићени опсег

Аутор је успео да потврди да је меморија коју користи кернел заиста означена као „само за читање“, међутим остатак те велике количине меморије која се користи за скривање кернела је не означено као „само за читање“. То је зато што РКП штити само регион који садржи текст кернела након примене КАСЛР слајда.


Експлоатација #3

У трећем експлоатацији аутор је могао да приступи другој области меморије која би такође требало да буде ограничена на само читање. РКП штити меморију и користи а Регистар конфигурације хипервизора (ХЦР) за контролу кључних операција кернела. Сврха ХЦР-а је да дозволи валидним и стварним операцијама кернела да приступе регистрима и блокирају злонамерне нападе. То ради провером позива упућених регистрима који управљају функцијама виртуелизације. ХЦР је конфигурисан да блокира специфичне операције којима би се нормално руковало омогућавајући РКП-у да одабере да ли ће дозволити или забранити захтев.

У овом експлоатацији ХЦР контрола је била не покривајући два регистра то се показало веома важним. Аутор је дубоко закопао у АРМ Референце приручник и открио да му је први регистар омогућио да у суштини искључи РКП за апликације. "Системски контролни регистар за ЕЛ1 (СЦТЛР_ЕЛ1) обезбеђује контролу највишег нивоа над системом, укључујући меморијски систем." У савршеном свету апликација би користила меморију која је мапирана преко РКП-а тако да РКП може да контролише чему апликација може да приступи. Међутим, искључивање овог регистра омогућило је РКП бити онемогућен ефективним враћањем уређаја на начин на који је радио пре инсталирања РКП-а – што значи да је уређај мапиран у физичку меморију без додатне безбедности коју обезбеђује РКП. То је заузврат значило да је аутор могао да чита и пише у меморију коју је првобитно и исправно блокирао РКП софтвер.

Други регистар који је пропуштен имао је суптилнији утицај, али на крају једнако разоран по безбедност. Тхе Регистар контроле превода за ЕЛ1 (ТЦР_ЕЛ1) регистар се директно односи на количину меморије са којом апликација ради која се зове страница. РКП је чврсто кодиран на величину странице од 4 кб јер ААРЦХ64 Линук кернели (као што је Андроид) користе величину превода од 4 КБ. Регистар у питању (ТЦР_ЕЛ1) поставља АРМ чипсетове на величину меморије која треба да се врати. Испада да овај регистар није заштићен од стране ХЦР и стога га нападач може променити као што га је аутор променио на величину странице од 64 кб.

Ово значи да када РКП испуни захтев, стварна количина доступне меморије сада износи 64 кб уместо 4 кб. Разлог је тај што АРМ чипсет и даље контролише величину странице и експлоатацијом је постављена на 64 кб. Пошто РКП штити меморију од уписивања, као део правила наведених у експлоатацији #2, меморија је и даље заштићена. Али овде је квака - пошто је РКП тврдо кодиран на 4 кб, не мења се на величину странице од 64 кб када је регистар ажуриран, тако да заштићено је само првих 4 кб меморије дозвољавајући нападачу да уради шта год хоће са преосталих 60кб.


Експлоатација #4

Последњи експлоат који аутор показује је упућивање на меморију где се налази РКП софтвер, како би нападач могао да нападне сам РКП софтвер. Један трик за заустављање ове врсте напада који користе и Линук кернели је уклањање мапе вашег програма из адресног простора виртуелне меморије тако да ниједна апликација не може да га нападне јер не може да га референцира.

Запамтите да је меморија све о показивачима и табелама које пресликавају физичку меморију у виртуелну меморију. У складу са нормалном одбраном у овој врсти напада, РКП се демапира тако да не може бити нападнут. Међутим, тамо где кернел не пружа такве могућности, РКП дозвољава да се део меморије мапира и означи као читање/писање. Једина провера је да то није само основно језгро јер РКП не проверава да ли су адресе за које се захтева мапирање област у којој се сам РКП налази у меморији. У основи, РКП дозвољава да се поново мапира назад у адресни простор коме апликације могу да приступе и као споредан утицај на меморија се аутоматски означава као Реад/Врите тако да нападач сада може да користи меморију како год жели.


Закључак

Један од највећих проблема са четири горе наведена експлоатација је то што аутор помиње колико би их било тешко извести због недостатка функција у основном Андроид кернелу. Иронично, сигуран РКП хипервизор је обезбедио све алате који су били потребни за извођење напада. То показује да понекад добронамерни софтвер изазива више проблема него што решава и срећни смо што имамо људе као Гал Бениамини који је спреман да упрља руке и тестира да ли документација одговара ономе што софтвер заправо ради.

Иако ови подвизи изгледају застрашујуће и чине да Кнок звучи веома рањиво, желео бих да уверим све да су сви ови проблеми поправљено у јануарском ажурирању од Самсунг-а. Штавише, ови експлоати захтевају веома дубоко разумевање АРМ процесора и програмирања, тако да је баријера за улазак у коришћење ових експлоата астрономски висока.


Извор: Пројекат Зеро