Браузери і app specific security mitigation. Частина 3. Google Chrome

image
Ми продовжуємо цикл статей про механізми захисту браузерів від експлойтів:
Давайте заглянемо під капот браузера Chrome і з'ясуємо, що є в його анти-експлоїт арсеналі.

Задіюються загальні механізми, що надаються сучасними версіями Windows і компіляторами:
  • Рандомізація баз модулів (Image ASLR);
  • HighEntropy ASLR (використовує 64-бітові адреси, Windows 8+);
  • Force ASLR (примусова рандомізація баз модулів);
  • Рандомізація аллокаций (HeapAlloc, VirtualAlloc; Windows 8+):
    Функції виділення пам'яті вибирають базу повертається пам'яті трьома способами:
    • вибираючи самий нижній адресу;
    • вибираючи самий верхній адресу;

    • вибираючи адреса відносно заданої бази.
      На системах Windows 8 перші два способи ніяк не рандомизировались і тому
      дозволяли виділити пам'ять за передбачуваним адресами.
  • Data Execution Prevention:
    неисполняемая пам'ять (стеки, купи, секції даних модулів та інше).
  • Stack cookies (канарки):
    у пролозі функції в стек поміщається рандомное значення перед адресою повернення, яке перевіряється перед поверненням управління. Виключає експлуатацію переповнення буфера.
  • Safe Structured Exception Handling (SAFESEH):
    запобігає перехоплення управління через перезапис вмісту керуючих структур SEH_EXCEPTION_REGISTRATION_RECORD. Перед тим, як передати управління на обробник, вказаний у цій структурі, відбувається його перевірка. Якщо виконуваний модуль, якому належить обробник, зібраний з /SAFESEH, то відбувається перевірка адреси по таблиці SEH обробників цього модуля (під час лінкування вони вшиваються в бінарники).
  • Structured Exception Handler Overwrite Protection (SEHOP):
    доповнює попередню техніку, оскільки сама по собі вона була далеко не ідеальна. По-перше, вона вимагала рекомпиляции додатків, по-друге — якщо обробник розташовувався в модулі без /SAFESEH або взагалі поза будь-якого модуля — вона просто не працювала. Тому компанія Microsoft додала техніку рівня OS — SEHOP. Її суть полягає у перевірці цілісності SEH-ланцюжка: при старті потоку в ланцюг SEH-обробників додавалася "канарейка", наявність якої перевірялося перед викликом будь-яких обробників. Як правило, при перезапису адресу обробника виключення, буде ще і покажчик ну наступну структуру в ланцюжку, що розриває ланцюг і робить "канарку" недосяжною.
  • Control Flow Guard (CFG):
    запобігає перехоплення потоку управління через перезаписування адрес даних програми, включаючи таблиці віртуальних функцій, перевіряючи адреси на командах непрямих переходів. Валідні адреси функцій модуля зберігаються в бітовій карті, яка будується компілятором. Докладніше.
  • Windows mitigation policies:
    ряд обмежень, застосовуваних Windows 8+ до процесів, з яких в Chrome використовує для своєї пісочниці наступні:
    • Relocate Images
    • Heap Terminate

    • Bottom-up ASLR
    • High-entropy ASLR
    • Strict Handle Checks
    • Disable Font Loading
    • Disable Load Image from Remote Devices
    • Disable Load Image of "mandatory low" (low integrity level)
    • Extra Disable Child Process Creation
Ми розглянемо внутрішні механізми браузера:
  • Аллокатор PartitionAlloc:
    дозволяє рознести об'єкти різних розмірів і типів за різними хипам, тим самим спростивши можливості атакуючого у виборі об'єктів-кандидатів на звільнену пам'ять. Допомагає ловити heap over/underflow-и як всередині самого хіпа, так і на його кордонах. Детальніше — далі.
  • Трасуючий збирач сміття для C++ — Oilpan;
  • JIT-компілятор JavaScript:
    включає в себе ряд механізмів, що ускладнюють його використання для генерації елементів експлойта.
  • Sandbox:
    система безпеки браузера, призначена для зниження збитку від компрометації його компонентів.
Введення про UaF і пошкодження пам'яті
Браузер надає деякий API для керування об'єктами-компонентами документа — веб-сторінки. Вміст цього документа представляється у вигляді дерева вузлів, кожен вузол якого — елемент, атрибут, текстовий, графічний або інший об'єкт — це уявлення DOM. Вузли цього дерева — "ноди" — можуть створюватися, знищуватися і бути змінені засобами JavaScript. Існування безлічі взаємозалежних складних об'єктів є передумовою для наявності багів, а зручність управління цими об'єктами за допомогою JavaScript — способом використання цих багів.
Баги, що призводять до пошкодження об'єктів в купі, дуже часто є відправною точкою для всієї послідовності дій, яку виконує браузерний експлойт. Проблеми, викликані ними, можна поділити на дві великі категорії:
  1. temporary (тимчасові) — виникають в результаті спроби використання об'єкта поза періоду його існування (виклик методу об'єкта після його звільнення, наприклад);
  2. spatial (просторові) — породжені помилковим доступом за межі розташування об'єкта в пам'яті (звернення до елемента масиву по невірному індексом, наприклад).
Для запобігання спрямованого впливу на інші об'єкти в пам'яті, використовуючи уразливий об'єкт, пропонується розглянути ряд механізмів, що реалізуються в аллокаторах — менеджерах купи.
Blink — рендерер Chrome — задіє два власних аллокатора: PartitionAlloc і Oilpan (він же BlinkGC). Є два окремих випадки:
  • discardable memory — вивантажується пам'ять, яка використовується для кешування великих графічних об'єктів; звільняється, коли вільна пам'ять на пристрої вичерпується;
  • malloc, від якого хочуть цілком позбутися.
PartitionAlloc
PartitionAlloc використовується для тих об'єктів, для яких не передбачається автоматична збірка сміття. Це його ключова відмінність від Oilpan, про якого пізніше.
Дизайн PartitionAlloc включає в себе такі елементи, що мають відношення до безпеки об'єктів в пам'яті:
  • розбиття на розділи аллокаций об'єктів різних типів. Така ізоляція дозволяє скоротити можливості, які будуть у атакуючого у разі експлуатації багів, що призводять до читання або запису даних за межі уразливого об'єкта на інший об'єкт, наприклад, лінійного переповнення буфера в цій купі.
    1. LayoutObjects — тісно пов'язані з DOM нодами об'єкти, використовувані рендерером для відображення елементів сторінки.
    2. Buffers — буфери для масивів, рядків, битвекторов.

    3. FastMalloc — тут досить великий список різноманітних об'єктів.
  • зберігання метаданих купи в окремому регіоні — тобто вони також ізолюються для запобігання їх пошкодження;
  • вказівник на freelist (список вільних блоків пам'яті) захищається від часткової перезапису, або розіменування;
  • великі алокації розміщуються окремо та обрамляються guard pages — сторінками пам'яті перед початком і після закінчення виділеного блоку, при доступі до яких процес терміново перерветься.
Проілюструвати це розвиток можна, поглянувши на эксплойт, продемонстрований Pinkie Pie на Mobile Pwn2Own 2013. Тут автор використовує integer overflow, що виникає в конструкторі типізованого масиву. Умови такі: виділяється буфер масиву Float64, при цьому послідовна ініціалізація всіх його елементів виходить за його кінець і запис довільних значень типу Float64 може бути продовжена скільки завгодно далі поспіль кожні 8 байт пам'яті після виділеного буфера. Для масиву довжини потрібен буфер великого розміру, PartitionAlloc делегує його виділення системного аллокатору — dlmalloc на Android. Pinkie Pie перезаписував заголовок наступного алокації в купі, змінюючи її розмір, звільняв розміщений там об'єкт (додаючи блок потрібного розміру в freelist) і таким чином добився виділення наступного об'єкта заданого розміру на цьому місці — куди можна продовжити писати довільні значення.
Звідси ми бачимо, від чого розробники захищають метадані аллокатора, навіщо великі алокації обрамляються guard pages, які не дадуть вийти за межі буфера таким манером, чому буфери типізованих масивів ізолюються від інших об'єктів.
Oilpan
Oilpan пропонує автоматичне прибирання сміття. Ця система знімає з розробників необхідність ручного керування пам'яттю, що є причиною помилок класу use-after-free. Коротко нагадаємо суть вразливостей, викликаних такими помилками: відбувається передчасне звільнення об'єкта, тобто звільнення, після якого він може бути використаний.
В якості прикладу подивимося на те, що нам вдалося знайти на багтрекері проекту: https://bugs.chromium.org/p/chromium/issues/detail?id=69965 Тут розглядається UaF баг, пов'язаний з класом Geolocation. Відбувається наступне: об'єкти класу Geolocation знищуються при оновленні сторінки, однак, пов'язані з ними запити на дозвіл геолокації не були попередньо скасовані, з-за чого залишаються висять покажчики в менеджері запитів, і спроба їх скасування при закритті вкладки в майбутньому закінчується помилковим доступом до звільненого об'єкту геолокації. Патч для цього бага додає метод pageDestroyed в клас Geolocation, який, мабуть, повинен був влаштувати правильний порядок звільнення об'єктів сторінки. З тих пір клас Geolocation зазнав зміни, пов'язані з впровадженням Oilpan, зараз він керується цією системою автоматично.
Експлуатація таких багів складається з етапів: виконання умов, в яких уразливий об'єкт буде видалений з купи, розміщення на звільнилася від цього об'єкта пам'яті контрольованих даних — створення "фейкового об'єкта" таким чином і виконання умов, що призводять до використання елементів цього фейкового об'єкта як власних членів. Для того, щоб запобігти другу частину цієї дії — виготовлення фейкового об'єкта шляхом розміщення на вивільненій пам'яті — розробники Chrome ізолюють регіони пам'яті, в яких живуть об'єкти різних типів. Подивимося, як це робиться:
// Override operator new to allocate Node subtype objects onto
// a dedicated heap.
GC_PLUGIN_IGNORE("crbug.com/443854")
void* operator new(size_t size) { return allocateObject(size, false); }
static void* allocateObject(size_t size, bool isEager) {
ThreadState* state =
ThreadStateFor<ThreadingTrait<Node>::Affinity>::state();
const char typeName[] = "blink::Node";
return ThreadHeap::allocateOnArenaIndex(
state, size,
isEager ? BlinkGC::EagerSweepArenaIndex : BlinkGC::NodeArenaIndex,
GCInfoTrait<EventTarget>::index(), typeName);
}

chromium//src/third party/WebKit/Source/core/dom/Node.h
У переопределенном new викликається allocateObject, аргумент isEager == false, тому — далі, ThreadHeap::allocateOnArenaIndex прийме третім аргументом arenaIndex значення BlinkGC::NodeArenaIndex — індекс "арени" (регіону пам'яті), в якому будемо виділяти об'єкт:
inline Address ThreadHeap::allocateOnArenaIndex(ThreadState* state,
size_t size,
int arenaIndex,
size_t gcInfoIndex,
const char* typeName) {
ASSERT(state->isAllocationAllowed());
ASSERT(arenaIndex != BlinkGC::LargeObjectArenaIndex);
NormalPageArena* arena =
static_cast<NormalPageArena*>(state->arena(arenaIndex));
Address address =
arena->allocateObject(allocationSizeFromSize(size), gcInfoIndex);
HeapAllocHooks::allocationHookIfEnabled(address, size, typeName);
return address;
}

chromium//src/third party/WebKit/Source/platform/heap/Heap.h
Які ще регіони визначено?
enum HeapIndices {
EagerSweepArenaIndex = 0,
NormalPage1ArenaIndex,
NormalPage2ArenaIndex,
NormalPage3ArenaIndex,
NormalPage4ArenaIndex,
Vector1ArenaIndex,
Vector2ArenaIndex,
Vector3ArenaIndex,
Vector4ArenaIndex,
InlineVectorArenaIndex,
HashTableArenaIndex,
FOR_EACH_TYPED_ARENA(TypedArenaEnumName) LargeObjectArenaIndex,
// Values used for iteration heap of segments.
NumberOfArenas,
};

* * * 
// List of typed arenas. The list is used to generate the implementation
// of typed arena related methods.
//
// To create a new typed arena add a H(<ClassName>) to the
// FOR_EACH_TYPED_ARENA macro below.
#define FOR_EACH_TYPED_ARENA(H) \
H(Node) \
H(CSSValue)

#define TypedArenaEnumName(Type) Type##ArenaIndex,

chromium//src/third party/WebKit/Source/platform/heap/BlinkGC.h
Тут ми бачимо: в пам'яті будуть розділені об'єкти класів Node, CSSValue, HashTables, Vectors; інші об'єкти цим аллокатором розподіляються по регіонах за розміром.
Перейдемо до розгляду ключової властивості Oilpan/BlinkGC — автоматичної збірці сміття. Об'єкти, які повинні управлятися цією системою, успадковуються від шаблонного класу GarbageCollected, GarbageCollectedFinalized або GarbageCollectedMixin. Члени-об'єкти цих класів, розташовувані в купі, представляються шаблонними класами Member або WeakMember в залежності від необхідної семантики.
Алгоритм, який виконує збирання сміття, є mark-and-sweep алгоритмом, і складається з двох основних етапів:
  1. mark — проводиться обхід графа об'єктів, для цього викликається метод trace() кожного, відзначає досяжні об'єкти з даного; відправні точки для такого обходу можуть вибиратися в залежності від поточного стану програми у двох варіаціях:
    • precise — вибирається тоді, коли потоки програми зупинені наприкінці циклів обробки повідомлень. Це гарантує відсутність "сирих" (raw) покажчиків у стеках потоків — значить, можна виходити з спеціальних глобальних покажчиків "persistent handles";
    • conservative — здійснюється в тих випадках, коли є необхідність пройти стеки потоків і взяти звідти можливі покажчики.

  2. sweep — недосяжні об'єкти, виявлені на попередньому етапі, відзначаються на звільнення і будуть знищені, коли знадобиться пам'ять. Внаслідок недетерминированного порядку відкладеного видалення об'єктів з купи, в момент виклику деструктора якого-небудь об'єкта вже не можна покладатися на наявність в купі з ним пов'язаних об'єктів. Тому розробники додають спеціальний метод — pre-finalizer, що викликається між цими етапами недосяжних для об'єктів, коли вони все ще живі.
JIT Hardening
Якщо б інструкції, одержувані при складанні динамічно генерованого коду, не зазнавали змін, атакуючий отримав би потужний примітив, який дозволяє створювати шеллкод в його пам'яті. Щоб уникнути цього, був введений ряд противомер:
  • NOPs
    В тіло програми випадковим чином вставляються NOP'и (інструкції, не змінюють стан оточення, єдина мета яких — посісти місце) різних розмірів — від одного до восьми байт. Вони потрібні, щоб виключити можливість появи константных послідовностей байт в зібраному коді.
    void Assembler::Nop(int n) {
    // The recommended muti-byte sequences of NOP instructions from the Intel 64
    // and IA-32 Architectures Software developer's Manual.
    //
    // Length Assembly Byte Sequence
    // 2 bytes 66 NOP 66 90H
    // 3 bytes NOP DWORD ptr [EAX] 0F 1F 00H
    // 4 bytes NOP DWORD ptr [EAX + 00H] 0F 1F 40 00H
    // 5 bytes NOP DWORD ptr [EAX + EAX*1 + 00H] 0F 1F 44 00 00H
    // 6 bytes 66 NOP DWORD ptr [EAX + EAX*1 + 00H] 66 0F 1F 44 00 00H
    // 7 bytes NOP DWORD ptr [EAX + 00000000H] 0F 1F 80 00 00 00 00H
    // 8 bytes NOP DWORD ptr [EAX + EAX*1 + 00000000H] 0F 1F 84 00 00 00 00 00H
    // 9 bytes 66 NOP DWORD ptr [EAX + EAX*1 + 66 0F 1F 84 00 00 00 00
    // 00000000H] 00H
    ...
    }

  • Constant Folding
    Арифметичні вирази підраховуються (згортаються) під час складання коду:
    <script>
    x = 0x123 + 0x567; // == 0x68A
    </script>

    mov rax,68A00000000h

  • Constant Blinding
    Тільки значення до двох байт зберігаються у коді без змін. Наприклад:
    <script>
    a = 0x1234;
    </script>

    Буде зібраний в:
    ...
    mov rax,123400000000h
    ...

    Константи більшого розміру ксорятся з випадковим значенням (jit_cookie):
    void MacroAssembler::SafeMove(Register dst, Smi* src) {
    ...
    if (IsUnsafeInt(src->value()) && jit_cookie() != 0) {
    if (SmiValuesAre32Bits()) {
    // JIT cookie can be converted to Smi.
    Move(dst, Smi::FromInt(src->value() ^ jit_cookie()));
    Move(kScratchRegister, Smi::FromInt(jit_cookie()));
    xorp(dst, kScratchRegister);
    } else {
    DCHECK(SmiValuesAre31Bits());
    int32_t value = static_cast<int32_t>(reinterpret_cast<intptr_t>(src));
    movp(dst, Immediate(value ^ jit_cookie()));
    xorp(dst, Immediate(jit_cookie()));
    }
    } else {
    Move(dst, src);
    }
    }

  • Guard Pages
    Буффер, що містить зібраний JIT код, обрамляється PAGE_NOACCESS сторінками, щоб запобігти його не можна перезаписати, якщо трапиться переповнення хіпа в довколишніх аллокациях.
  • JIT Page Randomization
    Розташування пам'яті, де буде розміщуватися зібраний JIT код, найчастіше (але не завжди) рандомизируется. Якщо вільний адресу не буде вгаданий з трьох спроб, Chrome дає системного аллокатору самому вибрати адреса для створюваного буффера.
    static void* RandomizedVirtualAlloc(size_t size, int action, int protection) {
    ...
    if (use_aslr &&
    (protection == PAGE_EXECUTE_READWRITE || protection == PAGE_NOACCESS)) {
    // For executable pages try and randomize the allocation address
    for (size_t attempts = 0; base == NULL && attempts < 3; ++attempts) {
    base = VirtualAlloc(OS::GetRandomMmapAddr(), size, action, protection);
    ...
    }
    void* OS::GetRandomMmapAddr() {
    ...
    static const uintptr_t kAllocationRandomAddressMin = 0x0000000080000000;
    static const uintptr_t kAllocationRandomAddressMax = 0x000003FFFFFF0000;
    ...
    uintptr_t address;
    platform_random_number_generator.Pointer()->NextBytes(&address,
    sizeof(address));
    address <<= kPageSizeBits;
    address += kAllocationRandomAddressMin;
    address &= kAllocationRandomAddressMax;
    return reinterpret_cast<void *>(address);
    }

Sandboxing
Chrome реалізує многопроцессную архітектуру, яка дозволяє призначити різні привілеї та обмеження для різних частин браузера. Одиниця, якою оперує пісочниця — це процес. Мінімальна конфігурація пісочниці Chrome включає в себе два процеси: один привілейований, званий брокером, і один (або більше) ізольований. Наприклад, як ізольовані процеси виділяються рендерер — инстансы движка Blink, отрисовывающие HTML документи. Рендерер запускаються для вкладок веб-сторінок і для браузерних розширень. Ризик компрометації рендерера великий, тому що всередині нього відбувається інтерпретація різнорідного коду, який завантажується з будь-яких джерел, які користувач буде серфити. Крім рендереров, окремі процеси — це контейнери плагінів (flash), допоміжні — crash репортер, gpu акселератор для графіки. Рендерер та інші використовують IPC (inter-process communication) для запитів доступу до ресурсів із брокера. Вони делегують такі виклики API брокеру допомогою IPC, брокер звіряє делегований виклик з політикою, специфицируемой для кожного ізольованого процесу, дозволені виклики виконуються, а результат повертається через той же IPC-механізм назад.
sbox_top_diagram
Модель пісочниці Chrome, джерело
Засоби Windows, на яких заснована ізоляція процесів Chrome:
  • Access token (маркер доступу)
  • Job object
  • object Desktop
  • Integrity Levels (рівні довіреності)
  • AppContainer
  • Windows Mitigation Policies
Варто ще раз зауважити, що є взаємодія між ізольованими процесами і привілейованим брокером, означає вихід з пісочниці може бути здійснено не тільки через слабкості перерахованих вище системних механізмів, але і через експлуатацію уразливості брокера, досяжну через IPC. Такий підхід був продемонстрований Pinkie Pie на Mobile Pwn2Own 2013, у зв'язці з RCE, яку ми вже розглянули раніше в цій статті: див. Part II, линк.
Access token
Маркер доступу містить SID-и — ідентифікатори суб'єктів доступу: користувачів і груп. Ізольованим процесів встановлюється маркер, що містить NULL SID (S-1-0-0), для якого у системі навряд чи знайдеться об'єкт, що володіє ACL, який може бути отриманий.
nullsid
Яким чином такий процес отримує хендл якого-небудь файлу? На API-функції (тут — ZwCreateFile) встановлюються звичайні хуки, дзвінок переадресовується через модулі пісочниці брокеру, брокер відкриває файл і дублює хендл назад.
ntdllhook
Job object
Включає в себе деякі спеціальні обмеження, пов'язані з ресурсами, не керованими ACL. Цією сутністю забороняється створення дочірніх процесів, читання/запис буфера обміну та інше. Докладніше.
jobobj
object Desktop
Для ізольованих процесів Chrome створюється окремий об'єкт робочого столу для того, щоб запобігти взаємодія з іншими процесами, передаючи повідомлення їх вікон.
Чим небезпечна така взаємодія? Це стара слабкість архітектури Windows, яка використовувалася для виконання т. н. Shatter Attack. Віконні повідомлення аж до Vista були анонімні і могли надсилатися до будь-якого процесу. Особливо пікантну можливість давало повідомлення WM_TIMER з адресою функції, за яким передасть управління цільовою процес без будь-якої участі з свого боку.
В Vista і наступних версіях була обмежена передача повідомлень між процесами виходячи з їх Integrity level (рівень довіреності): User Interface Privilege Escalation. Менш привілейовані процеси більше не можуть відправляти повідомлення більш привілейованим.
Integrity levels, AppContainer
Механізми розмежування доступу Windows, про них ми писали в попередній статті.
Windows Mitigation Policies
Набір нових security-фіч ОС Windows, які можуть бути включені для процесів, що частково перекривають можливості EMET (Enhanced Mitigation Experience Toolkit). Тут такі можливості, як відключення завантаження шрифтів (парсятся в ядрі Windows), модулів у свій процес, також — створення процесів.
Заборона на створення процесів перетинається з тим, що вже зроблено в Job object для ізольованих процесів Chrome, але в Job object був виявлений один кумедний пробіл. Обхід полягає у виклику API AllocConsole, яка створює консольне вікно програми, а для консольного вікна системою буде запущений хост-процес conhost.exe. Докладніше про цих політиків і їхніх слабкостях можна почитати у дослідника James Forshaw презентации.
ProcessSystemCallDisablePolicy / Win32k.sys Lockdown
Цю політику ми розглянемо окремо.
Графічна підсистема Windows справно поставляє LPE-уразливості вже багато років. У випадку з браузерних атаками, їх використовують після RCE. Отримавши виконання коду в процесі-рендері, експлоїт підвищує привілеї через вразливість Windows, тим самим отримуючи повний доступ до системи. Проілюструвати це можна добре документованим експлойтів для уразливості kernel pool corruption в win32k, який продемонстрували дослідники MWR Labs на Pwn2Own 2013 в зв'язці з RCE в Chrome: статья презентация.
Уразливість була виявлена в оброблювачі виклику, який використовується для передачі повідомлень між вікнами:
W32KAPI LRESULT NtUserMessageCall( IN HWND hwnd, IN UINT msg, IN WPARAM wParam, IN LPARAM lParam, IN ULONG_PTR xParam, IN DWORD xpfnProc, IN BOOL bAnsi);
. Останній параметр bAnsi визначає кодування тексту повідомлення, яке копіюється з викликало сервіс процесу в пам'ять ядра: WCHAR або ASCII — 2 або 1 байт на символ. І цей параметр інтерпретувався по-різному при алокації буфера в пулі ядра і при копіюванні повідомлення в буфер — спочатку як bool, потім як бітова маска. Це дало можливість заповнити буфер, скопіювавши в нього в два рази більше байт. Таким чином маніпулюючи даними в ядрі, домоглися виконання шеллкода в ring0, шеллкод обнулив ACL привілейованого процесу winlogon.exe, тобто залишив його беззахисним перед тривіальної ін'єкцією коду. Profit!
win32ksys
Проблема win32k
Розробка цієї простої, на перший погляд, противомеры зайняла багато часу і сил, так як вимагає модифікації не тільки самого коду Chrome, але і координації з командами розробки Adobe Flash Player і Pdfium (lockdown потрібен не тільки для процесів-рендерів, але і для PPAPI процесів, де виконуються плагіни). Інженери Google додали в стек спілкування Flash з win32k свій брокер. На поточний момент повноцінна реалізація lockdown існує тільки для Windows 10, оскільки сама операційна система надає можливості фільтрації системних викликів. Дуже рекомендуємо ознайомитися з документом, описує проблеми і рішення цього засобу захисту.
Висновок
Сильна сторона Chrome — це, звичайно, пісочниця. Тут ми бачимо широкий набір способів обмеження повноважень для пом'якшення наслідків експлуатації вразливостей в кодовій базі рендерера. Набір цих способів залежить від того, що пропонує нам операційна система, у свіжих версіях Windows було додано багато нового і цікавого. Крім того, велику увагу приділено управління динамічною пам'яттю, яка залишається на задньому плані при створенні нових фіч браузера для сучасного вебу, але має першорядне значення з точки зору безпеки. Розробники впровадили прогресивну систему збирання сміття і отримали нові властивості середовища, в якому виконуються компоненти браузера, не характерні для звичайних C + + додатків.
Автори
  • Турченков Дмитро / @d-t
  • Бубрыгин Ігор / @igor1024
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.