Pull to refresh

Программы, данные и их хозяева (окончание)

Reading time 7 min
Views 3.1K
В первой и второй частях статьи мы рассмотрели фундаментальную причину компьютерных вирусов — автопрограммируемость (способность алгоритма к изменению самого себя) в большой многопользовательской среде.

Вирусы практически неизбежно возникают в компьютере, для которого выполняются 2 условия:
1) исполняемому коду на аппаратном уровне не запрещена запись в область исполняемого кода;
2) у компьютера много хозяев, независимо контролирующих системные интерфейсы ввода-вывода.


Компьютером мы называем произвольную вычислительную систему. Мы уже показали, что Интернет является именно такой системой, для которой справедливы оба названных условия. Они выполняются и для подавляющего большинства подсистем Интернета, т.е. подключенных к нему системных блоков — от бытовых смартфонов и ноутбуков до корпоративных серверов. Номинальные хозяева потеряли возможность монопольного управления ими с момента подключения к Сети, разделив эту привилегию с миллионами чужих людей, действия которых могут влиять на исполняемый код.


Оценка надежности компьютера в отношении устойчивости к вирусам.

Как Интернет в целом, так и соединенный с Интернетом типичный компьютер, к сожалению, занимают в таблице антивирусной надежности последнее место (отмеченное красным).

Ситуация была бы совершенно иной, если бы люди умели писать программы без ошибок. Но такой технологии на Земле пока нет — по крайней мере, для коммерческих программ. О комплексе технологических и социальных причин, делающих ошибки в программном обеспечении неизбежными, мы поговорим в другой раз, а пока посмотрим на таблицу, описывающую мир, где программы не содержат ошибок.


Оценка надежности компьютера в отношении устойчивости к вирусам для гипотетического случая полного отсутствия ошибок во всем ПО при условии, что устойчивость к вирусам заложена в него на уровне разработки :)

Если бы все операционные системы, браузеры, веб-серверы и прочие программы были написаны идеально и с учетом требований безопасности, то сколь угодно большая фон-неймановская среда могла бы существовать, оставаясь неуязвимой для вирусов. В идеальном программном обеспечении все связи между элементами настолько тщательно продуманы, что при любых комбинациях взаимодействий математически гарантируется невозможность изменений в коде со стороны кого-либо, кроме его номинального хозяина. Любой специалист по информационной безопасности понимает, что применительно к большим системам это утопия.

Тем не менее, тщательное программирование с целью исключения возможности влияния одних элементов кода на другие — это один из практически используемых методов антивирусной защиты. И он приносит неплохие результаты, особенно при компактности кода. Но — не идеальные. Часто можно слышать утверждения типа «Сертифицированные UNIX-системы неуязвимы». Это близко к истине, но это не истина. Подобные утверждения не являются математически корректными. Они небесспорны, и их строгое доказательство невозможно на практике. Формальное доказательство безупречности большого объема кода требует много времени и очень дорого стоит, особенно с учетом взаимодействия этого кода с разнообразным hardware. Абсолютную уверенность в неизменности кода дает только его физическая защита от изменений (read-only) на соответствующем носителе. Этим носителем, кстати, может быть и оперативная память — при условии невозможности внесения в нее изменений самим кодом (например, если он размещается в памяти внешними средствами с последующим блокированием записи в эту память до первого такта исполнения).

Грамотная реализация защиты критически важного кода в промышленных операционных системах иногда обеспечивает надежность, приближенную к физической реализации read-only. Но такие системы далеко не всегда можно использовать — по множеству технологических и экономических причин. В работе специалиста по информационной безопасности могут возникать задачи совершенно разного рода — от проектирования узла оператора связи до программирования ПЛК, управляющего турбиной; от разработки ответственной базы данных до аудита и приведения в порядок произвольной корпоративной системы. Если, например, такая система имеет в основе ОС Windows и комплекс продуктов «1С: Предприятие», то все ссылки на «неуязвимость UNIX» окажутся бесполезными. В практике работы приходится иметь дело и с закрытым проприетарным ПО, об уязвимостях в котором трудно судить, и с чипами, система команд которых достоверно неизвестна. В сфере информационных технологий исходные условия практически всех проектов различаются. Поэтому для грамотного руководства любым проектом специалист должен владеть приемами, универсальными для информатики и кибернетики в целом. Одним из них является фиксирование программы (аппаратная защита от изменений).

Во многих случаях фиксирование программы обеспечивается с помощью эмуляции аппаратной защиты. Эмуляция может выполняться на разных уровнях архитектуры, она может быть более или менее полной, но самое главное — она не должна управляться программно, т.е. из того самого кода, который защищается с ее помощью. Программно управляемая эмуляция защиты (например, от записи в некоторые области памяти или от доступа к ним) не лишает компьютер свойства автопрограммируемости, поскольку в конечном итоге возможность модификации кода определяется самим кодом.

