Специалисты компании 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, включая документацию и примеры.
v1000
Как-то фейсбуку постоянно «везет» на такие крупные уязвимости. Иногда даже кажется, что они специально это делают.
powerman
Вряд ли "специально" — если подразумевается "требование создать дыру включено в ТЗ на разработку". Но если подразумевается "у нас в компании так выстроены процессы, что появление таких уязвимостей это неизбежное следствие и нас это устраивает" — да, думаю тогда вполне можно сказать, что "специально".
bgBrother
Или "разработчиков нашей компании заставили добавить уязвимость".
powerman
Ну, я посмотрел CVE на Signal — их мало, и ни один пока на backdoor не похож. Подождём ещё пару лет, конечно, проверим какой из Дурова предсказатель.
Что до попыток подкупа разработчиков — то да, это известная история, спецслужбы США не раз пытались, с переменным успехом, внедрять закладки в разных софт (включая, если не путаю, ядро Linux и OpenBSD). Проблема в том, что обычно есть процесс ревью, так что подкупить нужно и разработчика, и ревьювера — просто чтобы это изменение смержили. Плюс нередко спустя некоторое время этот код всё-равно обнаруживают и удаляют, да ещё и расследуют "кто это сделал?!". В общем, спецслужбы просто делают свою работу, и их сложно за это винить. Но я не думаю, что у них достаточно высокий процент успеха в этом деле, чтобы нам реально стоило об этом беспокоиться — слишком это сложный и ненадёжный процесс, внедрять закладки так, чтобы компания-владелец (для закрытого софта) либо коммьюнити (для открытого софта) это пропустили.
Меня в этом плане гораздо сильнее напрягаю законы Австралии (и их софта вроде JIRA), которые требуют от компаний внедрять backdoor-ы вполне официально, и при этом запрещают им разглашать этот факт. Вот когда такие законы примут в США — тогда реально использовать не-опенсорс (хз как такие законы скажутся на нём, но туда внедрять явно будет намного сложнее, особенно — незаметно) станет стрёмно.
bgBrother
EARN IT Act, поддерживаемый Джо Байденом, подходит?
Весьма забавно, кстати, учитывая, что ранее пытались ввести совершенно противоположный Secure Data Act 2018.
powerman
Да. Их существование и методы во многом порождены нашим обществом, поэтому винить их в том, что они такие — несколько лицемерно. Ниже я ответил более подробно.
Не уверен. Он про другое, а запрет E2E шифрования к нему притягивают сильно за уши, по сути — в данный момент это просто спекуляция. Плюс к тому между запретом E2E и требованием встраивать бэкдоры — есть существенная разница.
Firz
Это так и о киллере, к примеру, можно сказать или наркоторговце, просто делают свою работу.
powerman
Не совсем. Киллеры и наркоторговцы — это частная инициатива, их личное решение и их личная ответственность. А в существовании спецслужб и их стиле работы винить конкретно некого — по крайней мере если в государстве не диктатура. Если смотреть наивно — то винить в этом можно голосующее население, которое выбрало такое правительство, которое приняло соответствующие законы и организовало работу спец.служб именно таким образом. Если смотреть реалистично — человеческая природа такова, что мирно и дружно жить не хочет, поэтому если у нашей страны не будет своих спец.служб действующих грязными методами, то другие страны с удовольствием этим воспользуются, и станет ли населению нашей страны от этого лучше — не очевидно. Плюс уровень реального влияния на политику и законы этого самого голосующего населения, даже в формально демократических странах, тоже не очень очевиден.
В целом, на мой взгляд, эту тему обсуждать бессмысленно, и особо не уместно делать это на хабре, так что предлагаю вернуться к более техническим вопросам, на которые мы можем влиять (в отличие от используемых спец.службами методов работы) — напр. как стоит выстраивать процессы в компаниях и опенсорсе чтобы максимально усложнить спец.службам внедрение закладок.
Я уже упоминал выше процесс ревью, но к нему стоит так же добавить появление инструментов, которые занимаются автоматическим поиском и информированием об уязвимостях — напр. Dependabot гитхабовский умеет делать такое (сопровождая это еженедельными напоминаниями по почте):
Плюс к этому у гитхаба сейчас в бете CodeQL, занимающийся сканированием кода на уязвимости. Ещё, например, в Go есть линтеры, которые тоже отслеживают потенциальные уязвимости в коде, и которые обычно даже отдельно устанавливать не нужно, т.к. они уже включены в самый популярный линтер — т.е. любой проект использующий линтер и исповедующий политику "по умолчанию все проверки линтера должны быть включены, а выключать будем только конкретные и по веским причинам" уже их использует.
Если не лениться подключать все эти инструменты, причём поставить процессы так, чтобы это делалось в начале работы над любым проектом — внедрять уязвимости "специально" станет заметно сложнее.