среда, 14 октября 2009 г.

Задавая вопросы, ответ на которые всё равно ненадёжен

Это перевод Asking questions where the answer is unreliable anyway. Автор: Реймонд Чен.

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

"Как я могу узнать, сколько ссылок есть на этот объект разделяемой памяти?"
Даже если бы был способ узнать, то ответ, который вы получили бы, мог стать тут же неверным, потому что через микросекунду после вашего вопроса кто-то открыл новый описатель.
Это пример вопроса, который "бессмыслен из-за неизбежных условий гонки".

"Как я могу узнать, свободна ли критическая секция, не входя в неё?"
И опять: если бы вы получили ответ, то он может тут же стать неверным, потому что какой-то другой поток решил захватить критическую секуию сразу после того, как вы проверили свободна ли она.

"Как я могу узнать, установлена ли в системе ловушка клавиатуры?"
Всё та же проблема: в тот момент, когда вы получаете ответ ("всё чисто"), кто-нибудь другой устанавливает хук.

На самом деле, это даже ещё хуже, потому что люди, которые задают этот вопрос, обычно заинтересованы в защите ввода с клавиатуры. Но если кто-то установил хук на клавиатуру, то это означает, что они уже внедрились в ваш процесс (имеется ввиду хук). В этот момент ничто не мешает им изменить воображаемую функцию IsKeyboardHooked так, чтобы она всегда возвращала False.

Теперь, если ваша программа спросит, не стоит ли ловушка на клавиатуру, то ответ будет "Нет" и вы продолжите, в счастливой уверенности, что у вас нет хуков. Только потому, что кто-то так сказал.

Вы не можете надёжно судить о безопасности системы изнутри самой системы. Это всё равно что доказать самому себе, что вы не сошли с ума.

Система уже может быть скомпрометирована и все ваши доводы могут быть виртуализированы. Кроме того, ваша программа может быть запущена под виртуальной машиной, а в этом случае отсутствие ловушки внутри виртуальном машины ничего вам не даёт. Логгирование клавиатуры может производиться вне виртуальной машины.

С точки зрения UI, рабочий стол является границей безопасности. Как только вы позволяете кому-то запуститься на вашем рабочем столе, вы неявно доверяете им. Потому что они могут посылать вашей программе любые сообщения, вставлять хуки, вмешиваться в ваши оконные описатели, редактировать меню и вообще делать любые вещи с вами.

Вот почему есть немного настолько же ужасных ошибок, как позволить службе взаимодействовать с рабочим столом. Подключением к интерактивному рабочему столу вы предоставляете доверие контексту безопасности, которому вы не должны доверять. Конечно, это позволит вам манипулировать объектами на рабочем столе, но это также позволит объектам рабочего стола манипулировать вами (где-то тут есть подходящая шутка Якова Смирнова, но вместо этого я процитирую Ницше: Wenn du lange in einen Abgrund blickst, blickt der Abgrund auch in dich hinein).

Если вы являетесь службой, то вы не хотите давать не доверенным программам манипулировать вами. Иначе это откроет вас для Shatter атак.

Комментариев нет:

Отправить комментарий

Можно использовать некоторые HTML-теги, например:

<b>Жирный</b>
<i>Курсив</i>
<a href="http://www.example.com/">Ссылка</a>

Вам необязательно регистрироваться для комментирования - для этого просто выберите из списка "Анонимный" (для анонимного комментария) или "Имя/URL" (для указания вашего имени и ссылки на сайт). Все прочие варианты потребуют от вас входа в вашу учётку.

Пожалуйста, по возможности используйте "Имя/URL" вместо "Анонимный". URL можно просто не указывать.

Ваше сообщение может быть помечено как спам спам-фильтром - не волнуйтесь, оно появится после проверки администратором.

Примечание. Отправлять комментарии могут только участники этого блога.