Stagefright: Експлойтът, който промени Android

Една от най-силните страни на Android е основно неговата природа с отворен код, която позволява на заинтересованите страни да разклоняват, модифицират и преразпределят операционната система по начин, който отговаря на техните конкретни нужди. Но самото предимство на отворения код действа като нож с две остриета, що се отнася до проблемите със зловреден софтуер и сигурност. По-лесно е да намерите и коригирате недостатъци, когато имате много способни сътрудници по проект, чийто изходен код е достъпен безплатно. Въпреки това, коригирането на проблема на ниво източник често не означава, че проблемът е коригиран в ръцете на крайния потребител. Като такъв Android не е най-добрият избор, когато става въпрос за избор на операционна система за чувствителни към данни корпоративни нужди.

На Google I/O 2014 Google даде първия си тласък към по-сигурна и удобна за предприятия екосистема с пускането на

Програма Android For Work. Android For Work възприе подход с двоен профил за корпоративни нужди, чрез който ИТ администраторите могат да създадат a отделни потребителски профили за служителите – един фокусиран върху работата, оставяйки други профили за личните на служителите използване. Чрез използването на хардуерно базирано криптиране и политики, управлявани от администратора, работните и личните данни остават различни и безопасни. Впоследствие Android For Work получи повече внимание през следващите месеци, като голям акцент беше върху сигурността на устройството срещу зловреден софтуер. Google също планира да активирайте пълно криптиране на устройството за всички устройства които трябваше да бъдат пуснати с Android Lollipop от кутията, но това беше отменено поради проблеми с производителността, като преместването стана незадължително за OEM производителите.

Стремежът към защитен Android не е изцяло работа на Google, тъй като Samsung изигра доста важна роля в това чрез своите Принос на KNOX към AOSP, което в крайна сметка подсилен Android For Work. Въпреки това, скорошните експлойти и уязвимости в сигурността в Android сочат трудна задача, когато става въпрос за популярност за корпоративно приемане. Пример за това е скорошната уязвимост на Stagefright.

Съдържание:

• Какво е Stagefright?
• Колко сериозен е Stagefright?
• Какво прави Stagefright различен от другите „масивни уязвимости“?
• Дилемата за актуализиране
• Android, Post-Stagefright
• Заключителни бележки

Какво е Stagefright?

С прости думи, Stagefright е експлойт, който използва кодовата библиотека за възпроизвеждане на мултимедия в Android, наречена libstagefright. Механизмът libstagefright се използва за изпълнение на код, който се получава под формата на злонамерено видео чрез MMS, като по този начин се изисква само мобилният номер на жертвата, за да се извърши успешна атака.

Свързахме се с нашия вътрешен експерт, XDA Senior Recognized Developer и Developer Admin pulser_g2 за предоставяне на по-подробно обяснение.

"Докато пиша това, експлойтът [Stagefright] трябваше да бъде обяснен в BlackHat [Връзка], въпреки че все още няма налични слайдове или подробности за бялата хартия.

Затова давам това обяснение по-скоро като груба представа за случващото се, отколкото като силно задълбочено обяснение с пълна точност и т.н.

Има редица различни грешки, съставляващи Stagefright, и те имат свой собствен CVE [Често срещани уязвимости и експозиции] номера за проследяване:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

За съжаление наличните пачове не са свързани директно с всеки CVE (както трябва да бъдат), така че това ще бъде малко объркващо за обяснение.

1. [CVE-2015-1538]

В кода за обработка на MPEG4, кодът за обработка на 3GPP метаданните (нещата, които описват формата и друга допълнителна информация, когато видеото е във формат 3GPP) е бъгово. Той не отхвърля метаданни, когато данните са прекалено големи, по-скоро само проверява дали са твърде малки. Това означаваше, че е възможно нападателят да създаде „модифициран“ или „повреден“ файл, който ще има по-дълга част от метаданни, отколкото трябва.

Едно от големите предизвикателства при писането на код за обработка на „ненадеждни“ данни (т.е. от потребител или от всяко друго място, външно за вашия код) е обработката на данни с променлива дължина. Видеоклиповете са идеален пример за това. Софтуерът трябва да разпределя памет динамично, в зависимост от това какво се случва.

В този случай се създава буфер като указател към някаква памет, но дължината на масива, към който сочи, е един елемент твърде малък. След това метаданните бяха прочетени в този масив и беше възможно последният запис в този масив да не бъде "нулев" (или нула). Важно е последният елемент в масива да е нула, тъй като по този начин софтуерът казва, че масивът е завършен. Като може да направи последната стойност различна от нула (тъй като масивът е потенциално един елемент твърде малък), злонамереният код може да бъде прочетен от друга част от кода и да прочете твърде много данни. Вместо да спре в края на тази стойност, той може да продължи да чете други данни, които не трябва да чете.

