Стагефригхт: Експлоатација која је променила Андроид

Стагефригхт је један од најгорих експлоатација које је Андроид видео у последње време. Кликните да прочитате више о специфичностима и да знате како да се заштитите!

Једна од најјачих страна Андроид-а је првенствено његова природа отвореног кода, која омогућава заинтересованим странама да се рачвају, модификују и редистрибуирају ОС на начин који одговара њиховим посебним потребама. Али управо ова предност отвореног кода делује као мач са две оштрице када су у питању малвер и безбедност. Лакше је пронаћи и закрпити недостатке када имате пуно способних сарадника на пројекту чији је изворни код доступан бесплатно. Међутим, решавање проблема на изворном нивоу често се не претвара у решавање проблема у рукама крајњег потрошача. Као такав, Андроид није најбољи избор када је у питању избор оперативног система за потребе предузећа осетљиве на податке.

На Гоогле И/О 2014, Гоогле је дао свој први подстицај ка сигурнијем екосистему прилагођеном предузећима са лансирањем Андроид Фор Ворк програм. Андроид Фор Ворк је усвојио приступ двоструког профила за потребе предузећа, при чему су ИТ администратори могли да креирају а различите корисничке профиле за запослене – један је фокусиран на посао, а други профили остављају за личне запослене користити. Коришћењем хардверског шифровања и смерница којима управља администратор, радни и лични подаци су остали различити и безбедни. Након тога, Андроид Фор Ворк је добио више пажње у каснијим месецима, са великим фокусом на безбедност уређаја од малвера. Гугл је такође планирао да

омогућите потпуно шифровање уређаја за све уређаје који је требало да буду пуштени са Андроид Лоллипоп-ом из кутије, али је то укинуто због проблема са перформансама, а овај потез је постао опционалан за ОЕМ-ове.

Гугл за безбедним Андроидом није у потпуности Гугл дело, пошто је Самсунг одиграо прилично значајну улогу у томе путем КНОКС доприноси АОСП-у, што на крају ојачани Андроид Фор Ворк. Међутим, недавне безбедносне експлоатације и рањивости у Андроид-у указују на тежак задатак када је у питању популарност усвајања у предузећима. Случај за то је недавна рањивост Стагефригхт-а.

Садржај:

  • Шта је Стагефригхт?
  • Колико је Стагефригхт озбиљан?
  • По чему се Стагефригхт разликује од других „масовних рањивости“?
  • Дилема ажурирања
  • Андроид, Пост-Стагефригхт
  • Завршне напомене

Шта је Стагефригхт?

Једноставно речено, Стагефригхт је експлоатација која користи библиотеку кодова за репродукцију медија у Андроиду под називом либстагефригхт. Либстагефригхт мотор се користи за извршавање кода који се прима у облику злонамерног видеа путем ММС-а, тако да је за успешан напад потребан само број мобилног телефона жртве.

Контактирали смо нашег интерног стручњака, КСДА вишег признатог програмера и администратора програмера пулсер_г2 да пружи детаљније објашњење.

"Док ово пишем, експлоатација [Стагефригхт] је требало да буде објашњена на БлацкХат [Линк], иако још нема доступних слајдова или детаља о белом папиру.

Стога дајем ово објашњење више као грубу представу о томе шта се дешава, а не као веома детаљно објашњење са пуном тачношћу итд.

Постоји велики број различитих грешака које чине Стагефригхт, а ове имају свој ЦВЕ [Уобичајене рањивости и изложености] бројеви за праћење:

  • ЦВЕ-2015-1538
  • ЦВЕ-2015-1539
  • ЦВЕ-2015-3824
  • ЦВЕ-2015-3826
  • ЦВЕ-2015-3827
  • ЦВЕ-2015-3828
  • ЦВЕ-2015-3829

Нажалост, закрпе које су доступне нису директно повезане са сваким ЦВЕ-ом (као што би требало да буду), тако да ће ово бити мало неуредно за објаснити.

1. [ЦВЕ-2015-1538]

