Chrome Attic – Взгляд На Исходный Код



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

.

Именно эта система привлекла внимание многих программистов по простой причине.

При чтении исходного кода создается впечатление, что Google декомпилировала (реверс-инжиниринг) компоненты Windows — а это запрещено лицензионным соглашением.

Но прежде чем мы рассмотрим реверс-инжиниринг, стоит взглянуть на сам браузер.



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

ИЗ всех нововведений браузера его архитектура безопасности является самой интересной и значимой.

Традиционные браузеры (Firefox, Internet Explorer 7 и ниже, Opera, Safari) создают один процесс для всего — отображения интерфейса, подключения к Интернету, анализа HTML, запуска плагинов.

Все вкладки браузера используют этот процесс.

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

Есть у этой архитектуры и менее заметные особенности.

Например, в идеале код, работающий в плагинах или движке JavaScript, не должен иметь доступа к определённым ресурсам — например, записи файлов на диск.

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



Редмонд снова впереди

Windows Vista и IE7 фактически опередили Google в отходе от этой модели.

Internet Explorer уже давно использует концепцию « зоны безопасности ", что позволяет разграничивать привилегии для интрасети и глобальной сети.

Одним из постоянных источников ошибок в IE было то, что специально созданная страница могла "обмануть" браузер и выполняться так, как если бы она находилась в доверенной зоне.

Чтобы избавиться от этой проблемы, Vista запрещает смешивание источников из разных зон в рамках одного процесса.

Если после просмотра сайтов из зоны Интернет открыть внутренний корпоративный сайт, создается новый экземпляр процесса iexplore.exe, и они работать отдельно.

Internet Explorer 8, выпущенный в этом году в виде бета-версии, идет еще дальше в этом направлении.

Вместо одного процесса на зону IE8 использует один процесс на вкладку плюс один родительский процесс, отвечающий за интерфейс.

Это обеспечивает еще лучшую изоляцию.

В IE8 даже вкладки внутри одной зоны безопасности независимы и изолированы друг от друга.

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



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

Еще одна особенность IE8 — поддержка ДЭП — предотвращение выполнения данных, предназначенное для того, чтобы раз и навсегда разобраться с выполнением кода из-за переполнения буфера.

Традиционно в архитектуре x86 память может быть помечена как доступная для чтения и выполнения и/или записи.

Если включен режим «только чтение», выполнение разрешено.

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

При использовании DEP чтение и запись больше не связаны; Область памяти может быть помечена как чтение+запись без флага выполнения.

К сожалению, иногда необходимо создавать области, где разрешено «чтение+запись+выполнение».

Распространенным случаем являются JIT-компиляторы (точно в срок), такие как Java и .

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

Хотя нормальная поддержка DEP появилась в x86 относительно недавно, Win32 API уже давно поддерживает соответствующие функции.

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

Однако ленивые разработчики просто пренебрегли такой «необязательной» вещью.

Поэтому некоторые старые программы Windows не могут работать с DEP, включая некоторые плагины ActiveX. Чтобы обеспечить совместимость с этими плагинами, разработчики IE7 по умолчанию отключили поддержку DEP. С момента выпуска этого браузера многие плагины уже были обновлены (разработчики поняли, что очень скоро это станет обязательным требованием), а IE8 уже включает DEP по умолчанию.

Это подводит нас к Chrome. Как и IE8, Chrome создает один процесс на вкладке .

На самом деле, он идет еще дальше, создавая дополнительный процесс для каждого плагина.

И, как и IE8, Chrome включает DEP для всех своих процессов.

Вы спросите, причем здесь реверс-инжиниринг? Если покопаться в исходниках Chrome, то можно увидеть интересную вещь.

Chrome сначала пытается использовать стандартный API для управления DEP. Однако, если это не сработает, он пробует второй метод:

// Completely undocumented from Microsoft. You can find this information by // disassembling Vista's SP1 kernel32.dll with your favorite disassembler.

(цитата из кода браузера).

Большинство используемых функций полностью официально документированы.

Создатьпроцесс описано очень хорошо.

Нткуерифуллаттрибутесфиле - уже недокументированная функция.

Chrome использует оба для создания процессов.

Теги: #Google Chrome #DEP #безопасность #microsoft #Google Chrome

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.