Stagefright — один из худших эксплойтов, которые Android видел за последнее время. Нажмите, чтобы узнать больше об особенностях и узнать, как защитить себя!
Одной из самых сильных сторон Android в первую очередь является его природа с открытым исходным кодом, которая позволяет заинтересованным сторонам разветвлять, модифицировать и распространять ОС таким образом, который соответствует их конкретным потребностям. Но само это преимущество открытого исходного кода действует как палка о двух концах, когда дело касается проблем вредоносного ПО и безопасности. Легче находить и исправлять недостатки, когда в проекте много способных участников, исходный код которых доступен бесплатно. Однако устранение проблемы на уровне исходного кода не часто приводит к тому, что проблема оказывается в руках конечного потребителя. Таким образом, Android не является лучшим выбором, когда дело доходит до выбора ОС для корпоративных нужд, чувствительных к данным.
На Google I/O 2014 компания Google сделала первый шаг к созданию более безопасной и удобной для предприятий экосистемы, запустив
Стремление к созданию безопасного Android — это не только работа Google, поскольку Samsung сыграла в этом довольно значительную роль через свою Вклад KNOX в AOSP, что в конечном итоге усиленный Android для работы. Однако недавние эксплойты и уязвимости безопасности в Android указывают на непростую задачу, когда дело доходит до популярности для корпоративного внедрения. В качестве примера можно привести недавнюю уязвимость Stagefright.
Содержание:
- Что такое страх сцены?
- Насколько серьезен страх сцены?
- Что отличает Stagefright от других «массовых уязвимостей»?
- Дилемма обновления
- Android, после страха
- Заключительные замечания
Что такое страх сцены?
Проще говоря, Stagefright — это эксплойт, который использует библиотеку кода для воспроизведения мультимедиа в Android под названием libstagefright. Движок libstagefright используется для выполнения кода, полученного в виде вредоносного видео через MMS, поэтому для проведения успешной атаки требуется только номер мобильного телефона жертвы.
Мы обратились к нашему штатному эксперту, старшему признанному разработчику XDA и администратору разработчика. пульсатор_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) содержит ошибки. Он не отклонял метаданные, если данные были чрезмерно большими, а только проверял, не слишком ли они малы. Это означало, что злоумышленник мог создать «модифицированный» или «поврежденный» файл, который имел бы более длинную часть метаданных, чем следовало бы.
Одной из больших проблем при написании кода для обработки «ненадежных» данных (т. е. от пользователя или из любого другого места, внешнего по отношению к вашему коду) является обработка данных переменной длины. Видео являются прекрасным примером этого. Программному обеспечению необходимо динамически распределять память в зависимости от того, что происходит.
В этом случае буфер создается как указатель на некоторую память, но длина массива, на который он указывает, оказалась на один элемент меньше. Затем метаданные считывались в этот массив, и можно было сделать так, чтобы последняя запись в этом массиве не была «нулевой» (или нулевой). Важно, чтобы последний элемент массива был равен нулю, поскольку именно так программа сообщает, что массив завершен. Имея возможность сделать последнее значение ненулевым (поскольку массив потенциально был на один элемент меньше), вредоносный код мог быть прочитан другой частью кода и прочитать слишком много данных. Вместо того, чтобы остановиться в конце этого значения, он может продолжить чтение других данных, которые ему не следует читать.
(Ссылка: ОмниРОМ Геррит)
2. [CVE-2015-1539]
Минимально возможный «размер» метаданных должен составлять 6 байт, поскольку это строка UTF-16. Код принимает размер целочисленного значения и вычитает из него 6. Если бы это значение было меньше 6, вычитание «опустилось бы» и завершилось бы, и в итоге мы получили бы очень большое число. Представьте себе, что вы можете считать только от 0 до 65535, например. Если вы возьмете число 4 и вычтете 6, вы не сможете опуститься ниже нуля. Итак, вы возвращаетесь к 65535 и начинаете считать оттуда. Вот что здесь происходит!
Если была получена длина менее 6, это могло привести к неправильному декодированию кадров, поскольку Процесс byteswap использует переменную len16, значение которой получается в результате вычислений, начинающихся с (размер-6). Это может привести к тому, что произойдет гораздо более масштабная операция подкачки, чем предполагалось, что приведет к неожиданному изменению значений в данных кадра.
(Ссылка: ОмниРОМ Геррит)
3. [CVE-2015-3824]
Важная персона! Этот противный. Есть полная противоположность последней проблеме — целочисленное переполнение, при котором целое число может стать «слишком большим». Если вы достигнете 65535 (например) и не сможете считать больше, вам придется перевернуться и перейти к 0 следующим!
Если вы распределяете память на основе этого (что и делает Stagefright!), в массиве будет выделено слишком мало памяти. Когда данные были помещены в него, они потенциально могли перезаписать несвязанные данные данными, контролируемыми создателем вредоносного файла.
(Ссылка: ОмниРОМ Геррит)
4. [CVE-2015-3826]
Еще одна неприятная штука! Очень похоже на последнее — еще одно целочисленное переполнение, при котором массив (используемый в качестве буфера) становится слишком маленьким. Это позволит перезаписать несвязанную память, что опять-таки плохо. Кто-то, кто может записывать данные в память, может повредить другие данные, не связанные с ними, и потенциально использовать это для запуска на вашем телефоне некоторого кода, который он контролирует.
(Ссылка: ОмниРОМ Геррит)
5. [CVE-2015-3827]
Очень похоже на эти последние. Переменная используется при пропуске некоторой памяти, и во время вычитания ее можно сделать отрицательной (как указано выше). Это приведет к очень большой длине «пропуска», переполнению буфера и предоставлению доступа к памяти, к которой не следует обращаться.
(Ссылка: ОмниРОМ Геррит)
Есть также некоторые (потенциально) связанные исправления, которые, похоже, вошли и в [Android] 5.1.
(Ссылка: ОмниРОМ Геррит)
Это добавляет проверки для предотвращения проблем с прошлым исправлением безопасности, а также добавляет проверки границ, которые сами по себе могут быть переполнены. В C числа, которые могут быть представлены как целое число со знаком, хранятся как целое число со знаком. В противном случае они остаются неизменными в процессе эксплуатации. В этих проверках некоторые целые числа можно было сделать знаковыми (а не беззнаковыми), что впоследствии уменьшило бы их максимальное значение и позволило бы произойти переполнение.
(Ссылка: ОмниРОМ Геррит)
Еще несколько целочисленных недополнений (когда числа слишком малы, а затем над этими числами выполняется вычитание, что позволяет им стать отрицательными). Это снова приводит к большому числу, а не к маленькому, и это вызывает те же проблемы, что и выше.
(Ссылка: ОмниРОМ Геррит)
И, наконец, еще одно целочисленное переполнение. Как и раньше, его собираются использовать где-то еще, и он может переполниться.
(Ссылка: ОмниРОМ Геррит)"
Насколько серьезен страх сцены?
В соответствии с Сообщение блога опубликованный материнской исследовательской компанией Zimperium Research Labs, эксплойт Stagefright потенциально подвергает 95% устройств Android (около 950 миллионов) подвержены этой уязвимости, поскольку она затрагивает устройства под управлением Android 2.2 и вверх. Что еще хуже, устройства до Jelly Bean 4.3 подвергаются «наибольшему риску», поскольку они не содержат адекватных средств защиты от этого эксплойта.
Что касается ущерба, который может нанести Stagefright, Pulser_g2 заметил:
[blockquoteauthor="pulser_g2"]"Сам по себе Stagefright предоставит доступ системному пользователю по телефону. Однако вам придется обойти ASLR (рандомизацию макета адресного пространства), чтобы фактически злоупотреблять им. Было ли это достигнуто, пока неизвестно. Этот эксплойт позволяет запускать «произвольный код» на вашем устройстве от имени пользователя системы или мультимедиа. У них есть доступ к аудио и камере на устройстве, а пользователь системы — отличное место для запуска корневого эксплойта. Помните все удивительные эксплойты, которые вы использовали для рутирования своего телефона?
Их потенциально можно использовать для получения root прав на вашем устройстве! У кого есть root, тот и владеет телефоном. Им пришлось бы обойти SELinux, но TowelRoot справился с этим, и PingPong тоже справился. Как только они получат root, все на вашем телефоне будет для них открыто. Сообщения, ключи и т. д.»[/blockquote]
Если говорить о наихудших сценариях, то для доставки кода и запуска этого эксплойта требуется только MMS. Пользователь даже не нужно открывать сообщение поскольку многие приложения для обмена сообщениями предварительно обрабатывают MMS перед тем, как пользователь с ним взаимодействует. Это отличается от атак целевого фишинга, поскольку пользователь может совершенно не обращать внимания на успешную атаку, ставя под угрозу все текущие и будущие данные в телефоне.
Что отличает Stagefright от других «массовых уязвимостей»?
«Все уязвимости представляют определенный риск для пользователей. Это особенно рискованно, поскольку, если кто-то найдет способ атаковать его удаленно (а это возможно, если бы был найден способ обойти ASLR), он может сработать еще до того, как вы поймете, что находитесь под угрозой. атака"
Старые эксплойты, такие как перехват установщика Android, FakeID, а также корневые эксплойты, такие как TowelRoot и PingPong, в какой-то момент требуют взаимодействия с пользователем для своего выполнения. Хотя они по-прежнему являются «эксплуатациями» в том смысле, что при их злонамеренном использовании может быть причинен большой вред, факт остается фактом: Stagefright теоретически нужен только номер мобильного телефона жертвы, чтобы превратить ее телефон в трояна, и поэтому в последнее время ему уделяется так много внимания. дни.
Однако Android не полностью зависит от этого эксплойта. Ведущий инженер по безопасности Android Адриан Людвиг высказал некоторые опасения в сообщение в Google+:
[blockquoteauthor="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, включая почти трехлетний Nexus 4. Samsung также последовала этому примеру, объявив, что будет работать с операторами связи и партнерами над внедрением ежемесячная программа обновлений безопасности но не удалось указать устройства и сроки реализации этой реализации. Это интересно, поскольку в нем упоминается «ускоренный» подход к обновлениям безопасности в сотрудничестве с операторами связи, чтобы мы могли ожидайте более частых обновлений (хотя и основанных на безопасности, но, надеюсь, это также ускорит обновление прошивки) от оператора связи устройства.
К пакету присоединяются и другие 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, после страха
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 у OEM-производителей.
Другой вариант, который может быть возможен, — сделать его обязательным для всех устройств, поставляемых с Google Play Store будет получать гарантированные обновления безопасности в течение фиксированного периода времени, возможно, двух годы. Платформу Play Services можно использовать для проверки наличия важных обновлений и исправлений безопасности, при этом доступ к Play Store будет закрыт в случае несоответствия.
Заключительные замечания
В лучшем случае это все еще предположение, поскольку не существует элегантного способа решить эту проблему. Если не использовать очень тоталитарный подход, всегда будут какие-то недостатки в возможности исправления ситуации. Из-за огромного количества Android-устройств отслеживание состояния безопасности каждого устройства будет очень сложной задачей. Насущной необходимостью является переосмысление способа обновления Android, поскольку нынешний способ, безусловно, не самый лучший. Мы в XDA Developers надеемся, что Android по-прежнему будет оставаться верным своим корням с открытым исходным кодом, работая вместе с планами Google с закрытым исходным кодом.
Ваш телефон уязвим для Stagefright? Как вы думаете, ваш телефон когда-нибудь получит патч Stagefright? Дайте нам знать в комментариях ниже!