Першу частину циклу можна подивитися тут.
Продовжимо нашу сумну історію ...
Але спочатку ще раз про АМТ.
Поширена думка, що ця технологія присутня тільки в деяких сучасних чіпсетах Intel, і для уникнення проблем безпеки досить вибирати чіпсети без підтримки АМТ. На даному етапі це вже не вірно, останній чіпсет 7 серії у всіх модифікаціях підтримує дану технологію.
І ще, на жаль, проблема безпеки АМТ у нас абсолютно не обговорюється в силу безграмотності фахівців ІБ, але на заході повно публікацій на цю тему, з дуже жорсткими висновками. Наберіть в пошуковику: «Intel AMT backdoor» і переконайтеся самі.
Що там конкретно нарив Касперський так і не відомо, але загальне уявлення про реальні розборках в цій кремінної сфері можна отримати з ще двох подій вже не такого далекого минулого.
Між давніми суперниками процессоростроения стався великий конфлікт, що призвів до «сливу» конфіденційної інформації про бекдоров в процесорах.
Але незабаром «імперія» AMD завдала удару у відповідь.
До речі, фірма Intel назвала це недокументовану можливість обтічної фразою «специфічна реалізація» і не визнала цю «особливість» бекдоров або помилкою реалізації. Фірма так і поставляє процесора з цієї, як вона виражається; «Специфічної реалізацією команди SYSRET».
Тому всім великим розробникам комерційного софта довелося пропатчити власні продукти для обходу цієї «специфічної особливості виконання команди». Але цю вразливість команди SysRet можна експлуатувати з рівня драйверів і додатків, і їх може писати хто не попадя. Так що уразливість, що дозволяє підвищувати рівень привілеїв, присутній в процесорах Intel до справжнього моменту.
Наведеної вище інформації думаю досить для обгрунтування твердження про таємних протистояннях виробників процесорів і апаратних закладках в їх продукції. В силу периферійності нашої країни і убогості професійних знань «генералів» ІБ в цій сфері контролювати і брати участь в цих процесах зараз ми не в змозі, хоча могли б легкістю, будь на те хоча б найменше бажання.
Як не дивно, у нас, «як в Греції, - все є ...» необхідний науковий доробок в автоматизованій верифікації системи команд в країні є. Безсумнівним лідером в цій області є Інститут Системного Програмування Російської Академії Наук (ІСП РАН). На жаль, напрацювання в області автоматизованої верифікації процесорних структур цього інституту замість нашого власної держави використовує Корея, фірма Самсунг зокрема.
Ось і виходить, що маємо не цінуємо, а остаточно втративши, навіть не заплачемо ...
Але у цієї теми є й інша, хоч і легальна, але абсолютно непрозора сторона. Йдеться про механізми оновлення микрокода.
Пристрасті по мікрокоді
Трохи теорії, щоб ввести в курс справи. Процесора архітектури х86 мають змішане програмно-апаратне керування. Будь-яка команда для процесора х86 це набірмікрооперацій, прості команди це одна мікрооперація, а складні команди можуть складатися з сотень, а для деяких сучасних команд з тисяч микроопераций.
Прості команди (типу арифметичних, логічних) процесор виконує на комбінаторної логікою за одну микрооперацию, фактично це апаратне виконання команди.
Більш складні команди складаються з ланцюжків микроопераций з умовними переходами, циклами, перериваннями. Так ось, ці ланцюжки микроопераций і є мікропрограмами виконання команд процесора. Це звичайно дуже поверхове і спрощене пояснення механізму виконання команд на сучасних процесорах х86, але думаю, суть зрозуміла.
Всі прошивки виконання команд зберігаються в самому процесорі, в спеціальній незалежній пам'яті, і заливаються туди на етапі його виготовлення. Але, як відомо, у будь-якого програміста на тисячу рядків коду завжди знайдеться хоча б одна помилка, так що помилки в Мікропрограми бувають, і для оперативного їх виправлення використовується механізм патчів.
Іншими словами, вміст пам'яті мікропрограм можна підправити вже на діючому обладнанні, для цього використовуються спеціальні інформаційні блоки (microcode update).
У Intel все написано в документації (Vol. 3A глава 9.11 MICROCODE UPDATE FACILITIES). Механізм поновлення микрокода для процесорів AMD можна виявити на офіційному сайті, в документації він не описаний. Алгоритми поновлення микрокода у обох виробників практично однакові, відмінності тільки в структурі патча. Так що розберемо тему на основі офіційної документації Intel, ось витяг:
9.11 MICROCODE UPDATE FACILITIES
The Pentium 4, Intel Xeon, and P6 family processors have the capability to correct errata by loading an Intel-supplied data block into the processor. The data block is called a microcode update. This section describes the mechanisms the BIOS needs to provide in order to use this feature during system initialization. It also describes a specification that permits the incorporation of future updates into a system BIOS.
Intel considers the release of a microcode update for a silicon revision to be the equivalent of a processor stepping and completes a full-stepping level validation for releases of microcode updates.
A microcode update is used to correct errata in the processor. The BIOS, which has an update loader, is responsible for loading the update on processors during system initialization (Figure 9-7). There are two steps to this process: the first is to incorporate the necessary update data blocks into the BIOS; the second is to load update data blocks into the processor.
Механізм поновлення микрокода простий, кожен раз після подачі живлення або після видачі сигналу скидання (Reset) необхідно завантажити патч в усі процесорні ядра. Іншими словами, поточні патчі не зберігаються в незалежній пам'яті і їх потрібно кожен раз перезаписувати.
Структура патча складається з трьох частин, перша частина «Header» і остання «extended signature» описана в документації повністю, але вони не несуть істотного значення.
Найголовніша частина ( «Date» - розмір не фіксований), - тіло патча, не описана в документації, структура його не відома. Саме ця частина містить прошивки, які заміщають прошиті на етапі виробництва прошивки процесора. Фірми Intel і AMD не надають ніякої інформації для того щоб дізнатися хоча б якісь команди і режими роботи процесора піддаються зміні.
Передбачається (так сказано в документації), що процедура поновлення микрокода проводиться з БІОС, але немає ніяких обмежень на її проведення і під час подальшої роботи процесора. Іншими словами, патчить микропрограмму процесора можна до нескінченності і під час роботи операційної системи. Блокувань режиму поновлення микрокода в апаратурі процесора не передбачено, перевірки автентичності патча також немає. А ось це вже некоректно, і пахне бекдоров, прихованим під недокументованими можливостями
Перекладаючи на загальнозрозумілою мовою, є можливість в будь-який момент часу підправити алгоритм роботи будь-якої команди процесора, таким чином, щоб вона виконувала недокументовану функцію, потрібно тільки знати структуру інформаційного блоку, і тоді з будь-процесорної команди можна буде створити зовсім іншу, власну, за своїм смаком і розумінням.
Виробники процесорів регулярно поширюють офіційні оновлення микрокода, але списку виправлених помилок, або доданих оптимізацій немає. Є тільки номер патча, його можна контролювати після заливки в процесор.
Ідіотизм ситуації в тому, що ці оновлення повинні потрапити в процесор під час завантаження ОС, і, наприклад, Microsoft не повідомляє офіційної інформації про номер патча який вона вантажить.
Ось приклад такого файлу поновлення микрокода операційної системи Windows.
Іншими словами, немає можливості контролювати поточну прошивку микрокода навіть на рівні його номера. Також неможливо блокувати функцію оновлення микрокода апаратно, вона завжди доступна з нульового кільця привілеїв.
Ще однією проблемою стає БІОС материнських плат, там завжди є патч микрокода для процесора, але хто гарантує, що він коректний? Несумлінне спотворення його вмісту можливо і на етапі його створення в Інтел і на етапі заливки в БІОС при виробництві материнської плати.
Крім цього патч може оновлюватися під час оновлення БІОС материнської плати вже в процесі експлуатації обладнання та й просто замінити його в Біосе не проблема. Хоч якусь гарантію давала б цифровий підпис на патчі, але її наявність не передбачена в структурі блоку оновлення програмного забезпечення, виробники БІОС зовнішнього захисту на ці патчі теж не накладають.
Ось ми і підійшли до теми сучасних БІОС, але про це в наступній частині цього сумного циклу статей.
