Проделки Chrome: действительно ли Google реверсировал Windows? №1

Сразу же после публикации несколько недель назад, исходный код нового
браузера Chrome от Google привлек к себе пристальное внимание многих
разработчиков. Тому послужило сразу несколько причин: во-первых, в состав
браузера входит новая виртуальная машина V8 для выполнения JavaScript,
выполняющая скрипты практически без потери скорости, а также движок для
визуализации WebKit, который делает всю черную работу по корректному
распознаванию и отображению веб-страниц, и, наконец, потому что в браузер
внедрена новая система безопасности на основе виртуализации процессов,
призванная уменьшить влияние возможных уязвимостей на работу системы. Вот она-то
и привлекла в этот раз особое внимание специалистов по причине, которая,
возможно, удивит многих. Анализ исходников показал, что Google декомпилировал
код Windows, хотя это строжайше запрещено пользовательским соглашением.

Но, прежде чем мы вернемся к вопросу о декомпиляции, взглянем на то, как
именно собран Chrome и почему его архитектура безопасности так любопытна.

Архитектура безопасности Chrome

Из всех нововведений, которые Chrome привнес на рынок интернет-браузеров,
самым необычным и достойным внимания является его архитектура безопасности.
Обычные браузеры (Firefox, Internet Explorer 7 и ниже, Opera, Safari) запускают
для всех совершаемых ими действий один общий процесс. Тaк, один-единственный
процесс могут делить между собой модули отображения пользовательского
интерфейса, соединения с Интернет, разметки HTML и запуска плагинов. Прибавьте к
этому и открытие различных вкладок в самом браузере.

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

В Редмонде проложили путь

Windows Vista и Explorer 7 первыми нанесли Google удар, немного отступив от
своей традиционной однопроцессной схемы. Internet Explorer очень долго строил
архитектуру своей безопасности на основании "зон безопасности", которые
позволяли применять различные политики фильтрации контента в соответствии с тем,
находился ли удаленный источник во внутренней корпоративной сети или в Интернет.
Такая концепция стала причиной возникновения широко известной уязвимости, когда
потенциально опасные интернет-страницы выдавали себя за внутрикорпоративные и
получали все привилегии безопасной зоны. Чтобы противодействовать этому, версия
IE7 для Vista запрещает работу с двумя различными зонами безопасности в
рамках одного и того же процесса. Браузер, открытый в "Internet Zone" теперь
нельзя использовать для того, чтобы открыть страницу в "Intranet Zone"; вместо
этого инициируется полностью отдельный процесс iexplore.exe.

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

IE8 и Предотвращение выполнения данных (DEP)

Другая основная функция защиты IE8 – это поддержка технологии DEP,
предназначенной для предотвращения возникновения ошибок переполнения буфера,
позволяющих внедрять в запущенный процесс вредоносный код. Традиционно на
процессорах с архитектурой x86 память может быть помечена как память только для
чтения и выполнения и/или как память для записи. Если ячейка памяти была ранее
помечена как память только для чтения, то с нее может быть произведено
считывание и выполнение кода. Такая особенность и приводит к возникновению
ошибок переполнения буфера. Запущенная программа выделяет себе определенное
количество памяти, которая должна быть доступна как для чтения, так и для
записи, с тем, чтобы программа могла записывать и позднее возвращаться к
результатам ранее произведенных вычислений. Хакеры используют это, чтобы
внедрить небольшой фрагмент исполняемого кода в ту область памяти, которая
предназначена для временного хранения результатов работы запущенной программы.

Функция DEP разделяет память, предназначенную для чтения, и память
предназначенную для выполнения кода. Теперь она может быть помечена как память
для чтения и записи, но не как память для выполнения. Это затрудняет
осуществление манипуляций с переполнением буфера, но, к сожалению, не лишает их
смысла полностью, поскольку для ряда приложений, выполняющих операции по доступу
к памяти "на лету", непосредственно в момент проведения вычислений, возможность
чтения из областей памяти, предназначенных для хранения, просто необходима.
Некоторые более старые приложения, в том числе скрипты на основе ActiveX, могут
некорректно работать с DEP, поскольку в свое время их разработчики не
предусмотрели возможности такого разделения памяти атрибутов памяти в рамках
архитектуры х86. Поэтому, чтобы обеспечить совместимость своего браузера с
подобными приложениями, в Microsoft не стали внедрять поддержку DEP для IE7. Но
теперь многое изменилось, и IE 8 будет обладать врожденной поддержкой DEP.