Наличие в процессоре и чипсете отдельных — программно управляемых! — механизмов «аппаратной» защиты определенных областей памяти не решает проблему полностью. Например, в процессорах x86 программным путем управляются защищенный режим, режимы системного менеджмента и аппаратной виртуализации. Но само по себе оснащение компьютера таким процессором еще не означает, что он будет неуязвим перед вирусами: полная ответственность за грамотное управление «аппаратной» защитой все равно возлагается на программное обеспечение (BIOS, ОС, другое ПО системного уровня). Целостность кода зависит в таком компьютере исключительно от того, как он запрограммирован. Иными словами, если с двумя разными операционными системами (и даже с двумя разными настройками одной операционной системы) уровни защиты кода получаются разными на одном и том же hardware, это означает, что перед нами — типичная автопрограммируемая система, в которой защита реализуется не аппаратно, а программно.

В системе, не имеющей свойства автопрограммируемости, неизменность программы обеспечивается независимо от ее содержания. При замене программы на любую другую уровень ее защиты остается неизменным и абсолютным, поскольку обеспечивается конструкцией системы.

Кстати, в связи с некоторыми комментариями читателей к первой части статьи, обращаем внимание, что заменой произвольной программы считается замена в ней хотя бы одного бита. С формальной точки зрения, отличия в 1 бит достаточно, чтобы считать две произвольные программы различными. Термин «замена программы» вовсе не обязательно означает замену всего кода от начала до конца с радикальным изменением функциональности :)

Как программная, так и аппаратная защита кода от изменений обладают своими достоинствами и недостатками. Для решения многих практических задач информационной безопасности достоинства аппаратной защиты оказываются решающими. Главные из них — дешевизна, математически обоснованная надежность и интуитивная очевидность. Аппаратная защита не требует доказательства безупречности кода, обеспечивая его гарантированную неизменность в течение нужного времени даже при наличии ошибок. Но для применения этого метода защиты необходимо обеспечить разделение программ и данных (вынос данных за пределы зафиксированной области памяти), что в некоторых случаях может оказаться существенным недостатком.

Кроме защиты от вирусов, фиксирование программы (кода, алгоритма, информационных объектов вообще) позволяет решать и другие задачи информационной безопасности, о которых мы поговорим в следующих выпусках. А пока приведем несколько примеров фиксирования объектов на разных уровнях физической и логической структуры вычислительной системы. Для каждого объекта указаны флаги неизменяемости и неисполняемости. Подчеркнем, что они устанавливаются средствами, внешними по отношению к защищаемым объектам. В зависимости от конкретных задач и возможностей, флаги могут быть реализованы аппаратно, программно или условно (это означает, например, отсутствие прямого запрета на операции, вместо которого ведется отслеживание событий нарушения флагов). Данные примеры не следует воспринимать как прямое руководство к действию: это всего лишь иллюстрации общих принципов защиты от вирусов и некоторых частных случаев использования для этой цели фиксированных программ.


Антивирусная защита на уровне отдельных байтов. Соответствует классической схеме микроконтроллера с программой в ROM и данными в RAM, но может быть реализована и другими способами (например, установкой флагов в дополнительных битах общей памяти).


Антивирусная защита на уровне логических модулей. Хорошо иллюстрирует ключевой принцип разделения программ и данных — вне зависимости от конкретного механизма его реализации.


Антивирусная защита на уровне областей памяти. Физическое устройство памяти не имеет значения: это может быть и оперативная память, и флеш-память, и дисковая память (storage), и любая другая.


Антивирусная защита на уровне файлов. Этот уровень очень нагляден, его удобно контролировать.


Антивирусная защита на уровне объектов функционально завершенного программного обеспечения. Контроль на этом уровне — это ключ к долговременной надежности компьютерной инфраструктуры организации.

Заметим, что антивирусная программа, основанная на принципе эвристического анализа (анализа характера и поведения информационных объектов) представляет собой частный случай системы, которая контролирует на разных уровнях компьютера информационные объекты и фиксирует некоторые из них по заданным правилам. Это полезный инструмент в арсенале специалиста по информационной безопасности, но далеко не единственный.

Подведем итог. Мы видим три пути разрешения кризиса, который описали (отчасти — иносказательно) в первом выпуске блога. Самый очевидный, надежный и выгодный путь — снижение уровня автопрограммируемости вычислительных систем. Он труден, но все еще реален даже для совсем небольших организаций и частных пользователей. Он может обезопасить их не только от вирусной угрозы, но и от угрозы постепенного перехода их программ и данных в руки новых хозяев в течение нескольких ближайших лет.

Второй, очень опасный путь — уменьшение числа хозяев. До тех пор, пока основная масса программ и данных не сосредоточится в руках небольшого круга принимающих решения по всем существенным вопросам. Это единственная реальная альтернатива первому пути, к сожалению.

Третий путь — разработка коммерчески эффективной технологии создания программ без ошибок. Реальность такой технологии крайне сомнительна.

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

* * *

Читайте в следующем выпуске:
Что такое компьютерный вирус?
Tags:
Hubs:
+1
Comments 9
Comments Comments 9

Articles

Information

Website
aflex.ru
Registered
Founded
2001
Employees
51–100 employees
Location
Россия