(Справка: OmniROM Герит)

2. [CVE-2015-1539]

Най-краткият възможен "размер" на метаданните трябва да бъде 6 байта, тъй като е UTF-16 низ. Кодът взема размера на целочислената стойност и изважда 6 от него. Ако тази стойност беше по-малка от 6, изваждането щеше да се „препълни“ и да се увие, и щяхме да получим много голямо число. Представете си, че можете да броите само от 0 до 65535, например. Ако вземете числото 4 и извадите 6, не можете да паднете под нулата. Така че се връщате до 65535 и броите оттам. Ето какво се случва тук!

Ако е получена дължина под 6, това може да доведе до неправилно декодиране на рамки, тъй като byteswap процесът използва променливата len16, чиято стойност се получава от изчисление, започващо с (размер-6). Това може да доведе до много по-голяма операция за размяна от предвиденото, което би променило стойностите в данните на рамката по неочакван начин.

(Справка: OmniROM Герит)

3. [CVE-2015-3824]

голямо! Този е гаден. Има точно обратното на този последен проблем - целочислено препълване, при което цяло число може да стане "твърде голямо". Ако достигнете 65535 (например) и не можете да броите повече, ще се въртите и ще отидете на 0 следващия!

Ако разпределяте памет въз основа на това (което прави Stagefright!), ще се окажете с твърде малко памет, разпределена в масива. Когато данните бъдат поставени в това, това потенциално би презаписало несвързани данни с данни, контролирани от създателя на злонамерен файл.

(Справка: OmniROM Герит)

4. [CVE-2015-3826]

Още един гаден! Много подобно на последното - друго целочислено препълване, където масив (използван като буфер) ще бъде направен твърде малък. Това би позволило несвързаната памет да бъде презаписана, което отново е лошо. Някой, който може да записва данни в паметта, може да повреди други данни, които не са свързани, и потенциално да използва това, за да накара някакъв код, който контролира, да се изпълнява от вашия телефон.

(Справка: OmniROM Герит)

5. [CVE-2015-3827]

Доста подобни на тези последните. Използва се променлива при прескачане на памет и това може да стане отрицателно по време на изваждане (както по-горе). Това би довело до много голяма дължина на „пропускане“, препълване на буфер, даващо достъп до памет, която не трябва да бъде достъпвана.

(Справка: OmniROM Герит)

Има и някои (потенциално) свързани поправки, които изглежда са влезли и в [Android] 5.1.

(Справка: OmniROM Герит)

Това добавя проверки за спиране на проблеми с минала корекция на сигурността, за да добави проверки на граници, които сами по себе си могат да бъдат препълнени. В C числата, които могат да бъдат представени като int със знак, се съхраняват като int със знак. В противен случай те остават непроменени по време на операциите. При тези проверки някои цели числа можеха да бъдат направени със знак (а не без знак), което би намалило максималната им стойност по-късно и би позволило да се осъществи препълване.

(Справка: OmniROM Герит)

Някои по-ниски цели числа (където числата са твърде ниски и след това се извършва изваждане на тези числа, което им позволява да станат отрицателни). Това отново води до голям брой, а не до малък, и това причинява същите проблеми като по-горе.

(Справка: OmniROM Герит)

И накрая, друго цяло число препълване. Както и преди, предстои да се използва другаде и може да прелее.

(Справка: OmniROM Герит)"

Колко сериозен е Stagefright?

Според блог пост публикувана от изследователската компания-майка, Zimperium Research Labs, експлойтът Stagefright потенциално разкрива 95% от устройствата с Android - приблизително 950 милиона - за тази уязвимост, тъй като засяга устройства, работещи с Android 2.2 и нагоре. За да влошат нещата, устройствата преди Jelly Bean 4.3 са изложени на „най-голям риск“, тъй като не съдържат адекватни смекчаващи мерки срещу този експлойт.

По отношение на щетите, които Stagefright може да причини, pulser_g2 отбеляза:

[blockquote author="pulser_g2"]"Сам по себе си Stagefright ще даде достъп на системния потребител на телефона. Трябва да заобиколите ASLR (рандомизиране на оформлението на адресното пространство), за да злоупотребите с него. В момента не е известно дали това е постигнато или не. Този експлойт позволява „произволен код“ да се изпълнява на вашето устройство като системен или медиен потребител. Те имат достъп до аудиото и камерата на устройството, а системният потребител е чудесно място за стартиране на root експлойт. Спомняте ли си всички невероятни root експлойти, които сте използвали, за да руутнете телефона си?

Те потенциално могат да бъдат използвани безшумно за получаване на руут на вашето устройство! Този, който има root, притежава телефона. Те трябваше да заобиколят SELinux, но TowelRoot се справи с това и PingPong също се справи. След като получат root, всичко на телефона ви е отворено за тях. Съобщения, ключове и т.н."[/blockquote]Говорейки за най-лошите сценарии, е необходим само MMS, за да достави код и да задейства този експлойт. Потребителя дори не е необходимо да отваря съобщението тъй като много приложения за съобщения обработват предварително MMS, преди потребителят да взаимодейства с него. Това е различно от spear-phishing атаките, тъй като потребителят може напълно да забрави за успешна атака, компрометирайки всички настоящи и бъдещи данни в телефона.

Какво прави Stagefright различен от другите „масивни уязвимости“?

„Всички уязвимости представляват известен риск за потребителите. Това е особено рисковано, тъй като ако някой намери начин да го атакува дистанционно (което е възможно, ако се намери начин да се заобиколи ASLR), може да се задейства, преди дори да осъзнаете, че сте под атака"

По-стари експлойти като отвличане на Android Installer, FakeID, както и руут експлойти като TowelRoot и PingPong изискват взаимодействие с потребителя в даден момент, за да бъдат изпълнени. Въпреки че те все още са „експлоатации“ във факта, че могат да причинят много вреди, ако се използват злонамерено, остава фактът, че Stagefright теоретично се нуждае само от мобилния номер на жертвата, за да превърне телефона си в троянски кон и затова му се обръща толкова много внимание напоследък дни.

Android обаче не е изцяло поверен на милостта на този експлойт. Водещият инженер по сигурността на Android, Адриан Лудвиг обърна внимание на някои опасения в a Публикация в Google+:

[blockquote author="Adrian Ludwig"]"Има често срещано, погрешно предположение, че всеки софтуерен бъг може да бъде превърнат в експлойт за сигурност. Всъщност повечето грешки не могат да се използват и има много неща, които Android е направил, за да подобри тези шансове...

Посочен е списък на някои от тези технологии, които са въведени след Ice Cream Sandwich (Android 4.0). тук. Най-известният от тях се нарича Randomization на оформлението на адресното пространство (ASLR), който беше напълно завършен в Android 4.1 с поддръжка на PIE (независими от позицията изпълними файлове) и вече е на над 85% от Android устройства. Тази технология прави по-трудно за нападателя да отгатне местоположението на кода, което е необходимо за изграждането на успешен експлойт...

Не спряхме с ASLR, ние също добавихме NX, FortifySource, Read-Only-Relocations, Stack Canaries и други."[/blockquote]

Все още обаче не може да се отрече, че Stagefright е сериозен въпрос за бъдещето на Android и като такъв се приема сериозно от заинтересованите страни. Stagefright също подчерта белите слонове в стаята - проблемът с фрагментацията и актуализациите, които най-накрая достигат до потребителя.

Дилемата за актуализиране

Говорейки за актуализации, добре е да се види, че OEM производителите поемат отговорност за сигурността на потребителите, както мнозина обещаха подобряване на процеса на актуализиране специално за включване на корекции за сигурност и корекции за експлойти като Stagefright.

Сред първите, които пуснаха официално изявление, Google обеща месечни актуализации за сигурност (в допълнение към планираните актуализации на операционната система и платформата) за повечето си устройства Nexus, включително почти 3-годишния Nexus 4. Samsung също последва примера, като обяви, че ще работи с оператори и партньори за прилагане на a месечна програма за актуализиране на сигурността но не успя да уточни подробностите за устройствата и времевата линия на това внедряване. Това е интересно, тъй като споменава „бърз“ подход към актуализациите на защитата в сътрудничество с операторите, така че можем очаквайте по-чести актуализации (макар и базирани на сигурността, но се надяваме, че ще ускорят и надстройките на фърмуера) на оператора устройства.

Други производители на оригинално оборудване, които се присъединяват към групата, включват LG, който ще се присъедини към тях месечни актуализации за сигурност. Motorola също обяви списък с устройства, които ще бъдат актуализирани с корекции на Stagefright, а списъкът включва почти всички устройства, които компанията е направила от 2013 г. насам. Sony също каза това неговите устройства скоро ще получат корекциите също.

Веднъж операторите също предстоят с актуализации. Спринт има излезе с изявление че някои устройства вече са получили корекцията Stagefright, като още устройства са планирани за актуализация. AT&T също последва примера чрез издаване на корекцията на някои устройства. Verizon също издаде корекции, въпреки че това е бавно внедряване, което дава приоритет на смартфони от висок клас като Galaxy S6 Edge и Note 4. T-Mobile Note 4 също получи актуализация на корекцията на Stagefright.

Като краен потребител има няколко предпазни стъпки, които могат да бъдат предприети, за да намалите шансовете си да бъдете атакувани. Като за начало деактивирайте автоматичното извличане на MMS съобщения в приложенията за съобщения, присъстващи на вашия телефон. Това трябва да контролира случаите, когато не е необходимо взаимодействие с потребителя, за да работи експлойтът. След това внимавайте да избягвате изтеглянето на мултимедия от MMS съобщения от неизвестни и ненадеждни източници.

Като опитен потребител на XDA можете също направете редакции на вашата конструкция, за да деактивирате Stagefright. Това не е пълен и сигурен начин да се спасите от Stagefright, но можете да се възползвате от шансовете си да намалите вероятността от успешна атака, ако сте останали на по-стара версия на Android. Има и персонализирани ROM решения, повечето от които редовно синхронизират източници с AOSP и следователно ще имат включени корекции на Stagefright. Ако използвате ROM, базиран на AOSP, силно се препоръчва да актуализирате до по-нова версия на ROM, която включва пачовете на Stagefright. Можеш да използваш това приложение за да проверите дали текущият ви ежедневен шофьор е засегнат от Stagefright.

Android, Post-Stagefright

Stagefright не беше нищо друго освен сигнал за събуждане към Android и неговия проблем с фрагментацията, както и актуализациите. Той подчертава как няма ясен механизъм, чрез който такива критични корекции могат да бъдат въведени своевременно на множество устройства. Докато производителите на оригинално оборудване се опитват да пуснат корекции за устройства, суровата истина е, че повечето от тези корекции ще бъдат ограничени само до последните флагмани. Други не-флагмани и по-стари устройства, още по-малко от по-малки производители на оригинално оборудване, ще продължат да бъдат изложени на подобно на Stagefright.

Има сребърна подплата за този експлойт: Той отново привлече вниманието върху процеса на актуализиране на Android и го представи в светлина, която няма да привлече толкова много бъдещи корпоративни компании към приемането на Android за корпоративна употреба. Докато Google работи за по-голямо възприемане от предприятията, той ще бъде принуден да преосмисли своята стратегия за актуализиране и размера на контрола, който позволява на OEM производителите.

Тъй като Android M се доближава до пускането на пазара с всеки изминал ден, не би било изненада, ако Google избере да отдели все повече и повече компоненти на AOSP в полза на своя пакет услуги за Play. В края на краищата, това е една област, върху която Google все още запазва пълен контрол, ако дадено устройство ще се доставя с Google Play Store. Това има своите недостатъци под формата на замяна на отворени зони със стени с близки източници.

Когато се спекулира с бъдещето на Android, има (много малка) възможност Google също да ограничи промените, които производителите на оригинално оборудване могат да направят на AOSP. С RRO рамка тъй като присъства във функционално състояние в Android M, Google може да ограничи производителите на оригинално оборудване да правят само козметични промени под формата на RRO кожи. Това би трябвало да позволи по-бързо внедряване на актуализацията, но ще бъде с цената на отказа на OEM възможността да персонализира напълно Android.

Друг начин, който може да бъде възможен, е да го направите задължителен за всички устройства, с които се доставят Google Play Store за получаване на гарантирани актуализации за сигурност за фиксиран период от време, евентуално два години. Рамката на Play Services може да се използва за проверка на наличието на важни актуализации и пачове за сигурност, като достъпът до Play Store се анулира в случай на несъответствие.

Заключителни бележки

Това все още е спекулация в най-добрия случай, тъй като няма елегантен начин за отстраняване на този проблем. С изключение на много тоталитарен подход, винаги ще има някои недостатъци в обхвата на корекциите. Поради големия брой устройства с Android, проследяването на състоянието на сигурността на всяко устройство би било много гигантска задача. Необходимостта на момента е преосмисляне на начина, по който Android се актуализира, тъй като настоящият начин със сигурност не е най-добрият. Ние от XDA Developers се надяваме, че Android продължава да остава верен на своите корени с отворен код, докато работи заедно с плановете на Google за затворен код.

Вашият телефон уязвим ли е на Stagefright? Мислите ли, че телефонът ви някога ще получи корекция на Stagefright? Кажете ни в коментарите по-долу!