Тестовое покрытие не учитывает состояние, разве нет? Если тесты покрывают эту функцию, это ничего в общем случае не говорит о состоянии в момент прохода, а в низкоуровневых языках (да и не только) фактический смысл кода может полностью изменяться при изменении состояния, как в примере выше. Если доступ к памяти никак не ограничивается, то вариантов будет околобесконечное количество для каждой функции, и все не протестируешь.
Тесты не покрывают все возможные пути выполнения обычно, а верификация покрывает. Это скорее можно сравнить с параллельным написанием программы на двух языках. Но в плане багов да.
>Злоумышленник
ИМХО верификация (по крайней мере, на текущем этапе) это больше о надежности, чем о безопасности. Начиная от хитрых физических эффектов типа Rowhammer, некоторые из которых обязательно забудут включить в модель; и заканчивая тем, что в самый первый раз верификатор запускается на неверифицированной системе, которая может быть за счет этого скомпрометирована и намеренно давать ложноположительные результаты (а париться с инкрементальной верификацией и начинать с человекопроверяемого уровня никто не станет). Плюс для верификации нужна сперва спецификация, которая, по сути, тоже код, потенциально содержащий ошибки. Плюс намеренные бэкдоры. Плюс зоопарк периферии и отсутствие контроля над ее производством. Так что это скорее актуально в случае какой-то узкоспециализированной системы, которую очень дорого или невозможно фиксить от багов, но на которую не проводится атак.
Мне казалось, что OTA апдейты там должны быть подписаны и сверяться по секретному ключу, зашитому в симку оператором (иначе почему в последнее время умерла тема клонирования симок? можно бы было юзать фейковую станцию для заливания апплета, выдающего KI наружу, вместо попыток его подобрать). Поправьте меня, если я ошибаюсь.
ИМХО. Я думаю, основная проблема здесь даже не реализация, потенциально допускающая злоупотребления этими данными со стороны оператора, а порочность такой концепции в целом, пока для логина разрешается использовать недоверенные устройства. Нет надежного способа проконтролировать, что кто-то логинится по лицу с голосом через смартфон, а не по их записи через рутованный смартфон или эмулятор. Проблемное место — не ростелекомовские сервера, не устройства добропорядочных юзеров, а именно эта возможность записи. Всякие случайные последовательности цифр, наклоны головы и прочее — только немного усложняют получение злоумышленником валидной записи, принципиально ничего не мешает скрытно записывать юзера достаточно долго, чтобы получить записи всех возможных вариантов и состряпать из них нечто, проходящее проверку. То есть, в случае пароля/токена юзеру достаточно не вводить/вставлять их куда попало, а если что — легко отозвать; в вашей схеме же появляется дополнительный большой геморрой для юзера по постоянной ежедневной защите неотзываемых биометрических данных (которые совсем не предназначены для этого, в отличие от пароля/токена!) от всех вокруг — никогда не садиться за недоверенные компьютеры с вебкамерой, не произносить чисел в публичных местах, надевать балаклаву в присутствии незнакомых людей — я утрирую, но суть понятна. Если юзер обнаружил, что смартфон, с которого он биометрически логинился несколько раз, скомпрометрирован, то юзер может тушить свет и переводить все деньги в заграничные банки, которые не дадут злоумышленнику их снять по биометрии, так, что ли? Дальше это все будут успешно эксплуатировать, юзеры будут бузить, вам придется ставить костыли, чтобы хотя бы поломать рабочие методы фейковой аутентификации, и в итоге это все окажется дороже, чем выдавать каждому вместе с паспортом токен с неизвлекаемым ключом.
Меня немного раздражает 'вседозволенность' программ, когда они прописывают себя не только в автозагрузке, но и пускают корни в службах, реестре и планировщике задач, замедляя компьютер своими непонятными процессами.
Видимо, я уже привык, что на телефоне приложения назойливо запрашивают доступ к данным и функциям системы («разрешить доступ к Фото/Камере/Микрофону/Геопозиции»).
Так сложилось исторически. Под Windows написано огромное количество софта во времена, когда о таких аспектах безопасности попросту не думали и писали кто как захочет. Этот софт никогда не будет переписан по современным канонам, так что остается всего два варианта: либо поломать совместимость в угоду безопасности, либо худо-бедно поддерживать все написанное. В Windows выбран путь, близкий ко второму варианту (поддерживать все, кроме совсем вопиющих и древних вещей, очень медленно закручивая гайки по мере отказа пользователей от старых приложений). Понятно, что граница нечеткая, можно было бы закрутить гайки сразу и посильнее, но тогда получится что-то типа www.sandboxie.com/KnownConflicts (и тут только относительно популярные приложения), а вы же сами упомянули, что, как простой юзер, хотите не регулярно ковыряться в настройках, заставляя работать старую программу, а чтобы просто все работало с минимальными телодвижениями. Для большинства конечных пользователей Windows безопасность — это если не пустой звук, то что-то явно менее важное, чем возможность запуска конкретного софта, с которым они привыкли работать. И они такие изменения посчитают не благом, а посягательством (как в упомянутом выше случае с UAC).
А на телефонах софт в любом случае почти целиком писался гораздо позже и заново, даже если по существу портировался, и можно было просто изначально ввести более жесткие правила, встроенные песочницы, что угодно, и новый софт после этого писался в новых рамках или не писался вообще.
Если есть простая штатная возможность организовать более безопасную среду, буду рад, если подскажете как это сделать!
Если у вас достаточно современное железо, то наименее проблемным способом будут виртуальные машины (Hyper-V есть в последних версиях Windows, так что возможность практически штатная, а если использовать на хосте, например, QubesOS, то это будет по удобству работы почти как песочницы). Если нет, и у вас немного Windows-only софта, то проще всего, наверное, найти аналоги и перейти на другую ОС, ибо в Windows с песочницами время от времени в любом случае придется ковыряться. Если Windows-only софта много, то можно отделить доверенный софт (браузер с важными аккаунтами, офис и всякое такое) на отдельный физический компьютер, на котором не запускать ничего кроме них, а на другом компьютере с маловажными данными просто расслабиться и получать удовольствие.
ЕМНИП, там был не настоящий Computrace, а именно какой-то их собственный дроппер, который работал по аналогичной схеме (копировался из BIOS в системную папку), но вместо агента отслеживания устанавливал всяческие непотребства типа «системного оптимизатора».
Если погрузиться в конспирологию, то вряд ли ME является наиболее привлекательной целью для намеренного размещения бэкдоров. Код полноценно не зашифрован, универсален, а его объем сравнительно небольшой, так что если разместить там что-то очевидно вредоносное, то кто-нибудь в итоге это отреверсит, и будет большой конфуз, разбирательства, финансовые потери. Для Intel это такой гигантский риск, что просто настойчивого пожелания спецслужб будет недостаточно, думаю. Если же разместить просто уязвимость, которую потом если что можно позиционировать как непреднамеренную ошибку, то система не будет из коробки готова к служению большому брату, а типичная эксплуатация таких уязвимостей подразумевает, что для этого сперва нужно получить как минимум локальный доступ. То есть последующая персистентность остается практически единственным профитом, а геморроя довольно много (у ME физически не хватит ресурсов на полноценный шпионаж за основной системой в реальном времени, придется сопрягать их, да еще и беспалевно...). Если градус предполагаемой слежки оправдывает такие сложности, то логичнее предположить что-то эдакое в действительно зашифрованном микрокоде или вообще на железе, особенно с учетом последних исследований @xoreaxeaxeax.
Я думаю, тут граница очень расплывчатая, и при желании можно по-разному трактовать, ибо «информация это сведения/сообщения/данные» из 149-ФЗ — весьма туманное определение. Обычно к коду прилагаются какие-то конфиги или хотя бы константы, которые можно при желании трактовать как данные. Кроме того, будет ли информацией дамп псевдослучайных байтов из /dev/random? А если он использовался в качестве гаммы для «настоящей» информации? А если кто-то постфактум заXORит шифротекст из нее и данных соответствующей длины и таким образом «превратит ее в гамму»? А если брать не случайную последовательность из /dev/random, а сам машинный код программы? Четкая граница между такими тонкими деталями вряд ли будет проведена в каком-нибудь законе, можно максимум смотреть на прецеденты.
Вероятно, информация из этого файла периодически как-то используется, иначе бы не было смысла его создавать. Файл лежит в AppData, значит, работа с ним скорее всего не делегирована привилегированным системным процессам. Тогда процессы пользователя сами периодически должны бы были расшифровывать информацию, и у них легко бы было перехватить ключ. Но даже если бы шифрованием занималась система, выдавая расшифрованную информацию пользовательским процессам по требованию, отличить легитимное считывание от нелегитимного весьма сложно (особенно, если учесть, что там в первую очередь Office, в котором VBA и прочие непотребства). В общем, в простейшем случае такой защиты злоумышленник бы просто считал ключ шифрования из реестра, или где бы он там хранился; а в случае делегирования шифрования системе — запросил бы считывание информации у нее.
Остается еще вариант, при котором тексты только зашифровываются для отправки в АНБ, а пользователь потом не имеет к ним доступа, но этим вроде бы DiagTrack занимается, а не служба индексирования.
Насколько я понимаю, можно использовать и независимо без проблем (хотя я не пробовал). По сути, там для интеграции просто скрипт прописывает нужные пути в конфиги VS.
Ну-ну.
Тестовое покрытие не учитывает состояние, разве нет? Если тесты покрывают эту функцию, это ничего в общем случае не говорит о состоянии в момент прохода, а в низкоуровневых языках (да и не только) фактический смысл кода может полностью изменяться при изменении состояния, как в примере выше. Если доступ к памяти никак не ограничивается, то вариантов будет околобесконечное количество для каждой функции, и все не протестируешь.
ИМХО верификация (по крайней мере, на текущем этапе) это больше о надежности, чем о безопасности. Начиная от хитрых физических эффектов типа Rowhammer, некоторые из которых обязательно забудут включить в модель; и заканчивая тем, что в самый первый раз верификатор запускается на неверифицированной системе, которая может быть за счет этого скомпрометирована и намеренно давать ложноположительные результаты (а париться с инкрементальной верификацией и начинать с человекопроверяемого уровня никто не станет). Плюс для верификации нужна сперва спецификация, которая, по сути, тоже код, потенциально содержащий ошибки. Плюс намеренные бэкдоры. Плюс зоопарк периферии и отсутствие контроля над ее производством. Так что это скорее актуально в случае какой-то узкоспециализированной системы, которую очень дорого или невозможно фиксить от багов, но на которую не проводится атак.
Так сложилось исторически. Под Windows написано огромное количество софта во времена, когда о таких аспектах безопасности попросту не думали и писали кто как захочет. Этот софт никогда не будет переписан по современным канонам, так что остается всего два варианта: либо поломать совместимость в угоду безопасности, либо худо-бедно поддерживать все написанное. В Windows выбран путь, близкий ко второму варианту (поддерживать все, кроме совсем вопиющих и древних вещей, очень медленно закручивая гайки по мере отказа пользователей от старых приложений). Понятно, что граница нечеткая, можно было бы закрутить гайки сразу и посильнее, но тогда получится что-то типа www.sandboxie.com/KnownConflicts (и тут только относительно популярные приложения), а вы же сами упомянули, что, как простой юзер, хотите не регулярно ковыряться в настройках, заставляя работать старую программу, а чтобы просто все работало с минимальными телодвижениями. Для большинства конечных пользователей Windows безопасность — это если не пустой звук, то что-то явно менее важное, чем возможность запуска конкретного софта, с которым они привыкли работать. И они такие изменения посчитают не благом, а посягательством (как в упомянутом выше случае с UAC).
А на телефонах софт в любом случае почти целиком писался гораздо позже и заново, даже если по существу портировался, и можно было просто изначально ввести более жесткие правила, встроенные песочницы, что угодно, и новый софт после этого писался в новых рамках или не писался вообще.
Если у вас достаточно современное железо, то наименее проблемным способом будут виртуальные машины (Hyper-V есть в последних версиях Windows, так что возможность практически штатная, а если использовать на хосте, например, QubesOS, то это будет по удобству работы почти как песочницы). Если нет, и у вас немного Windows-only софта, то проще всего, наверное, найти аналоги и перейти на другую ОС, ибо в Windows с песочницами время от времени в любом случае придется ковыряться. Если Windows-only софта много, то можно отделить доверенный софт (браузер с важными аккаунтами, офис и всякое такое) на отдельный физический компьютер, на котором не запускать ничего кроме них, а на другом компьютере с маловажными данными просто расслабиться и получать удовольствие.
Остается еще вариант, при котором тексты только зашифровываются
для отправки в АНБ, а пользователь потом не имеет к ним доступа, но этим вроде бы DiagTrack занимается, а не служба индексирования.>Information you reported is not considered a security vulnerability, since access rights are not considered a security feature.
[/sarcasm]