Pull to refresh
28
0
Send message
>Всем устройствам для слежки требуется источник питания
Ну-ну.
unsigned char unsafe_images_vault [100500];
unsigned char kernel_security_settings [256];

//какой-то код

void verySecureFunction (size_t l)
{
    memcpy(kitty_image_with_shellcode_ptr, unsafe_images_vault, l);
}

Тестовое покрытие не учитывает состояние, разве нет? Если тесты покрывают эту функцию, это ничего в общем случае не говорит о состоянии в момент прохода, а в низкоуровневых языках (да и не только) фактический смысл кода может полностью изменяться при изменении состояния, как в примере выше. Если доступ к памяти никак не ограничивается, то вариантов будет околобесконечное количество для каждой функции, и все не протестируешь.
Тесты не покрывают все возможные пути выполнения обычно, а верификация покрывает. Это скорее можно сравнить с параллельным написанием программы на двух языках. Но в плане багов да.
>Злоумышленник
ИМХО верификация (по крайней мере, на текущем этапе) это больше о надежности, чем о безопасности. Начиная от хитрых физических эффектов типа Rowhammer, некоторые из которых обязательно забудут включить в модель; и заканчивая тем, что в самый первый раз верификатор запускается на неверифицированной системе, которая может быть за счет этого скомпрометирована и намеренно давать ложноположительные результаты (а париться с инкрементальной верификацией и начинать с человекопроверяемого уровня никто не станет). Плюс для верификации нужна сперва спецификация, которая, по сути, тоже код, потенциально содержащий ошибки. Плюс намеренные бэкдоры. Плюс зоопарк периферии и отсутствие контроля над ее производством. Так что это скорее актуально в случае какой-то узкоспециализированной системы, которую очень дорого или невозможно фиксить от багов, но на которую не проводится атак.
Мне казалось, что OTA апдейты там должны быть подписаны и сверяться по секретному ключу, зашитому в симку оператором (иначе почему в последнее время умерла тема клонирования симок? можно бы было юзать фейковую станцию для заливания апплета, выдающего KI наружу, вместо попыток его подобрать). Поправьте меня, если я ошибаюсь.
И он будет работать в Google, пока ему не исполнится 510 лет!
image
ИМХО. Я думаю, основная проблема здесь даже не реализация, потенциально допускающая злоупотребления этими данными со стороны оператора, а порочность такой концепции в целом, пока для логина разрешается использовать недоверенные устройства. Нет надежного способа проконтролировать, что кто-то логинится по лицу с голосом через смартфон, а не по их записи через рутованный смартфон или эмулятор. Проблемное место — не ростелекомовские сервера, не устройства добропорядочных юзеров, а именно эта возможность записи. Всякие случайные последовательности цифр, наклоны головы и прочее — только немного усложняют получение злоумышленником валидной записи, принципиально ничего не мешает скрытно записывать юзера достаточно долго, чтобы получить записи всех возможных вариантов и состряпать из них нечто, проходящее проверку. То есть, в случае пароля/токена юзеру достаточно не вводить/вставлять их куда попало, а если что — легко отозвать; в вашей схеме же появляется дополнительный большой геморрой для юзера по постоянной ежедневной защите неотзываемых биометрических данных (которые совсем не предназначены для этого, в отличие от пароля/токена!) от всех вокруг — никогда не садиться за недоверенные компьютеры с вебкамерой, не произносить чисел в публичных местах, надевать балаклаву в присутствии незнакомых людей — я утрирую, но суть понятна. Если юзер обнаружил, что смартфон, с которого он биометрически логинился несколько раз, скомпрометрирован, то юзер может тушить свет и переводить все деньги в заграничные банки, которые не дадут злоумышленнику их снять по биометрии, так, что ли? Дальше это все будут успешно эксплуатировать, юзеры будут бузить, вам придется ставить костыли, чтобы хотя бы поломать рабочие методы фейковой аутентификации, и в итоге это все окажется дороже, чем выдавать каждому вместе с паспортом токен с неизвлекаемым ключом.
Дух Машины есть частица воли Омниссии, дарованная как благословение. Очевидно же.
ЕМНИП, там был не настоящий Computrace, а именно какой-то их собственный дроппер, который работал по аналогичной схеме (копировался из BIOS в системную папку), но вместо агента отслеживания устанавливал всяческие непотребства типа «системного оптимизатора».
Про cache miss было еще у Носова:
Снова спустились с лестницы, и Петя начал сначала:

