Компьютерра PDA N138 (01.10.2011-07.10.2011)
Шрифт:
Их, проблем, на уровне архитектуры вычислительного процесса не так уж и много, всего четыре, но они на протяжении последнего десятилетия терзают информационную безопасность, воплощаясь в разных ипостасях. Чисто программными методами с ними справиться не удаётся; настало время радикальных, "железных" решений.
Проблем четыре, и они разной природы. Три из них связаны с конкретными методами атак, а последняя проблема носит концептуальный характер. Перечислю с конца, благо этой темы мы уже краешком коснулись в данной статье.
На настоящий момент программная и аппаратная инфраструктура систем безопасности функционирует в лучшем случае на том же программном уровне,
Инфраструктура защиты должна быть вынесена с уровня программирования, доступного операционной системе и тем более прикладным программам. Не вдаваясь в подробности, можно сослаться на печальный опыт внедрения защиты с использованием NEX бита: его просто научились отключать.
На данный момент в архитектуре х86/64 таких независимых уровня два: это уровень режима системного менеджмента (SMM режим) и уровень хоста Гипервизор. Кроме этого, у Intel есть один малоизвестный режим работы процессора – логический режим доверенного выполнения (XSMM). Если всерьёз подходить к борьбе с вирусами, то, конечно, аппаратура контроля вирусной активности должна управляться программами, работающими именно в этих режимах, хотя ничего не мешает ввести новый режим, специально заточенный под специфику решаемой задачи.
Кроме этого, для антивирусных программ пользовательского уровня и уровня ОС следует предоставить доверенный командный интерфейс, по типу реализованного в ТРМ-модулях. Заодно можно побороться с пиратами, на радость блюстителей авторских прав, заставив контролировать в точках старта программ наличие легальных сертификатов с помощью того же ТРМ-модуля.
С инфраструктурой понятно, теперь вопрос: что контролировать?
И здесь всё ясно. Методов пробоя информационной безопасности у хакеров и шпионов не так много, на первом этапе можно ограничиться контролем за самыми актуальными.
В сумме эти методы эксплуатируют всего ТРИ архитектурных уязвимости. Следовательно, можно поставить на аппаратный контроль нарушение архитектурных соглашений, которые декларируются, но не контролируются на настоящий момент. Пока звучит туманно, но думаю, из дальнейшего сразу станет понятным.
Первая и самая серьёзная архитектурная уязвимость - это однородность оперативной памяти: в ней все можно хранить в произвольном порядке. Конечно, имеются соглашения на уровне ОС о распределении адресных пространств, часть этих соглашений уже давно контролируется аппаратурой (в области ОС нельзя работать прикладным программам), но только часть. Атака, направленная на повышение уровня привилегий, как раз и эксплуатирует уязвимость в архитектуре, не защищённую аппаратурой. В области прикладных программ пока разрешено работать программам с привилегиями уровня ядра ОС, и именно этим пользуются хакеры.
Вторая архитектурная уязвимость - это наличие единого стека. В нём хранится как служебная информация (указатели на точки возврата из процедур), так и локальные данные программ. Соглашение о разделении и упорядочивании стека существует, но не контролируется аппаратурой. Атака через переполнение буфера как раз и эксплуатирует этот механизм методом подмены адреса точки возврата из процедуры. Следовательно, если поставить на контроль целостность адресов области стека, где хранятся указатели на точки возврата из процедур, то можно блокировать целый класс хакерских атак.
Третья архитектурная уязвимость - это равноправие
Всё это было известно и раньше, но контролировать до настоящего момента эти атаки пытались разными программными методами, создавая "песочницы", применяя аналитику и прочее... Всё это худо-бедно работало, но медленно и ненадёжно. С другой стороны, все три вышеперечисленные атаки имеют однозначные характерные признаки на аппаратном уровне. Эти признаки можно контролировать непрерывно, а не только в критических точках, как делается с помощью программных методов контроля, и, что немаловажно, - без потери быстродействия.
Если использовать хотя бы перечисленные выше методы аппаратного контроля, то можно предотвращать хакерские атаки на этапе попытки внедрения в целевую систему, а не по факту функционирования уже внедрённого вируса. А это уже дорогого стоит...
Собственно, всё это было ясно и три, и пять лет тому назад - думаю, не только мне, но и любому грамотному специалисту. Кому-то удалось эти достаточно очевидные мысли пропихнуть в мозги бизнесменов, и те начали вкладывать во всё это деньги.
Можно было на этом успокоиться, но мысль оказаться впереди планеты всей прочно засела уже в моём мозгу. Я решил обогнать Intel и неспешно приступил к работе, зная, что цикл разработки у них - где-то год-полтора, а значит, у меня времени для этого было предостаточно. Сказано - сделано: к 2011 году я все эти методы контроля за вирусными атаками реализовал на практике. Понятно, что не в кремнии, а на виртуальном оборудовании, которое было создано с помощью средств виртуализации. Тогда же была написана соответствующая статья, к ней приложены демонстрационные программы, чтобы всё, что было в статье, можно было пощупать на практике. Статья "вылёживалась", пережидая мёртвый сезон длинных новогодних каникул. А в это время появилась новость, что сделка по покупке McAfee завершена, и я понял, что нахожусь на верном пути. Опубликовал статью и угомонился в ожидании дальнейших событий.
Ждать пришлось недолго: текущей осенью мои прогнозы начали сбываться. На конференции IDF2011 фирма Intel совместно с McAfee анонсировали технологию аппаратной антивирусной защиты DeepSAFE, которая будет реализована в новых моделях процессоров, разрабатываемых фирмой Intel. Пока это общие слова и невнятные картинки, но посмотрите на скриншот: там красным цветом выделена прослойка между процессором и операционной системой. Подписана она словом DeepSAFE. Это как раз то, что и требовалось, - независимый уровень контроля за активностью вирусных атак. Как он будет реализован, нам пока не объяснили. Вариантов несколько, но суть не в конкретном решении, а в самой концепции.