В Instagram нашли уязвимость, связанную с обработкой изображений



    Специалисты компании Check Point рассказали о найденной в начале этого года серьезной уязвимости в мобильном приложении Instagram для iOS и Android. Злоумышленники могли с помощью уязвимости CVE-2020-1895 получить практически полный доступ к смартфону жертвы, запустив на атакуемой системе удаленное выполнение произвольного кода. Все что им было нужно для этого — отправить пользователю картинку с вредоносным кодом и специально созданными размерами. Далее штатный алгоритм обработки изображений приложения Instagram использовался для успешного проведения атаки, основанной на переполнении кучи/хипа (heap buffer overflow).

    Уязвимость CVE-2020-1895 была обнаружена Check Point в начале этого года. Ей были подвержены версии приложения Instagram вплоть до 128.0.0.26.128.

    Расследование Check Point с помощью фаззинга показало, что разработчики Instagram неправильно использовали сторонний инструмент MozJPEG (открытый декодер JPEG от Mozilla).

    Оказалось, что в приложении Instagram код обработчика этого инструмента имел свои ограничения. В нем можно было вызвать целочисленное переполнение, если приложение пытается обработать и открыть изображение большего размера, считая его меньшим — ранее полученную и сохраненную пользователем на смартфон вредоносную картинку со специально заданными размерами.

    Примечательно, что у злоумышленника было два варианта дальнейшей атаки после запуска вредоносного кода после использования уязвимости:

    • получение информации со смартфона, включая просмотр и копирование контактов и сообщений, данных о местоположении пользователя и доступ к управлению камерой — все элементы и сервисы смартфона, к которым имело доступ приложение Instagram;
    • вызов непрерывного сбоя приложения Instagram при запуске, после удаления и переустановки приложения через некоторое время сбой можно вызвать снова.

    В феврале 2020 года специалисты Facebook выпустили новые версии мобильных приложений Instagram с патчем против уязвимости CVE-2020-1895.

    В середине сентября 2020 года Microsoft выпустила новый автоматизированный инструмент для разработчиков — Project OneFuzz. Это фаззинг решение в настоящее время уже заменило сервис Microsoft Security Risk Detection Service. Исходные коды инструмента Project OneFuzz уже доступны на GitHub под лицензией MIT, включая документацию и примеры.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 12

      +3
      Как-то фейсбуку постоянно «везет» на такие крупные уязвимости. Иногда даже кажется, что они специально это делают.
        +3

        Вряд ли "специально" — если подразумевается "требование создать дыру включено в ТЗ на разработку". Но если подразумевается "у нас в компании так выстроены процессы, что появление таких уязвимостей это неизбежное следствие и нас это устраивает" — да, думаю тогда вполне можно сказать, что "специально".

            0

            Ну, я посмотрел CVE на Signal — их мало, и ни один пока на backdoor не похож. Подождём ещё пару лет, конечно, проверим какой из Дурова предсказатель.


            Что до попыток подкупа разработчиков — то да, это известная история, спецслужбы США не раз пытались, с переменным успехом, внедрять закладки в разных софт (включая, если не путаю, ядро Linux и OpenBSD). Проблема в том, что обычно есть процесс ревью, так что подкупить нужно и разработчика, и ревьювера — просто чтобы это изменение смержили. Плюс нередко спустя некоторое время этот код всё-равно обнаруживают и удаляют, да ещё и расследуют "кто это сделал?!". В общем, спецслужбы просто делают свою работу, и их сложно за это винить. Но я не думаю, что у них достаточно высокий процент успеха в этом деле, чтобы нам реально стоило об этом беспокоиться — слишком это сложный и ненадёжный процесс, внедрять закладки так, чтобы компания-владелец (для закрытого софта) либо коммьюнити (для открытого софта) это пропустили.


            Меня в этом плане гораздо сильнее напрягаю законы Австралии (и их софта вроде JIRA), которые требуют от компаний внедрять backdoor-ы вполне официально, и при этом запрещают им разглашать этот факт. Вот когда такие законы примут в США — тогда реально использовать не-опенсорс (хз как такие законы скажутся на нём, но туда внедрять явно будет намного сложнее, особенно — незаметно) станет стрёмно.

              +1
              В общем, спецслужбы просто делают свою работу, и их сложно за это винить
              Вы это серьёзно, простите? Сложно их винить за коррупцию и внедрение закладок с целью шпионажа?

              которые требуют от компаний внедрять backdoor-ы вполне официально, и при этом запрещают им разглашать этот факт
              EARN IT Act, поддерживаемый Джо Байденом, подходит?

              Весьма забавно, кстати, учитывая, что ранее пытались ввести совершенно противоположный Secure Data Act 2018.
                +1
                Сложно их винить за коррупцию и внедрение закладок с целью шпионажа?

                Да. Их существование и методы во многом порождены нашим обществом, поэтому винить их в том, что они такие — несколько лицемерно. Ниже я ответил более подробно.


                EARN IT Act, поддерживаемый Джо Байденом, подходит?

                Не уверен. Он про другое, а запрет E2E шифрования к нему притягивают сильно за уши, по сути — в данный момент это просто спекуляция. Плюс к тому между запретом E2E и требованием встраивать бэкдоры — есть существенная разница.

                +2
                В общем, спецслужбы просто делают свою работу, и их сложно за это винить.

                Это так и о киллере, к примеру, можно сказать или наркоторговце, просто делают свою работу.
                  +2

                  Не совсем. Киллеры и наркоторговцы — это частная инициатива, их личное решение и их личная ответственность. А в существовании спецслужб и их стиле работы винить конкретно некого — по крайней мере если в государстве не диктатура. Если смотреть наивно — то винить в этом можно голосующее население, которое выбрало такое правительство, которое приняло соответствующие законы и организовало работу спец.служб именно таким образом. Если смотреть реалистично — человеческая природа такова, что мирно и дружно жить не хочет, поэтому если у нашей страны не будет своих спец.служб действующих грязными методами, то другие страны с удовольствием этим воспользуются, и станет ли населению нашей страны от этого лучше — не очевидно. Плюс уровень реального влияния на политику и законы этого самого голосующего населения, даже в формально демократических странах, тоже не очень очевиден.


                  В целом, на мой взгляд, эту тему обсуждать бессмысленно, и особо не уместно делать это на хабре, так что предлагаю вернуться к более техническим вопросам, на которые мы можем влиять (в отличие от используемых спец.службами методов работы) — напр. как стоит выстраивать процессы в компаниях и опенсорсе чтобы максимально усложнить спец.службам внедрение закладок.


                  Я уже упоминал выше процесс ревью, но к нему стоит так же добавить появление инструментов, которые занимаются автоматическим поиском и информированием об уязвимостях — напр. Dependabot гитхабовский умеет делать такое (сопровождая это еженедельными напоминаниями по почте):

                  Плюс к этому у гитхаба сейчас в бете CodeQL, занимающийся сканированием кода на уязвимости. Ещё, например, в Go есть линтеры, которые тоже отслеживают потенциальные уязвимости в коде, и которые обычно даже отдельно устанавливать не нужно, т.к. они уже включены в самый популярный линтер — т.е. любой проект использующий линтер и исповедующий политику "по умолчанию все проверки линтера должны быть включены, а выключать будем только конкретные и по веским причинам" уже их использует.


                  Если не лениться подключать все эти инструменты, причём поставить процессы так, чтобы это делалось в начале работы над любым проектом — внедрять уязвимости "специально" станет заметно сложнее.

          +3

          Не ясно как "переполнение кучи" трансформируется в "почти полный доступ к телефону". Так же не понятно пережатие мессенджерами удаляло вредоносность картинки или же нет.

            0

            Большинство переполнений обычно в конечном итоге приводят к возможности выполнить собственный код (который, вероятно, лежал рядом в этой же картинке) — что обычно даёт полный доступ, ограниченный только правами того приложения, в котором дыра.

              +9
              По моему опыту — как раз наоборот.
              Дырень еще надо раскрутить до состояния рабочего RCE.
              Невозможность сделать удачный heap grooming еще никто не отменял.
              Необходимость в обходе ASLR — тоже.
              А еще нередко бывают переполнения стека на 1 байт, которого хватает на то, чтобы испортить stack cookie, но не более.
              0
              Ну потому что иначе статью никто читать не будет. Ибо далее в тексте
              Примечательно, что у злоумышленника было два варианта дальнейшей атаки после запуска вредоносного кода после использования уязвимости:

              получение информации со смартфона, включая просмотр и копирование контактов и сообщений, данных о местоположении пользователя и доступ к управлению камерой — все элементы и сервисы смартфона, к которым имело доступ приложение Instagram;
              вызов непрерывного сбоя приложения Instagram при запуске, после удаления и переустановки приложения через некоторое время сбой можно вызвать снова.


              Т.е. выполнение стороннего кода в пределах песочницы приложения либо поломка приложения.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое