ASLR: «невловимі» адреси

Сучасні процесори мають адресну шину шириною 64 біт, проте декілька біт спочатку відводиться під інші завдання. Наприклад, NX-біт перешкоджає виконанню даних DEP (Data Execution Prevention). При спробі виконати код, який знаходиться в ділянці пам'яті, позначеному «не для виконання», виникає внутрішня помилка. У Windows відключити DEP для 64-бітних програм і драйверів не можна, зате для 32-бітових (все ще досить поширених) - без проблем. Це дозволяє зловмисникам викликати переповнення буфера. У результаті вони можуть інфікувати такі процеси, як Internet Explorer, і проникнути всередину системи. Після того як шкідник закріпився в Windows, він може використовувати Windows-API в своїх інтересах - наприклад, для того, щоб вважати потрібні йому дані або змінити конфігурацію системи.

Тому Microsoft ввела нову функцію захисту ядра - Address Space Load Randomization (ASLR, «рандомізація адресного простору»). Частково вона була реалізована вже в SP2 для ХР, але повністю - тільки в Vista. Її суть полягає в наступному. У Windows вхідними воротами для зловмисників зазвичай є бібліотеки DLL, які в попередніх версіях системи завжди завантажувалися в одні й ті ж ділянки пам'яті. З ASLR системні DLL і виконувані файли при кожному завантаженні системи потрапляють в різні ділянки оперативної пам'яті, щоб шкідливе ПЗ більше не могло атакувати системні операції за стандартними адресами. Для цього менеджер пам'яті має в своєму розпорядженні 256 різних адрес і при завантаженні DLL вибирає один з них випадковим чином. Така «плаваюча» стратегія ASLR має додаткову перевагу: адресний простір упаковано щільніше, ніж у більш ранніх версіях Windows, так що безперервних вільних ділянок у пам'яті залишається більше.

У спеціальних дистрибутивах Linux, таких як Hardened Gentoo, ASLR вже повністю реалізована. У стандартному ж ядрі міститься лише неповний варіант. У сучасному OS X Build ASLR використовується для кількох бібліотек, але їх повноцінна реалізація, на жаль, відсутня.

Перевірка автентичності: надійний код

В якості протиотрути Microsoft використовує в Vista підпис коду в режимі ядра (KMCS), яка дозволяє завантажувати лише ті драйвери пристроїв, які забезпечені цифровим підписом. Більшість драйверів отримують підпису через лабораторію WHQL (Windows Hardware Quality Lab), проте розробники можуть підписувати свій код самі - правда, для цього їм потрібен дійсний сертифікат. Windows перевіряє також, чи має виданий сертифікат відношення до одного з центрів сертифікації, дані про які містяться в завантажувача Windows і ядрі ОС. Треба сказати, що 32-бітні системи Vista хоча і перевіряють цифрові підписи драйверів, все-таки дозволяють завантажити непідписані драйвери. У 64-бітних Windows такий номер не пройде.

Всі модулі ядра в Mac OS X і Linux, в принципі, можуть мати цифровий підпис. Хоча теоретично це відноситься і до драйверів, ніяких механізмів перевірки в цих операційних системах не вбудовано.

MMCSS: пріоритет відео

Планувальник Windows жонглює декількома процесами, відкритими одночасно. Кожна програма на певний час дістає доступ до обчислювальних потужностей центрального процесора, і поступається місцем іншим і чекає знову своєї черги. Щоб такого не відбувалося, наприклад, коли ви дивитеся фільм, в Windows вбудовані спеціальні функції для мультимедійних файлів. Тому антивіруси та служби Windows в основному працюють у фоновому режимі і не заважають перегляду.

У Vista пріоритет фільмів і музики забезпечується службою планування мультимедійних класів - MMCSS. Для цього мультимедійне додаток, таке як Media Player, спочатку має зареєструватися в цій службі. Дана служба, реалізована у файлі% SystemRoot% \ System32 \ Mmcss.dll, включає в себе потік для управління пріоритетами. Windows передбачає ступені пріоритетності від 0 до 31, при цьому MMCSS має дуже високу пріоритетність - 27. Відповідно, пріоритетність всіх зареєстрованих мультимедійних потоків піднімається до 27. З 16-го ступеня починається режим реального часу, тобто потоку з пріоритетом 16 інші перешкодити вже не можуть.