Google уже выпустила Android 7. В ближайшее время владельцы различных устройств под управлением Android получат обновление прошивки. Одними из первых новую версию получат пользователи фирменных устройств Google Nexus 6P, 5X, 6, 9, Google Pixel C, Nexus Player, Android One. Так как Google распространяет обновления Android волнами, не все пользователи этих устройств смогут оперативно получить обновление. Android 7 также смогут получить флагманские модели устройств таких вендоров как Samsung (Galaxy S6 и S7), HTC (HTC 10, One A9 и One M9), Sony (Xperia Z3+, Xperia Z4 Tablet, Xperia Z5, Xperia X), LG (V20), Huawei. В новой версии Android появился ряд новых серьезных функций безопасности (security features), о некоторых из которых мы писали в предыдущих постах. Первый был посвящен функции Direct Boot, которая упростит владельцам устройств работу с шифрованием. Второй содержал информацию об улучшениях безопасности ядра Linux, на котором основана Android.Функция Direct Boot ответственна за своевременную подготовку исполнения системных файлов Android на зашифрованном устройстве. Так как предыдущие версии Android использовали метод шифрования Full Disc Encryption (FDE), т. е. шифрование памяти устройства целиком, загрузчику необходимо было знать код разблокировки устройства для расшифровки системных файлов (в качестве компонента ключа шифрования Android использует код разблокировки устройства). В такой схеме пользователю нужно было ввести код разблокировки дважды после перезагрузки устройства: в первый раз для разблокировки системных файлов, а второй для разблокировки самого устройства.
Своей реализацией Direct Boot обязана тому факту, что Android 7 переключилась с использования шифрования FDE на шифрование per-file, т. е. каждого отдельного файла. Такая схема шифрования уже давно применяется в iOS.
Under the hood, file-based encryption enables this improved user experience. With this new encryption scheme, the system storage area, as well as each user profile storage area, are all encrypted separately. Unlike with full-disk encryption, where all data was encrypted as a single unit, per-profile-based encryption enables the system to reboot normally into a functional state using just device keys. Essential apps can opt-in to run in a limited state after reboot, and when you enter your lock screen credential, these apps then get access your user data to provide full functionality.
Источник
Другое security-улучшение касается печально известного системного сервиса под названием MediaServer. Этот компонент работает с повышенными правами и отвечает за проигрывание различного мультимедийного контента. Уязвимости в нем регулярно закрывались в обновлениях безопасности Android, о которых мы писали в блоге. Функция безопасности под названием overflow sanitization помогает закрыть целый класс уязвимостей Android, которые были обнаружены в библиотеке libstagefright. Данную библиотеку использует MediaServer. Другое улучшение безопасности MediaServer касается работы всего мультимедийного стека компонентов, каждый из которых теперь находится в условиях изоляции своего собственного окружения sandbox.
First, by incorporating integer overflow sanitization, part of Clang’s UndefinedBehaviorSanitizer, we prevent an entire class of vulnerabilities, which comprise the majority of reported libstagefright bugs. As soon as an integer overflow is detected, we shut down the process so an attack is stopped. Second, we’ve modularized the media stack to put different components into individual sandboxes and tightened the privileges of each sandbox to have the minimum privileges required to perform its job. With this containment technique, a compromise in many parts of the stack grants the attacker access to significantly fewer permissions and significantly reduced exposed kernel attack surface.
Рис. В Android 7 сервис MediaServer разбит на различные подсистемы (мультимедийный стек), которые работают с ограниченными правами и в ограниченном окружении (sandbox). Видно, что новая система присвоения прав сервисам является гораздо эффективной с точки зрения безопасности, поскольку позволяет задать приложению только нужные ему права. В новой версии библиотека libstagefright функционирует в сервисе MediaCodecService, который имеет минимальные права в системе. Таким образом, эксплуатация уязвимостей в этом компоненте для Android 7 не принесет атакующим никаких результатов.
Новая функция Verified Boot строго контролирует целостность загрузчика, предотвращая загрузку устройства в случае его компрометации. Улучшению подвергся и механизм изоляции приложений (sandbox) ядра Linux, известный как seccomp. Кроме этого, были улучшены настройки конфигурации подсистемы безопасности SELinux. Обе этих меры позволяют полностью закрыть механизм безопасности sandbox приложений, а также уменьшить риск успешной эксплуатации других методов атак, используемых эксплойтами.
Об улучшениях безопасности ядра Android мы писали ранее. Они включают в себя реализацию DEP для виртуальной памяти режима ядра (Kernel DEP), функцию типа SMAP, которая позволяет блокировать доступ к страницам пользовательской виртуальной памяти для кода режима ядра. Несколько новых функций относятся к технике, известной под названием Attack Surface Reduction (ASR), она позволяет существенно сократить успешность эксплуатации целого класса уязвимостей. В рамках ASR. Android 7 поддерживает удаление доступа по умолчанию отладки устройства, а также запрещает приложениям использовать некоторые команды с использованием функции ioctl.
Улучшенным стал и механизм обновлений Android 7 «по воздуху» (OTA update). Теперь размер обновлений стал более компактным, а время установки существенно сократилось. Сокращение времени установки обуславливается еще и тем фактором, что в новой версии не будет этапа «подготовки приложений», который занимал больше всего времени в процессе установки обновления в предыдущих версиях Android.
be secure.
Комментарии (44)
lorc
07.09.2016 20:07+1Два самых толстых вектора атаки — это GPU и апаратные кодеки. И у того, и у другого есть своя прошивка и есть возможность работать с любой памятью в обход ядра. При чем, аппаратные кодеки чаще всего управляются мелким ARM-ядром, соотвественно набор комманд известен.
Поэтому, то что MediaServer будет изолирован на уровня ядра линукса никак не спасет от хитрого видео-файла, который вызовет переполнение стека в коде аппаратного декодера и исполнение произвольного кода на отдельном процессорном ядре.
Мне кажется, что такие атаки непопулярны только потому что они будут таргетированны только на конкретную модель устройства.
qw1
08.09.2016 02:08-1Давно не слышно про уязвимости кодеков. Я думаю, потому что основная опасность — это парсинг формата файла, или контейнера, где есть размеры и смещения, которые можно выставить некорректными. В декодировании однородного потока данных, который stagefright скармливает декодерам, много меньше мест для ошибок, приводящим к изменению control flow. Там одна математика, а не управление буферами и размещением данных.
lorc
08.09.2016 14:12+2Кажется вы слишком хорошего мнения о проприетарных кодеках. Я бы мог много страшного рассказать, то NDA не дает вдаваться в детали.
Вот, например, был очень интересных глюк в однмом проприетарном OMX компоненте. В результате кривого взаимодействия с аппаратным модулем, код OMX компонента вызывал munmap с очень неправильным размером, в результате чего размапливалась вся память mediaserver'a. Просто потому что один разработчик прошивки кодека решил использовать поле size в шареном буфере немножно не по назначению.
А теперь представьте сколько ошибок такого рода просто не вылезло при тестировании или на них решили забить.
qw1
08.09.2016 02:01Непонятно, как это не будет этапа «подготовки приложений».
Это же компиляция dex-кода установленных apk в машинный код, с объединением кода framework.jar и других системных jar с кодом приложения, чтобы применить «Whole program optimization». От такой мощной оптимизации решили отказаться?VioletGiraffe
08.09.2016 08:01«Подготовка» всего лишь сделана асинхронной. Сначала приложение скачивается и устанавливается, а потом оптимизируется.
qw1
08.09.2016 11:47Тут же вопрос не в установке приложения. А в том, что раньше OTA, содержащая обновление framework, инвалидировала dalvik-cache. При перезагрузке системы все приложения, встроенные и установленные, долго компилировалось заново. А теперь при начальной загрузке компилируются только критичные приложения (оболочка, телефон), а остальные позже в фоне?
FLABER
08.09.2016 11:36+3В прошлых версиях Android ART работал как AOT (Ahead Of Time) компилятор. Все приложения, которые устанавливались на устройства с Android, компилировались один раз во время установки, используя текущую конфигурацию системы. После обновления ОС каждая программа должна была пройти оптимизацию, чтобы соответствовать изменениям в системе и новым API. Для решения этой проблемы в Android 7.0 ART работает как гибридный AOT/JIT компилятор. JIT (Just-in-time) предусматривает компиляцию программы каждый раз, когда она запускается. Это ускоряет как установку, так и работу системы, которой не нужно тратить ресурсы на компиляцию. Но JIT увеличивает нагрузку на процессор и память, расходуя больше заряда аккумулятора. Поэтому в Android 7.0, после установки (или обновления ОС) приложение запускается через JIT компиляцию, но когда устройство на зарядке и не используется, стартует AOT компилятор и завершает установку.
Cubus
08.09.2016 18:25Спасибо за объяснения!
Неужели лишние 10-15 минут при установке OTA (что происходит не так уж часто) оказались настолько критичными, что пошли на такое усложнение?qw1
08.09.2016 20:54+1Открыл сохранённый logcat от какого-то обновления.
265 приложений (только системные, на чистом телефоне) на Snapdragon 600 — примерно за 45 минут.
В некоторые времена я сотню разных утилит и игрушек ставил, это ещё порядка того же времени на компиляцию /data/app.
При этом, телефоном пользоваться нельзя, а вдруг захочется позвонить.
ArtRoman
09.09.2016 11:43+1Это не только OTA, это ещё дико тормозило девайс при установке обновлений через Google Play, а так же при удалении обновлений системных приложений (после удаления обновления оптимизировалась встроенная в систему версия приложения). Живой телефон при установке обновлений из маркета, да и просто быстрая установка приложений на обновлённом 5X весьма радует. Однако, при первом старте после чистки кэша Dalvik, оптимизация никуда не делась, но сейчас она проходит гораздо быстрее, так как в обязательном порядке оптимизирует лишь системные компоненты (system/framework, некоторые system/priv-app, vendor/app), а кэш приложений хранится в папке данных самого приложения, и создаётся лишь при необходимости (вижу как *.odex, так и *.art файлы для каждого приложения).
Diaskhan
08.09.2016 06:41-3Мне кажется ?? или Андроид запиливается не только для смартфонов и планшетов, а для чего то более серьезного ???
Попахивает Рабочей станцией на Андроиде!!!
lostmsu
08.09.2016 09:55А сколько было шуток про Windows с видеподсистемой в режиме ядра. А тут до последней мажорной версии _кодеки_ под рутом работали. Андроид теперь — новое решето. Тем более с неналаженной системой обновлений безопасности.
Rubaka
08.09.2016 21:30что в ней не налажено? обновления безопасности каждый месяц приходят.
lostmsu
09.09.2016 08:49А ядрышко кто обновляет? Что с миллионами устройств с непатченным stagefright?
vikarti
14.09.2016 18:28Кому?
И почему на Nexus 5 мне OTA-апдейт с сентябрьскими обновлениями пришлось руками ставить. На моем Nexus 10 — апрельский. на Xperia Z2 Tablet — майский. Xperia Z Ultra — а вообще нет как понятия.
(на всем сток).
fishca
08.09.2016 11:36А что с производительностью в этой версии?
izzholtik
09.09.2016 14:40хуже, но не сильно.
fishca
09.09.2016 15:39печально, что-то не так у нас в консерватории
izzholtik
13.09.2016 12:38А что у вас с консервами не так?
fishca
13.09.2016 13:44Хотелось бы чтобы консервы обрабатывались в новых консерваториях быстрее, но не наоборот :)
izzholtik
13.09.2016 15:41В основном, претензии к памяти, система разожралась до 800 мб. Видимо, из-за того, что медиасервер на несколько частей развалили. Плюс всякие сервисы и прочий шлак — итого для приложений из 2 гб остаётся около 700 мб, что немного печально.
Wicron
09.09.2016 16:56Меры напоминают попытку обернуть прогнившее ведро мусора оплеткой, чтобы не пахло и постояло дальше. Лучше бы купили ARM и сделали нормальную native OS с контролем всего и вся так как им будет нужно. При текущей парадигме, когда часть устройства с прошивками кодеков, модулей и самое интересное — ядром линукс отдается по сути вендору, ни одно решение не будет гарантировать безопасности. Либо все возможные дырки придется обернуть в кучу таких вот оплеток. За всеми возможными дырками не успеть. Вендоры наплодили просто зоопарк решений, консорциумов, над которыми нужно брать контроль.
qw1
09.09.2016 17:14После той кастомизации, которую легко делать декомпиляцией jar/apk, внесением изменений и рекомпиляцией, переходить на ОСь с native-кодом не хочется. Вот пример, как Navigation Bar с унылыми кнопками «Назад/Домой/Меню» превратили в прокручиваемую область с кучей режимов и кнопок: https://www.youtube.com/watch?v=74IZEvR6xw8
Помимо этого, несложно модифицируется «шторка» и множество аспектов системных приложений (алгоритмы работы авто-яркости, состав Power Button Menu, содержимое lockscreen, меняется интерфейс «Телефона» и «Контактов»).
qw1
09.09.2016 17:24Вендоры наплодили просто зоопарк решений, консорциумов, над которыми нужно брать контроль.
Тут два момента:
1) Открытость и бесплатность андроида. Вендоры считают риски, и знают, что если завтра google откажется сотрудничать, они перейдут на другие облачные сервисы (Yandex, Nokia, Microsoft, Apple, Amazon), но в целом система не рухнет
2) Возможность кастомизации позволяет «выделиться». Например, Samsung комплектует устройства стилусом и реализует двухэкранный режим. HTC выкатывало новый интерфейс домашнего экрана «под плитки» (на волне анонса WinPhone, получилась в итоге ерунда и все вернулись в обычный режим, но как вау-фактор работало очень хорошо).
Microsoft, наоборот, пошла по пути, запрещающем сильные кастомизации. Это хорошо для платформы, но плохо для вендора. Зачем ему делать то же, что и у всех, становиться этаким noname-ом. Пользователи не будут подсаживаться на фичи интерфейса, и смогут легко переходить между производителями. А сейчас кто-то привык к Samsung, кто-то — к HTC, и нужны очень веские причины, чтобы сменить оболочку.
То есть, предложение взять ОСь под контроль не пройдёт, вендоры не поддержат.ArtRoman
12.09.2016 14:44Можно взять ОСь под контроль, но не менять user-space область – приложения, API. Все приложения крутятся в «виртуалках» dalvik (ныне art), причём уже скомпилированный код, и Google уже давно потихоньку затягивает гайки – приложения теряют доступ к флешке, к другим приложениям, к системным файлам, отключаются лишние броадкасты, во время сна теряется сетевой доступ, теперь вот запрещено использовать системные библиотеки в качестве динамически подключаемых для нативного кода, и т.д. При этом каждое приложение живёт своей жизнью и должно иметь у себя всё необходимое, все зависимости. Что там внутри – в целом, не должно интересовать ни разработчиков, ни конечных пользователей. Какая подсистема, что там происходит, как работает – это может быть скрыто и изменено. Те же медиа-библиотеки и сервисы, несмотря на описанные изменения, не изменились для разработчиков и для приложений, обеспечена полная совместимость. Так же андроид «портируется» под другие среды выполнения – например, можно запустить андроид-приложение без перекомпиляции или какой-либо модификации в хроме на компьютере на разных архитектурах и в разных операционных системах — в этом случае в качестве зависимого расширения скачается «эмулятор» – среда, внутри которого работает андроид, а файловый доступ представляется через стандартное файловое представление расширений хрома. В целом, это и есть показатель переносимости, который позволяет заменять внутренние организации системы, сохраняя внешнюю совместимость и работоспособность.
Таким образом, можно «взять ОСь под контроль» именно для унификации внутренних компонентов с сохранением совместимости, для исключения возможности влияния нативного дырявого кода от сторонних вендоров на всю систему. При этом внешняя кастомизация должна остаться, хотя и тут вендоры могут накосячить (и косячат!)qw1
12.09.2016 15:30Не вариант, потому что вендорская кастомизация лезет и в ядро, и во framework.
Примеры:
— не выключается экран, если пользователь читает текст в любом приложении (камера отслеживает зрачки) — Samsung;
— можно вводить жесты на выключенном экране (свайп вверх — включение, свайпы влево-вправо — управление музыкальным плеером, реализовано модификацией кода драйвера тач-панели) — HTC;
— деление экрана на 2 обрасти, в каждой из которых работает своё приложение — Samsung.
К слову, только в Android 5.1 появилась поддержка dual-sim (до этого реализуемая вендорами вручную на всех уровнях — от ядра, до фрейморка и приложений).
То есть, чтобы получить отличную интеграцию и потрясающий UX, нужен доступ ко всем уровням ОС, иначе многие «инновационные» плюшки не сделаешь.
Wicron
13.09.2016 11:03Удивительно, как им удалось замять неудачный переход между dalvik и art. Последнему прочили лидерство в контексте многоядерных процессоров, однако обновление 5 и выше чуть ли не превратило в кирпичи часть их же фирменных устройств, которым к примеру являлся не слабый 4х ядерный nexus 12,13 годов c tegra на борту. Удивительно, как можно делать самим ОС, если свои же обновления просто убивают часть устройств в плане юзабилити из тормозов и глюков.
ArtRoman
13.09.2016 12:23Кирпичи при обновлении — это одно (так и не понял, с чем именно это связано, но даже сестра подхватила синдром кирпича на Nexus 5, пришлось перешивать целиком полным образом), там изменился и процесс обновления, когда в OTA стали не диффы файлов вкладываться, а изменения блочных устройств (то есть это даже выше уровня ФС). А наибольшая проблема – тормоза старого железа. Art, несмотря на скорость работы, кушал больше памяти, и на девайсах с маленькой медленной оперативкой это стало болезненно. Более того, текущий их девайс, Nexus 5X, тоже имеет лишь 2 ГБ оперативки, и ещё пол-гига свапа – быстрая память спасает, но вынужденное шифрование печалит. При отключении шифрования заметна разница, особенно при нагрузке на IO – например, съёмка фотографий в HDR+, когда они обрабатываются, занимая память и проц, а затем сохраняются.
Wicron
12.09.2016 17:36Здесь можно спорить долго, нужно понять одно — пока google дает вендорам право подсовывать практически любое по качеству ядро и затыкать все дырки кодом Android, все это останется примерно как сейчас. Ну зачем это делать?
qw1
12.09.2016 18:37Тут вопрос в целях. Требуется создать безопасную ОСь или коммерчески успешную?
Каждый вендор думает, что его кастомизации уж точно самые лучшие, стабильные и безопасные.
И если ему косвенно намекнуть — ты дурак, мы тебе не доверяем, то его поддержки так не получить.
Wicron
13.09.2016 10:59Ему (вендору) не надо намекать, когда он делает решения на x86 — его задачи ограничиваются чем-то на уровне BIOS, за остальное отвечает нормальная компания с вменяемым образом мышления, ей уже не нужно никого называть дураками, так как она все делает за них. BIOSом тоже занимаются конторы со стажем чуть ли не 30+, такое есть на рынке. А что же в случае ARM? Бедная компания, которой нужно на одной подложке разместить миллиард транзисторов обязана, внимание, содержать штат embedded linux инженеров, или платить за это на сторону, что реже. Rockchip, Samsung, Qualcomm, до недавнего времени и Allwinner делали это. Крупная контентообразующая компания (название сами додумаете) вогнала вендоров в краску, заставив рынок потреблять 85% планшетов по цене 180 баксов и менее. У них нет денег на то, чтобы качественно пилить ядро. Samsung да в этом плане в основной гамме устройств за счет наработок прошлых лет неплохи, Quallcomm тоже. Остальные медленно подтягиваются или стоят на месте.
Производительность — уже давно пора иметь на Андроид вменяемые по качеству нагруженные приложения, те же игры, взгляните на свой магазинный топ, там уже не осталось вменяемого интересного контента, когда-то давно вы заточили операционку под быструю разработку простых приложений. Время пришло развивать платформу дальше. Как вы будете развиваться в этом направлении, если у вас нет контроля над качеством ядра, особенно в контексте графики?qw1
13.09.2016 14:51На x86 так исторически сложилось, что, во-первых, ноуты — это мобильные ПК (где пользователи привыкли сами ставить ОСь), во-вторых, ОСь традиционно была закрытой, поставлялась в виде скомпиленных бинарных файлов, и в ядре не было никакой возможности покопаться. С Андроидом иначе — джин выпущен из бутылки, сдавать свои позиции вендоры не будут.
Главное, зачем это гуглу? Думайте с точки зрения бабла. Сейчас все продажи идут через play store, принося 30% комиссии, все пользователи подсажены на крючок сервисов и сдают свои персональные данные. Если начинать мутить воду, есть риск, что их новую концепцию не примут, андроид форкнут, сервисы (почта, карты) закажут у другого поставщика (сейчас есть выбор). Одни убытки.
А какие плюсы? Концепция «чистого» устройства. Но есть же нексусы, как-то их народ не очень любит. Гугл в качестве осторожного эксперимента пробует этот путь. Если вы хотите такой андроид, болейте за что, чтобы у них с нексусами получалось лучше и лучше.
Лучше закидывать всё патчами или, ещё лучше, требовать от юзеров купить новое устройство, с закрытой дырой ))
те же игры, взгляните на свой магазинный топ, там уже не осталось вменяемого интересного контента
Тут дело не в ядре. Я помню бум «графонистых» игр в 2009-2011 (выходили Dead Space, серии шутеров N.O.V.A. и Modern Combat). Это всё сдулось вовсе не из-за качества ядра.
С одной стороны, юзеры привыкли платить $1-$2, на таком бюджете сложно делать качественные игры.
С другой стороны, казуальное управление. Сложно управлять шутером или стратегией на тач-скрине. А девайсы с полноценными контроллерами выходят из нишы повсеместно носимых. Консоли на андроиде не взлетели из-за нехватки игр по 1-й причине.
И ещё момент (возможно, спорный). Если я хочу поиграть в качественную игру, мне нужно погружение в её мир. А это большой экран и много времени (а мобильные девайсы — это игры в очередях, в автобусах, в туалете и т.п. небольшие сессии).Wicron
13.09.2016 15:57Следуя этим комментариям можно признать такие творения как Ps Vita и то, чем занимаются Sony и Nintendo — дурачеством. Там же нет большого экрана Но там есть реально удобный, быстрый, продуманный и отлаженный продукт. Хотя это ниша потенциально может быть занята и Анроидом, но они там чувствуют себя вольготно и не боятся своей гегемонии, это реально массово с позиции игр. Кто бы что ни говорил, через мои руки прошел десяток аппаратов на google, общие мои взносы на деятельность этой компании превысили шестизначную сумму, но теперь я ношу с собой iPad. Вы сами сделали удобный конвеер для своего конкурента не заняв нишу, сходную по качеству продукта.
qw1
13.09.2016 17:04Ниша не может быть занята андроидом, потому что
1) пользователи не привыкли платить (плюс большой процент пиратства)
2) зачем мне два андроид-устройства (телефон и консоль), я лучше попробую сэкономить, используя телефон как консоль, в итоге разочаруюсь и брошу андроид-консоль.
TargetSan
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.