У коду за руковање МПЕГ4, код за руковање 3ГПП метаподацима (ствари које описују формат и друге додатне информације, када је видео у 3ГПП формату) греши. Није одбацио метаподатке, где су подаци били претерано велики, већ само проверавао да ли су премали. То је значило да је могуће да нападач направи „модификовану“ или „оштећену“ датотеку, која би имала дужи део метаподатака него што би требало.

Један од великих изазова у писању кода за руковање „непоузданим“ подацима (тј. од корисника или са било ког другог места ван вашег кода) је руковање подацима променљиве дужине. Видео снимци су савршен пример за то. Софтвер треба да додељује меморију динамички, у зависности од тога шта се дешава.

У овом случају, бафер се креира као показивач на неку меморију, али је дужина низа на који указује је један елемент прекратка. Метаподаци су затим прочитани у овај низ и било је могуће да последњи унос у овом низу не буде „нулл“ (или нула). Важно је да је последња ставка у низу нула, јер на тај начин софтвер говори да је низ завршен. Будући да је последња вредност била у могућности да учини последњу вредност различитом од нуле (пошто је низ потенцијално био један елемент премали), малициозни код би могао да буде прочитан од стране другог дела кода и прочитао превише података. Уместо да се заустави на крају ове вредности, могао би да настави да чита друге податке које не би требало да чита.

(Реф: ОмниРОМ Геррит)

2. [ЦВЕ-2015-1539]

Најкраћа могућа "величина" метаподатака треба да буде 6 бајтова, јер је то УТФ-16 низ. Код узима величину целобројне вредности и од ње одузима 6. Ако је ова вредност била мања од 6, одузимање би се „смањило“ и заокружило, а на крају бисмо добили веома велики број. Замислите да можете да бројите само од 0 до 65535, на пример. Ако узмете број 4 и одузмете 6, не можете ићи испод нуле. Дакле, вратите се на 65535 и бројите одатле. То се овде дешава!

Ако је примљена дужина мања од 6, то би могло довести до погрешног декодирања оквира, јер бајтсвап процес користи променљиву лен16, чија се вредност добија из прорачуна који почиње са (величина-6). Ово би могло проузроковати много већу операцију замене него што је планирано, што би променило вредности у подацима оквира на неочекиван начин.

(Реф: ОмниРОМ Геррит)

3. [ЦВЕ-2015-3824]

А биггие! Овај је гадан. Постоји управо супротно од овог последњег питања - прекорачење целог броја, где цео број може постати "превелик". Ако достигнете 65535 (на пример) и не можете да бројите више, откотрљали бисте се и ишли на 0 следеће!

Ако додељујете меморију на основу овога (што Стагефригхт ради!), на крају бисте имали премало меморије додељене у низу. Када су подаци стављени у ово, потенцијално би пребрисали неповезане податке подацима које је контролисао креатор злонамерне датотеке.

(Реф: ОмниРОМ Геррит)

4. [ЦВЕ-2015-3826]

Још један гадан! Веома сличан последњем - још једно преливање целог броја, где би низ (који се користи као бафер) био премали. Ово би омогућило да се неповезана меморија препише, што је опет лоше. Неко ко може да упише податке у меморију може да поквари друге податке који нису повезани и потенцијално их користи да би неки код који контролишу могао да покреће ваш телефон.

(Реф: ОмниРОМ Геррит)

5. [ЦВЕ-2015-3827]

Прилично сличан овим последњим. Променљива се користи када се прескаче нека меморија, а она може бити негативна током одузимања (као горе). Ово би резултирало веома великом дужином „прескакања“, прекорачењем бафера, дајући приступ меморији којој се не би требало приступити.

(Реф: ОмниРОМ Геррит)

Постоје и неке (потенцијално) повезане исправке за које изгледа да су ушле иу [Андроид] 5.1.

(Реф: ОмниРОМ Геррит)

Ово додаје провере за заустављање проблема са прошлом безбедносном исправком да би се додале провере граница, које се саме по себи могу преоптеретити. У Ц, бројеви који се могу представити као потписани инт се чувају као потписани инт. Иначе остају непромењени током рада. У овим проверама, неки цели бројеви су могли да буду потписани (уместо без предзнака), што би касније смањило њихову максималну вредност и омогућило преливање.

(Реф: ОмниРОМ Геррит)