— Одна, две, три, четыре, пять…

— Может быть, двадцать пять? — спрашивает Валя.

— Да нет! Только думать мешаешь! Вот видишь, из-за тебя забыл! Придется опять сначала.
Если погрузиться в конспирологию, то вряд ли ME является наиболее привлекательной целью для намеренного размещения бэкдоров. Код полноценно не зашифрован, универсален, а его объем сравнительно небольшой, так что если разместить там что-то очевидно вредоносное, то кто-нибудь в итоге это отреверсит, и будет большой конфуз, разбирательства, финансовые потери. Для Intel это такой гигантский риск, что просто настойчивого пожелания спецслужб будет недостаточно, думаю. Если же разместить просто уязвимость, которую потом если что можно позиционировать как непреднамеренную ошибку, то система не будет из коробки готова к служению большому брату, а типичная эксплуатация таких уязвимостей подразумевает, что для этого сперва нужно получить как минимум локальный доступ. То есть последующая персистентность остается практически единственным профитом, а геморроя довольно много (у ME физически не хватит ресурсов на полноценный шпионаж за основной системой в реальном времени, придется сопрягать их, да еще и беспалевно...). Если градус предполагаемой слежки оправдывает такие сложности, то логичнее предположить что-то эдакое в действительно зашифрованном микрокоде или вообще на железе, особенно с учетом последних исследований @xoreaxeaxeax.
Я думаю, тут граница очень расплывчатая, и при желании можно по-разному трактовать, ибо «информация это сведения/сообщения/данные» из 149-ФЗ — весьма туманное определение. Обычно к коду прилагаются какие-то конфиги или хотя бы константы, которые можно при желании трактовать как данные. Кроме того, будет ли информацией дамп псевдослучайных байтов из /dev/random? А если он использовался в качестве гаммы для «настоящей» информации? А если кто-то постфактум заXORит шифротекст из нее и данных соответствующей длины и таким образом «превратит ее в гамму»? А если брать не случайную последовательность из /dev/random, а сам машинный код программы? Четкая граница между такими тонкими деталями вряд ли будет проведена в каком-нибудь законе, можно максимум смотреть на прецеденты.
Вероятно, информация из этого файла периодически как-то используется, иначе бы не было смысла его создавать. Файл лежит в AppData, значит, работа с ним скорее всего не делегирована привилегированным системным процессам. Тогда процессы пользователя сами периодически должны бы были расшифровывать информацию, и у них легко бы было перехватить ключ. Но даже если бы шифрованием занималась система, выдавая расшифрованную информацию пользовательским процессам по требованию, отличить легитимное считывание от нелегитимного весьма сложно (особенно, если учесть, что там в первую очередь Office, в котором VBA и прочие непотребства). В общем, в простейшем случае такой защиты злоумышленник бы просто считал ключ шифрования из реестра, или где бы он там хранился; а в случае делегирования шифрования системе — запросил бы считывание информации у нее.

Остается еще вариант, при котором тексты только зашифровываются для отправки в АНБ, а пользователь потом не имеет к ним доступа, но этим вроде бы DiagTrack занимается, а не служба индексирования.
>создать нормальную архитектуру, без этих вот извращений
image
[sarcasm]
>Information you reported is not considered a security vulnerability, since access rights are not considered a security feature.
[/sarcasm]
Насколько я понимаю, можно использовать и независимо без проблем (хотя я не пробовал). По сути, там для интеграции просто скрипт прописывает нужные пути в конфиги VS.
Я, наверное, сейчас скажу крамолу, но vcpkg под Windows за последние несколько лет прошел неплохой путь, и C++-библиотеки (если вам нужно не что-то совсем экзотическое) ставятся не сложнее, чем в *nix, в пару кликов. Так что, имхо, прогресс в плане «менеджера пакетов нет» все же есть.

Information

Rating
Does not participate
Registered
Activity