Comments 12
Вряд ли "специально" — если подразумевается "требование создать дыру включено в ТЗ на разработку". Но если подразумевается "у нас в компании так выстроены процессы, что появление таких уязвимостей это неизбежное следствие и нас это устраивает" — да, думаю тогда вполне можно сказать, что "специально".
Ну, я посмотрел CVE на Signal — их мало, и ни один пока на backdoor не похож. Подождём ещё пару лет, конечно, проверим какой из Дурова предсказатель.
Что до попыток подкупа разработчиков — то да, это известная история, спецслужбы США не раз пытались, с переменным успехом, внедрять закладки в разных софт (включая, если не путаю, ядро Linux и OpenBSD). Проблема в том, что обычно есть процесс ревью, так что подкупить нужно и разработчика, и ревьювера — просто чтобы это изменение смержили. Плюс нередко спустя некоторое время этот код всё-равно обнаруживают и удаляют, да ещё и расследуют "кто это сделал?!". В общем, спецслужбы просто делают свою работу, и их сложно за это винить. Но я не думаю, что у них достаточно высокий процент успеха в этом деле, чтобы нам реально стоило об этом беспокоиться — слишком это сложный и ненадёжный процесс, внедрять закладки так, чтобы компания-владелец (для закрытого софта) либо коммьюнити (для открытого софта) это пропустили.
Меня в этом плане гораздо сильнее напрягаю законы Австралии (и их софта вроде JIRA), которые требуют от компаний внедрять backdoor-ы вполне официально, и при этом запрещают им разглашать этот факт. Вот когда такие законы примут в США — тогда реально использовать не-опенсорс (хз как такие законы скажутся на нём, но туда внедрять явно будет намного сложнее, особенно — незаметно) станет стрёмно.
В общем, спецслужбы просто делают свою работу, и их сложно за это винитьВы это серьёзно, простите? Сложно их винить за коррупцию и внедрение закладок с целью шпионажа?
которые требуют от компаний внедрять backdoor-ы вполне официально, и при этом запрещают им разглашать этот фактEARN IT Act, поддерживаемый Джо Байденом, подходит?
Весьма забавно, кстати, учитывая, что ранее пытались ввести совершенно противоположный Secure Data Act 2018.
Сложно их винить за коррупцию и внедрение закладок с целью шпионажа?
Да. Их существование и методы во многом порождены нашим обществом, поэтому винить их в том, что они такие — несколько лицемерно. Ниже я ответил более подробно.
EARN IT Act, поддерживаемый Джо Байденом, подходит?
Не уверен. Он про другое, а запрет E2E шифрования к нему притягивают сильно за уши, по сути — в данный момент это просто спекуляция. Плюс к тому между запретом E2E и требованием встраивать бэкдоры — есть существенная разница.
В общем, спецслужбы просто делают свою работу, и их сложно за это винить.
Это так и о киллере, к примеру, можно сказать или наркоторговце, просто делают свою работу.
Не совсем. Киллеры и наркоторговцы — это частная инициатива, их личное решение и их личная ответственность. А в существовании спецслужб и их стиле работы винить конкретно некого — по крайней мере если в государстве не диктатура. Если смотреть наивно — то винить в этом можно голосующее население, которое выбрало такое правительство, которое приняло соответствующие законы и организовало работу спец.служб именно таким образом. Если смотреть реалистично — человеческая природа такова, что мирно и дружно жить не хочет, поэтому если у нашей страны не будет своих спец.служб действующих грязными методами, то другие страны с удовольствием этим воспользуются, и станет ли населению нашей страны от этого лучше — не очевидно. Плюс уровень реального влияния на политику и законы этого самого голосующего населения, даже в формально демократических странах, тоже не очень очевиден.
В целом, на мой взгляд, эту тему обсуждать бессмысленно, и особо не уместно делать это на хабре, так что предлагаю вернуться к более техническим вопросам, на которые мы можем влиять (в отличие от используемых спец.службами методов работы) — напр. как стоит выстраивать процессы в компаниях и опенсорсе чтобы максимально усложнить спец.службам внедрение закладок.
Я уже упоминал выше процесс ревью, но к нему стоит так же добавить появление инструментов, которые занимаются автоматическим поиском и информированием об уязвимостях — напр. Dependabot гитхабовский умеет делать такое (сопровождая это еженедельными напоминаниями по почте):
Плюс к этому у гитхаба сейчас в бете CodeQL, занимающийся сканированием кода на уязвимости. Ещё, например, в Go есть линтеры, которые тоже отслеживают потенциальные уязвимости в коде, и которые обычно даже отдельно устанавливать не нужно, т.к. они уже включены в самый популярный линтер — т.е. любой проект использующий линтер и исповедующий политику "по умолчанию все проверки линтера должны быть включены, а выключать будем только конкретные и по веским причинам" уже их использует.
Если не лениться подключать все эти инструменты, причём поставить процессы так, чтобы это делалось в начале работы над любым проектом — внедрять уязвимости "специально" станет заметно сложнее.
Не ясно как "переполнение кучи" трансформируется в "почти полный доступ к телефону". Так же не понятно пережатие мессенджерами удаляло вредоносность картинки или же нет.
Большинство переполнений обычно в конечном итоге приводят к возможности выполнить собственный код (который, вероятно, лежал рядом в этой же картинке) — что обычно даёт полный доступ, ограниченный только правами того приложения, в котором дыра.
Дырень еще надо раскрутить до состояния рабочего RCE.
Невозможность сделать удачный heap grooming еще никто не отменял.
Необходимость в обходе ASLR — тоже.
А еще нередко бывают переполнения стека на 1 байт, которого хватает на то, чтобы испортить stack cookie, но не более.
Примечательно, что у злоумышленника было два варианта дальнейшей атаки после запуска вредоносного кода после использования уязвимости:
получение информации со смартфона, включая просмотр и копирование контактов и сообщений, данных о местоположении пользователя и доступ к управлению камерой — все элементы и сервисы смартфона, к которым имело доступ приложение Instagram;
вызов непрерывного сбоя приложения Instagram при запуске, после удаления и переустановки приложения через некоторое время сбой можно вызвать снова.
Т.е. выполнение стороннего кода в пределах песочницы приложения либо поломка приложения.
В Instagram нашли уязвимость, связанную с обработкой изображений