Розбираємося в системі забезпечення безпеки Android
Зміст статті
Android - молода операційна система, і її, як будь-яку іншу новонароджену ОС, прийнято дорікати за відсутності належного рівня безпеки. Антивірусні компанії та профільні аналітики рапортують про справжній бум шкідливого ПЗ для Android і пророкують швидкий наступ армії зомбі-вірусів, які спустошать гаманці користувачів. Але чи так уразливий зелений робот насправді?
На зорі свого розвитку Android стала справжнім магнітом для нападок з боку антивірусних компаній та незалежних дослідників: інженерів Google звинувачували в недалекоглядності, величезній кількості проломів та загальної ненадійності архітектури Android. Це стосувалося всіх компонентів системи, але основний удар експертів обрушився на реалізацію механізму розмежування прав, який нібито обмежував застосування один від одного, але мав пролом у самій своїй основі.
У приклад зазвичай наводилися програми, що використовують експлойти ядра Linux, які дозволяли отримати права root, а потім зробити з системою все, що захоче зловмисник. Цих кількох знайдених уразливостей вистачило, щоб створити в жовтій пресі галас, який не вщухнув і донині.
Але як же справи насправді? Проблема існує чи ні? Чи варто боятися користувачам Android за збереження своїх даних, або перейти на iOS, і як, якщо це можливо, захистити свої дані від зловмисників? Про все це розповідає наш сьогоднішній огляд.
Хакер #166. DDoS
Діра в дірі?
У своїй основі Android покладається на ядро Linux, яке виконує більшу частину брудної роботи за нього. На Linux лягають такі турботи, як дотримання прав доступу, стеження процесами та їх коректним виконанням. Насправді це означає, що жодна програмаAndroid не може отримати доступ до даних іншої програми, поки останнє цього не захоче.
В Android це називається пісочницею (sandboxing), яка дозволяє зберегти дані сусідніх додатків один від одного, не дозволивши зловреді потягнути приватну інформацію, збережену будь-яким додатком системи. У пісочницю потрапляють всі програми, включаючи заздалегідь встановлені на апарат. Фактично лише невелика частина Android працює з правами root, а саме початковий процес zygote, що виконує функції контролю над виконанням додатків, і невелика частина системних сервісів. Решта програм завжди працює в пісочницях, тому зловред, навіть пройшов процедуру «впарювання» користувачеві, не може потягнути нічого цінного, крім вмісту SD-карти, доступ до якої за замовчуванням відкритий всім (пізніше ми ще повернемося до цього).
Крім даних окремо взятих програм, для доступу закрита також базова інсталяція Android, що розміщується на окремому розділі внутрішньої NAND-пам'яті і підключена до каталогу /system. За умовчанням вона змонтована в режимі тільки для читання і, в принципі, не зберігає в собі жодної конфіденційної інформації (для її розміщення також використовуються пісочниці /data), тому якимось хитрим чином прописатися в автозавантаження або модифікувати системні компоненти не вийде (якщо , звичайно, не використовувати експлойти для отримання прав root, про що я розповім нижче).
Для спілкування додаткам доступно кілька варіантів IPC, причому рідні для Linux засоби комунікації, такі як пам'ять і сокети, що розділяється, доступні тільки процесам, що належать одному додатку, та й то лише в тому випадку, якщо хоча б частинадодатки написана компілюваною в машинний код мовою, тобто з використанням Android NDK. У всіх інших випадках програми зможуть використовувати Binder для безпечного обміну повідомленнями та інтенти для виклику сторонніх програм (про них ми також поговоримо нижче).
Починаючи з версії 3.0, Android має вбудовану підтримку шифрування всіх даних користувача за допомогою стандартної підсистеми dmcrypt ядра Linux. Шифрування проводиться щодо того самого каталогу /data алгоритмом AES128 в режимі CBC та ESSIV:SHA256 за допомогою ключа, що генерується на основі пароля, який необхідно ввести під час завантаження ОС. При цьому варто враховувати, що картка пам'яті не шифрується, тому збережені на ній дані залишаються повністю відкритими.
Програми та права доступу
Ще одна важлива особливість такої системи полягає в тому, що налаштування користувача завжди будуть пріоритетнішими за запити додатків, а це означає, що, якщо користувач відключить GPS, додаток ніяк не зможе включити його самостійно навіть за наявності всіх прав на використання GPS. При цьому деякі функції ОС недоступні для програм зовсім. Наприклад, маніпулювати SIM-картою має право лише операційна система, і ніхто, крім неї.
Перевірка привілеїв йде на найнижчому рівні ОС, у тому числі на рівні ядра Linux, так що для обходу цієї системи безпеки зловреді доведеться не тільки отримати права root на пристрої, а й якимось чином скомпрометувати ядро, що набагато складніше завдання.
Самі по собі перераховані механізми обміну даними та виклику функцій додатків, що контролюються за допомогою системи привілеїв, в Androidреалізовані досить чітко і зрозуміло, проте можуть призвести до проблем у разі, якщо програміст недостатньо серйозно ставиться до декларації привілеїв, необхідні доступу до свого додатку. Це може призвести до витоку інформації або можливості задіяння функціональності програми будь-ким. Наприклад, у перших версіях Dropbox для Android була проблема з правильним визначенням привілеїв, яка призводила до того, що будь-яка встановлена програма могла використовувати Dropbox-клієнт для заливання будь-якої інформації на «хмарний диск» www.securelist.com.
Захист від зриву стека
Для захисту додатків, створених з використанням Android NDK, а також системних компонентів, написаних мовою Сі, Android включає в себе великий набір механізмів захисту від зриву стека, свого часу реалізованих різними розробниками для різних проектів. В Android 1.5 системні компоненти було переведено на використання бібліотеки safe-iop, що реалізує функції безпечного виконання арифметичних операцій над цілими числами (захист від integer overflow). З OpenBSD була запозичена реалізація функції dmalloc, що дозволяє запобігти атакам з використанням подвійного звільнення пам'яті та атаки узгодженості чанків, а також функцію calloc з перевіркою на можливість цілісного переповнення під час операції виділення пам'яті. Весь низькорівневий код Android, починаючи з версії 1.5, збирається із використанням механізму компілятора GCC ProPolice для захисту від зриву стека на етапі компіляції.
-В альтернативній Android-прошивці MIUI жодна стороння програма не зможе відправити SMS без явного підтвердження з боку користувача.
-CyanogenMod розширює стандартний механізм повноважень Android можливістю відмінибудь-якого повноваження вже після встановлення програми.
-
В рамках експериментального проекту SE Android відбувається робота над форком Android з активованою системою безпеки SELinux.
Репозиторій додатків
Щоб хоча б частково вирішити цю проблему, не вдаючись до ручної перевірки додатків на безпеку, як зроблено в Apple App Store, Google на початку цього року ввела в дію сервіс Bouncer, що представляє собою віртуальну машину, в якій автоматично запускається будь-який додаток, що публікується в репозиторії. Bouncer виконує багаторазовий запуск софтини, робить безліч дій, що симулюють роботу користувача з додатком, та аналізує стан системи до та після запуску з метою з'ясувати, чи не було спроб доступу до конфіденційної інформації, відправки SMS на короткі платні номери тощо.
Швидше за все, Google вже розробила схему протидії виявленню Bouncer за допомогою генерації унікальних віртуальних оточень для кожної нової програми, але так чи інакше віруси продовжуватимуть проникати в Google Play, і варто бути уважним при встановленні програм, обов'язково читаючи відгуки користувачів та аналізуючи список повноважень програми перед його встановленням.
Рев'ю коду та оновлення
Останнє, але не менш важливе, про що хотілося б сказати, говорячи про систему безпеки Android, - це реву коду і процес реагування команди розробників на появу нових вразливостей. Колись програмісти OpenBSD показали, що це один з найбільш важливих аспектів розробки безпечної ОС, і Google наслідує їх приклад досить чітко.
У Google на постійній основі працює команда безпеки Android (Android Security Team), завдання якої полягає в тому, щоб стежити за якістю кодуопераційної системи, виявляти та виправляти знайдені в ході розробки нової версії ОС помилки, реагувати на звіти про помилки, надіслані користувачами та сек'юріті-компаніями. Загалом ця команда працює у трьох напрямках:
- Аналіз нових серйозних нововведень операційної системи на безпеку. Будь-яка архітектурна зміна Android повинна бути схвалена цими хлопцями.
- Тестування коду, в якому беруть участь також Google Information Security Engineering team і незалежні консультанти. Йде постійно протягом усього циклу підготовки нового релізу ОС.
- Реагування на виявлення вразливості вже випущеної ОС. Включає постійний моніторинг можливих джерел інформації про знайдену вразливість, а також підтримку стандартного баг-трекера.
Якщо вразливість буде виявлена, команда безпеки починає наступний процес:
- Повідомляє компанії, що входять до альянсу OHA (Open Handset Alliance), і розпочинає обговорення можливих варіантів вирішення проблеми.
- Як тільки рішення буде знайдено, код вносяться виправлення.
- Патч, що містить вирішення проблеми, надсилається членам OHA.
- Патч вноситься до репозиторію Android Open Source Project.
- Виробники/оператори розпочинають оновлення своїх пристроїв у режимі OTA або публікують виправлену версію прошивки на своїх сайтах.
Особливо важливим у цьому ланцюжку є той факт, що обговорення проблеми відбуватиметься лише з тими членами OHA, які підписали угоду про нерозголошення. Це дає гарантію, що громадськість дізнається про знайдену проблему тільки після того, як її вже буде вирішено компаніями, і фікс з'явиться в репозиторії AOSP. Якщо ж про вразливістьстане відомо із загальнодоступних джерел (форуму, наприклад), команда безпеки одразу приступить до вирішення проблеми в репозиторії AOSP, так щоб доступ до виправлення отримали відразу все і якнайшвидше.
Додаткам вхід до каталогу з приватною інформацією інших програм закрито
Знову ж таки слабким місцем тут залишаються виробники пристроїв та оператори зв'язку, які можуть затягнути з публікацією виправленої версії, незважаючи на ранній доступ до виправлення.
- Детальне роз'яснення реалізації системи шифрування Android;
- опис системи повноважень для розробників додатків;
- посібник зі створення безпечних Android-додатків.
Як і будь-яка інша операційна система, Android не позбавлена вразливостей та різних архітектурних припущень, що спрощують життя вірусописачів. Але говорити про те, що Android вразлива за визначенням, також не варто. У ній явно простежується вплив останніх тенденцій у створенні безпечних операційних систем. Це і пісочниці для додатків, і чітко контрольований системою механізм обміну даними між додатками, і напрацювання проекту OpenBSD — єдиної ОС загального призначення, розробка якої велася з упором на безпеку.