Још неки недостаци целог броја (где су бројеви прениски, а затим се на тим бројевима врши одузимање, омогућавајући им да постану негативни). Ово опет доводи до великог броја, а не до малог, и то узрокује исте проблеме као горе.

(Реф: ОмниРОМ Геррит)

И коначно, још једно преливање целог броја. Исто као и раније, ускоро ће се користити на другом месту и може се прелити.

(Реф: ОмниРОМ Геррит)"

Колико је Стагефригхт озбиљан?

Према блог пост коју је објавила матична истраживачка компанија, Зимпериум Ресеарцх Лабс, експлоатација Стагефригхт потенцијално разоткрива 95% Андроид уређаја – отприлике 950 милиона – на ову рањивост јер утиче на уређаје који користе Андроид 2.2 и горе. Да ствар буде још гора, уређаји пре Јелли Беан-а 4.3 су у „најгорем ризику“ јер не садрже адекватна средства за ублажавање ове експлоатације.

Што се тиче штете коју би Стагефригхт могао да нанесе, пулсер_г2 је приметио:

[блоцккуоте аутхор="пулсер_г2"]"Сама по себи, Стагефригхт би дао приступ кориснику система на телефону. Ипак, морали бисте да заобиђете АСЛР (рандомизацију распореда адресног простора) да бисте га заиста злоупотребили. За сада се не зна да ли је то постигнуто или не. Ова експлоатација омогућава покретање „произвољног кода“ на вашем уређају као корисник система или медија. Они имају приступ звуку и камери на уређају, а корисник система је одлично место за покретање роот експлоатације. Сећате ли се свих невероватних рут експлоата које сте користили за рутовање свог телефона?

Они би се потенцијално могли тихо користити за добијање роот-а на вашем уређају! Онај ко има роот поседује телефон. Морали би да заобиђу СЕЛинук, али ТовелРоот је то успео, а успео је и ПингПонг. Када добију роот, све на вашем телефону је отворено за њих. Поруке, кључеви итд."[/блоцккуоте]Говорећи о најгорим сценаријима, потребан је само ММС за испоруку кода и покретање овог експлоатације. Корисник не мора чак ни да отвори поруку јер многе апликације за размену порука унапред обрађују ММС пре него што корисник ступи у интеракцију са њим. Ово се разликује од напада пхисхинг-ом јер би корисник могао бити потпуно несвестан успешног напада, компромитујући све садашње и будуће податке у телефону.

По чему се Стагефригхт разликује од других „масовних рањивости“?

„Све рањивости представљају одређени ризик за кориснике. Ово је посебно ризично, јер ако неко пронађе начин да га нападне са даљине (што јесте могуће, ако се пронађе начин да се заобиђе АСЛР), могао би се покренути пре него што схватите да сте под напад"

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

Међутим, Андроид није у потпуности на милости овог подвига. Водећи инжењер Андроид безбедности, Адриан Лудвиг, осврнуо се на неке недоумице у а Гоогле+ пост:

[блоцккуоте аутхор="Адриан Лудвиг"]"Постоји уобичајена, погрешна претпоставка да се свака софтверска грешка може претворити у безбедносни подвиг. У ствари, већина грешака се не може искористити и има много ствари које је Андроид урадио да побољша те шансе...

Наведена је листа неких од оних технологија које су уведене од Ице Цреам Сандвицх-а (Андроид 4.0) овде. Најпознатији од њих је под називом Аддресс Спаце Лаиоут Рандомизатион (АСЛР), који је у потпуности завршен у Андроиду 4.1 са подршком за ПИЕ (Извршне датотеке независне од позиције) и сада је на преко 85% Андроид-а уређаја. Ова технологија отежава нападачу да погоди локацију кода, што им је потребно да би направили успешан експлоат...

Нисмо стали са АСЛР, додали смо и НКС, ФортифиСоурце, Реад-Онли-Релоцатионс, Стацк Цанариес, и још много тога."[/блоцккуоте]

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

Дилема ажурирања

Говорећи о ажурирањима, добро је видети да ОЕМ преузимају одговорност за безбедност корисника, као што су многи обећали да ће побољшати процес ажурирања посебно за укључивање безбедносних исправки и закрпа за експлоатације као што је Стагефригхт.