Что и приводит нас, в конечном счете, к Chrome. Точно так же, как и IE8,
Chrome создает раздельные процессы для каждой из вкладок, даже более того, для
каждого из плагинов. И, также как и IE8, Chrome включает DEP для всех своих
процессов. Это и заставило некоторых поднять в удивлении брови.

О коде, комментариях и наработках

В Windows есть несколько способов включения DEP, лучший из них – это создание
64-битного процесса. Все 64-битные процессы в обязательном порядке поддерживают
DEP и не имеют возможности для маневра. Это – правило без исключений, поэтому
такие процессы по умолчанию "понимают" DEP и безопасно его выполняют. К
сожалению, использование браузера в 64-битной среде весьма проблематично из-за
ограниченной поддержки со стороны сторонних приложений, в первую очередь -
Flash.

Поэтому Chrome работает в 32-битной среде, и оперирует 32-битными
процессами. Каждый 32-битный процесс может находиться по отношению к DEP в трех
состояниях: иметь эту функцию включенной (что хорошо), отключенной (что плохо),
либо эмулировать ее через ATL Thunk Emulation. ATL – это библиотека,
которой Microsoft снабжает программистов, пишущих приложения для Windows на
языке C++ и которая широко используется для создания ActiveX-плагинов для
браузеров. К сожалению, более ранние ATL версии плохо написаны и создают
исполняемый код, который не помечен как исполняемый (как раз то, с чем призвана
бороться DEP). Поскольку такая ситуация, похоже, несколько смущает Microsoft
(ведь, в конце концов, ATL – их собственная библиотека), в операционных системах
этой компании есть функция, позволяющая выявлять некорректные версии библиотек
ATL и обеспечивать для них возможность включения системы защиты DEP, за
исключением тех нескольких строк кода, которые вообще не совместимы.

Все это, конечно, прекрасно и дает Chrome возможность получить необходимые
ему функции контроля над DEP, с тем, чтобы соблюсти баланс между совместимостью
и безопасностью (браузер включает DEP для всех своих процессов и эмулирует эту
функцию через ATL Thunk Emulation для сторонних приложений). Есть лишь одна
неувязочка. Сама DEP дебютировала в составе XP Service Pack 2 (также ее
можно увидеть и в Windows Server 2003 SP1 и во всех версиях Vista и Server
2008). А вот возможность настраивать политику ее применения со стороны
процесса появилась лишь в Vista SP1 и Server 2008. В предыдущих версиях DEP
также присутствовала, но никакой возможности её контроля со стороны приложений
не было.

Поэтому, если мы взглянем на ту

часть кода Chrome, которая регулирует применение DEP к внутренним процессам
браузера, мы сможем увидеть несколько интересных комментариев:

// Try documented ways first.

// Only available on Vista SP1 and Windows 2008.

Дальше следует несколько строк кода, а затем...

// Go in darker areas.

// http://www.uninformed.org/?v=2&a=4

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

// Completely undocumented from Microsoft. You can find this
information by

// disassembling Vista's SP1 kernel32.dll with your favorite disassembler.

Данный комментарий был впервые обнаружен Скоттом Хансельманом спустя
несколько дней после публикации исходного кода браузера, и он уличает Google
в декомпиляции Windows, которая строжайше запрещена Соглашением с конечным
пользователем (EULA)
этой операционной системы.

Согласно ему, запрещено:

• Разрабатывать какие-либо технические ограничения для этой системы;
• Подвергать реверс-инжинирингу, декомпилировать или разбирать ее на части,
  за исключением и только в случае выданного через суд разрешения;
• Использовать компоненты системы в составе приложений, для нее не
  предназначенных;
• Делать больше копий ОС, чем это установлено данным соглашением или
  предписано законодательством;
• Выкладывать ОС в свободный доступ с целью копирования;
• Продавать, сдавать в аренду или лизинг данную ОС;
• Использовать ОС в коммерческих целях.

Google заявляет о том, что никогда ничего не декомпилировал. В связи с
процитированными выше комментариями в Google заявили, что использовали код,
опубликованный uninformed.org - интересным, специфическим, редко выходящим
журналом по реверс-инжинирингу. По правде сказать, исходный код Chrome
действительно содержит ссылку на разъяснения по поводу контроля использования
DEP в XP SP2, опубликованные там.

(Продолжение следует)