Stagefright: експлойт, який змінив Android

Однією з найсильніших сторін Android є її природа з відкритим вихідним кодом, яка дозволяє зацікавленим сторонам створювати, модифікувати та перерозповсюджувати ОС у спосіб, який відповідає їхнім конкретним потребам. Але саме ця перевага відкритого коду діє як палка з двома кінцями, коли справа доходить до проблем зловмисного програмного забезпечення та безпеки. Легше знаходити та виправляти недоліки, коли у вас є багато досвідчених учасників проекту, вихідний код якого є у вільному доступі. Однак вирішення проблеми на рівні джерела не часто перетворюється на вирішення проблеми в руках кінцевого споживача. Таким чином, Android не є головним вибором, коли справа доходить до вибору ОС для корпоративних потреб, пов’язаних із конфіденційними даними.

На Google I/O 2014 Google зробив перший поштовх до більш безпечної та зручної для підприємств екосистеми, запустивши

Програма Android For Work. Android For Work використовує підхід подвійного профілю для корпоративних потреб, за допомогою якого ІТ-адміністратори можуть створювати окремі профілі користувачів для співробітників - один зосереджений на роботі, інші профілі залишаються для особистих профілів співробітників використовувати. Завдяки використанню апаратного шифрування та політик, керованих адміністратором, робочі та особисті дані залишалися чіткими та безпечними. Згодом 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 та адміністратора розробника 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, це може призвести до неправильного декодування кадрів, оскільки Процес обміну байтами використовує змінну 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 числа, які можуть бути представлені як signed int, зберігаються як signed 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 перед тим, як користувач взаємодіє з ним. Це відрізняється від фішингових атак, оскільки користувач може зовсім не помітити успішної атаки, скомпрометувавши всі наявні та майбутні дані в телефоні.

Чим Stagefright відрізняється від інших «масових вразливостей»?

«Усі вразливості становлять певний ризик для користувачів. Це особливо ризиковано, оскільки якщо хтось знайде спосіб атакувати його віддалено (а це можливо, якщо було знайдено спосіб обійти ASLR), він може бути запущений до того, як ви навіть усвідомите, що перебуваєте під загрозою атака"

Старіші експлойти, такі як Android Installer Hijacking, FakeID, а також root-експлойти, такі як TowelRoot і PingPong, вимагають взаємодії користувача в певний момент для їх виконання. Незважаючи на те, що вони все ще є «експлойтами» в тому факті, що багато шкоди можуть виникнути при зловмисному використанні, факт залишається фактом, що Stagefright теоретично потрібен лише номер мобільного телефону жертви, щоб перетворити її телефон на трояна, тому останнім часом їй приділяється так багато уваги днів.

Однак Android не повністю залежить від цього експлойту. Провідний інженер безпеки Android Адріан Людвіг висловив деякі занепокоєння в a публікація Google+:

[blockquote author="Adrian Ludwig"]"Існує поширене помилкове припущення, що будь-яку помилку програмного забезпечення можна перетворити на експлойт безпеки. Насправді більшість помилок не можна використовувати, і Android багато чого зробив, щоб покращити ці шанси...

Наведено список деяких із тих технологій, які були представлені після Ice Cream Sandwich (Android 4.0). тут. Найвідоміший з них називається рандомізація макета адресного простору (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 програма щомісячного оновлення безпеки але він не вказав деталі пристроїв і часових рамок цієї реалізації. Це цікаво, оскільки в ньому згадується «швидкий» підхід до оновлень безпеки у співпраці з операторами, щоб ми могли очікуйте більш частих оновлень (хоча й на основі безпеки, але, сподіваюся, це також прискорить оновлення прошивки) від оператора пристроїв.

Інші OEM-виробники приєднаються до групи, включаючи 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. Існують також користувацькі рішення ПЗУ, більшість із яких регулярно синхронізують джерела з AOSP і, отже, містять виправлення Stagefright. Якщо ви використовуєте ПЗУ на основі AOSP, настійно рекомендуємо оновити ПЗУ до новішої версії, яка містить патчі Stagefright. Ви можете використовувати цей додаток щоб перевірити, чи не впливає Stagefright на ваш поточний щоденний водій.

Android, Post-Stagefright

Stagefright був нічим іншим, як тривожним дзвіночком щодо Android і його проблеми фрагментації, а також оновлень. Це підкреслює, що немає чіткого механізму, за допомогою якого такі критичні виправлення можна було б своєчасно розгорнути на багатьох пристроях. Хоча OEM-виробники намагаються розгорнути виправлення для пристроїв, сувора правда полягає в тому, що більшість із цих виправлень буде обмежено лише останніми флагманами. Інші нефлагманські та старіші пристрої, а тим більше менші OEM-виробники, й надалі будуть піддаватися впливу Stagefright.

У цьому подвигу є срібна підкладка: Це знову привернуло увагу до процесу оновлення Android і представило його в світлі, який не приверне стільки майбутніх корпоративних компаній до прийняття Android для корпоративного використання. Оскільки Google працює над ширшим запровадженням на підприємствах, вона буде змушена переглянути свою стратегію оновлення та рівень контролю, який він надає OEM-виробникам.

Оскільки Android M з кожним днем ​​наближається до виходу на ринок, не було б нічого дивного, якби Google відмовився від все більшої кількості компонентів AOSP на користь свого пакета послуг Play. Зрештою, це одна зі сфер, над якою Google усе ще зберігає повний контроль, якщо пристрій постачатиметься з Google Play Store. Це має свої мінуси у формі заміни відкритих зон на закриті стіни.

Розмірковуючи про майбутнє Android, існує (дуже невелика) ймовірність того, що Google також може обмежити зміни, які OEM можуть внести в AOSP. З Рамки РРО будучи присутнім у функціональному стані в Android M, Google може обмежити OEM-виробників лише косметичними змінами у вигляді оболонок RRO. Це має забезпечити швидше розгортання оновлень, але ціною того, що виробникам обладнання буде відмовлено в можливості повністю налаштувати Android.

Інший шлях, який може бути можливим, — це зробити його обов’язковим для всіх пристроїв, які постачаються разом Google Play Store, щоб гарантовано отримувати оновлення безпеки протягом фіксованого періоду часу, можливо, двох років. Платформу Play Services можна використовувати для перевірки наявності важливих оновлень безпеки та виправлень, а доступ до Play Store буде скасовано в разі невідповідності.

Заключні примітки

Це все ще лише припущення, оскільки немає елегантного способу вирішити цю проблему. За винятком дуже тоталітарного підходу, завжди будуть деякі недоліки в досягненні виправлень. Через величезну кількість пристроїв Android відстежувати стан безпеки кожного пристрою було б дуже складним завданням. Необхідно переглянути спосіб оновлення Android, оскільки поточний спосіб, звичайно, не найкращий. Ми в XDA Developers сподіваємося, що Android продовжує залишатися вірним своїм корінням з відкритим вихідним кодом, працюючи разом із планами Google із закритим кодом.

Ваш телефон вразливий до Stagefright? Як ви думаєте, чи отримає ваш телефон коли-небудь патч Stagefright? Дайте нам знати в коментарях нижче!