Међу првима који су објавили званичну изјаву, Гугл је обећао месечне безбедносне исправке (поред планираних ажурирања оперативног система и платформе) за већину својих Некус уређаја, укључујући скоро 3 године стар Некус 4. Самсунг је такође следио овај пример најављујући да ће сарађивати са оператерима и партнерима на имплементацији а програм месечног безбедносног ажурирања али није успео да прецизира уређаје и детаље о временској линији ове имплементације. Ово је занимљиво јер се помиње приступ „брзим путем“ безбедносним ажурирањима у сарадњи са оператерима, тако да можемо очекујте чешћа ажурирања (иако заснована на безбедности, али се надамо да ће убрзати и надоградњу фирмвера) на оператеру уређаја.

Остали ОЕМ-ови који се придружују пакету укључују ЛГ који ће се придружити месечне безбедносне исправке. Моторола је такође најавила списак уређаја који ће бити ажурирани са Стагефригхт поправкама, а листа укључује скоро све уређаје које је компанија направила од 2013. године. Сони је то такође рекао његови уређаји ће ускоро добити закрпе такође.

По први пут, оператери такође долазе са ажурирањима. Спринт има издао саопштење да су неки уређаји већ добили Стагефригхт закрпу, са више уређаја заказано за ажурирање. АТ&Т је такође следио њихов пример издавањем закрпе неким уређајима. Веризон је такође издао закрпе, иако је ово споро увођење које даје предност врхунским паметним телефонима као што су Галаки С6 Едге и Ноте 4. Т-Мобиле Ноте 4 је такође добио ажурирање закрпе Стагефригхт.

Као крајњи корисник, постоји неколико корака предострожности који се могу предузети да би се смањиле ваше шансе да будете нападнути. За почетак, онемогућите аутоматско преузимање ММС порука у апликацијама за размену порука које су присутне на вашем телефону. Ово би требало да контролише случајеве у којима није била потребна интеракција корисника да би експлоатација функционисала. Након овога, водите рачуна да избегавате преузимање медија из ММС порука из непознатих и непоузданих извора.

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

Андроид, Пост-Стагефригхт

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

Овом подухвату је сребро: Поново је скренуо пажњу на Андроидов процес ажурирања и представио га у светлу које неће привући толико будућих корпоративних компанија да усвоје Андроид за употребу у предузећима. Како Гоогле ради на већем усвајању у предузећима, биће приморан да поново размисли о својој стратегији ажурирања и количини контроле коју омогућава ОЕМ-има.

С обзиром да се Андроид М из дана у дан приближава тржишту, не би било изненађење ако би Гоогле одлучио да одвоји све више компоненти АОСП-а у корист свог пакета Плаи услуга. На крају крајева, то је једна област над којом Гоогле и даље задржава потпуну контролу да ли се уређај испоручује са Гоогле Плаи продавницом. Ово има своје недостатке у виду замене отворених површина са зидовима са блиским изворима.

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

Друга рута која би могла бити могућност била би да буде обавезна за све уређаје са којима се испоручују Гоогле Плаи продавница за добијање гарантованих безбедносних ажурирања за фиксни временски период, можда два године. Оквир Плаи услуга може да се користи за проверу присуства важних безбедносних ажурирања и закрпа, при чему се приступ Плаи продавници укида у случају неусаглашености.

Завршне напомене

Ово је у најбољем случају још увек спекулација јер не постоји елегантан начин да се реши овај проблем. Осим веома тоталитарног приступа, увек ће постојати неки недостатак у домету поправки. Због огромног броја Андроид уређаја који постоје, праћење статуса безбедности сваког уређаја био би веома гигантски задатак. Потреба за сатом је преиспитивање начина на који се Андроид ажурира, јер тренутни начин свакако није најбољи. Ми у КСДА Девелоперс се надамо да ће Андроид и даље остати веран својим коренима отвореног кода док ради заједно са Гоогле-овим плановима затвореног кода.

Да ли је ваш телефон рањив на Стагефригхт? Мислите ли да ће ваш телефон икада добити Стагефригхт закрпу? Обавестите нас у коментарима испод!