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

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

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


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


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

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

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


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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

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

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

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

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

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

    * * *

    Читайте в следующем выпуске:
    Что такое компьютерный вирус?
    AflexDistribution
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 9

      0
      Картинки не грузятся.
        0
        Спасибо, исправил
        +1
        Даже если весь код закрыть от записи, есть много других способов проникнуть в комп )
          0
          Вы совершенно правы. Например, хакер, сумевший поменять параметры DNS в маршрутизаторе, через который идет весь трафик большого офисного центра, сможет в результате подменить любой сайт и любой файл для любого из сотрудников этого центра. Вы скачаете официальный патч с официального сайта солидной компании (как может показаться), но на самом деле это будет совсем другой сайт и очень опасный файл.

          Но обратите внимание, что аппаратная фиксация параметров указанного маршрутизатора делает даже такой способ проникновения в систему практически невозможным. Это лишь один пример. Фиксирование программы — не панацея, но оно бывает очень полезным.

          В рамках статьи мы не ставили цель охватить все аспекты информационной безопасности и предоставить решения всех возможных проблем; темой статьи была причина возникновения компьютерных вирусов. В следующих выпусках блога мы затронем и другие аспекты информационной безопасности.
            0
            Трудно представить, как реализовать read-only подход в системе, программные компоненты которой должны периодически обновляться — и ОС, и те же антивирусы нежизнеспособны без своих обновлений…
              0
              О методах практической реализации защиты кода от изменений мы обязательно расскажем в следующих выпусках.

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

              Вы можете протестировать новую программу (например, убедиться, что после установки нового SP на операционную систему не возникнет программного конфликта или иных проблем) и только после этого снять флаг read-only, заменить старую версию новой и снова поставить фоаг read-only.

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

              Думаю, Вам известны многочисленные случаи, когда после безоглядной замены старой версии ПО на новую возникали серьезные проблемы несовместимости. Безусловно, Вы можете доверить браузеру самостоятельно решать, когда он заменит сам себя и на что именно заменит. Но будьте готовы к тому, что в Вашем компьютере при этом появится, например, новый графический плагин, открывающий доступ извне к низкоуровневым библиотекам на уровне ядра. Или что-то другое, еще более опасное.
              0
              Я работала в нескольких компаниях, и, честно говоря, не помню такого случая, чтобы сисадмин когда-либо тестировал софт после установки.
                0
                Хе, как это я умудрился пропустить новую статейку)

                Значит операционная система на моём компе больше не хозяин. Всё будет решаться аппаратно. И что мешает разработчикам харда напихать в железку всякой херни: цифровых подписей, всяких копирастских штучек, etc. Ничего, всё так и будет. Такой судьбы я компу никогда не пожилаю. И ни один разумный человек не пожелает. Это раз.

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

                Вообще, идея откопать фиксированные архитектуры забавна в своём идиотизме, но так никогда не будет. Просто налепят шифрованных загрузчиков и цифровых подписей (как налепили во всяком iГовне) и ни один байт не запустится без одобрения ZOG.
                  0
                  Они уже все напихали и налепили, и в ваш хард, и всюду куда следует. )) Это не зависит от того, фиксированная или не фиксированная, архитектура не имеет к этому отношения. Не путайте фиксированную архитектуру и закрытую. Закрытая, это когда вам не говорят, что в харде и что в софте внутри. А фиксированная, это значит, что из сети, снаружи менять на вашем компе ничего нельзя, потому что аппаратно запрещено.
                  А динамический запуск программ тут вообще не при чем, выделением памяти ОС как занималась, так и будет заниматься всегда, в любой архитектуре.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое