APIC/EPIC! Мікросхеми Intel розкривають секрети, які навіть ядро ​​не повинно побачити…

Ось BWAIN цього тижня, наш жартівливий термін для a Помилка з вражаючою назвою.

BWAIN — це нагорода, яку ми вручаємо, коли новий недолік кібербезпеки не тільки виявляється цікавим і важливим, але й з’являється з власним логотипом, доменним іменем і веб-сайтом.

Цей дубльований Витік ÆPIC, каламбур на слова APIC та EPIC.

Перше скорочено Розширений програмований контролер переривань, а останнє — це просто слово «епічний», як у гігант, масивний, екстремальний, мега, жалібний.

Літера Æ не використовувалася в письмовій англійській мові з саксонських часів. Його назва æsc, вимовляється ясен (як у дереві), і це майже відповідає звуку А в сучасному слові ASH. Але ми припускаємо, що ви повинні вимовити це слово ÆPIC тут або як «APIC-slash-EPIC», або як «ah!-eh?-PIC».

Про що це все?

Усе це породжує п’ять цікавих питань:

• Що таке APIC, а навіщо воно мені?
• Як ви можете мати такі дані навіть ядро не можу підглянути?
• Що спричинило цей епічний провал в APIC?
• Лі Витік ÆPIC впливати на мене?
• Що робити про це?

Що таке APIC?

Давайте повернемося в 1981 рік, коли вперше з'явився IBM PC.

ПК містив чіп під назвою Програмований контролер переривань Intel 8259A, або ПІК. (Пізніші моделі, починаючи з PC AT, мали два PIC, з’єднані разом, для підтримки більшої кількості подій переривань.)

Мета PIC полягала в буквальному сенсі переривання програми, що виконується на центральному процесорі (CPU) ПК, коли відбувалося щось критичне, що потребувало негайної уваги.

Ці апаратні переривання включали такі події, як: натискання клавіші на клавіатурі; послідовний порт, що отримує символ; і повторюваний апаратний таймер.

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

Як ви можете собі уявити, за PIC незабаром з'явився оновлений чіп під назвою APIC, просунутий свого роду PIC, вбудований у сам ЦП.

Сьогодні APIC забезпечує набагато більше, ніж просто зворотний зв’язок від клавіатури, послідовного порту та системного таймера.

Події APIC викликаються (і надають дані в реальному часі про) такими подіями, як перегрів, і дозволяють апаратну взаємодію між різними ядрами в сучасних багатоядерних процесорах.

А сучасні мікросхеми Intel, якщо ми можемо дуже спростити, можна налаштувати для роботи двома різними способами, відомими як режим xAPIC та Режим x2APIC.

Тут, xAPIC це «застарілий» спосіб вилучення даних з контролера переривань, і x2APIC це більш сучасний спосіб.

Ще більше спрощуючи, xAPIC покладається на те, що називається MMIO, скорочено введення/виведення, відображене в пам'яті, для зчитування даних з APIC, коли він реєструє цікаву подію.

У режимі MMIO ви можете дізнатися, що викликало подію APIC, зчитуючи певну область пам’яті (RAM), яка відображає регістри введення/виведення самої мікросхеми APIC.

Ці дані xAPIC відображаються в 4096-байтному блоці пам’яті десь у фізичній оперативній пам’яті комп’ютера.

Це спрощує доступ до даних, але вимагає дратівливої, складної (і, як ми побачимо, потенційно небезпечної) взаємодії між чіпом APIC і системною пам’яттю.

Навпаки, x2APIC вимагає від вас безпосередньо зчитувати дані APIC із самого чіпа, використовуючи так звані Спеціальні регістри моделі (MSR).

За словами Intel, уникнення частини процесу MMIO «забезпечує значно підвищену адресність процесора та деякі покращення доставки переривань».

Примітно, що вилучення даних APIC безпосередньо з вбудованих регістрів означає, що загальний обсяг підтримуваних даних і максимальна кількість ядер ЦП, якими можна керувати одночасно, не обмежуються 4096 байтами, доступними в режимі MMIO.

Як ви можете мати дані, до яких не може підглянути навіть ядро?

Ви, напевно, вже здогадалися, що дані, які потрапляють в область пам’яті MMIO, коли ви використовуєте режим xAPIC, не завжди обробляються так ретельно, як це повинно бути…

…і тому якийсь «витік даних» у цю область MMIO є серцевиною цієї проблеми.

Але враховуючи, що ви вже потрібні повноваження рівня системного адміністратора для читання даних MMIO в першу чергу, і тому ви майже напевно можете отримати будь-які дані в пам’яті в будь-якому випадку…

…чому те, що дані інших людей помилково з’являються в області даних APIC MMIO, означає епічний витік?

Це може трохи полегшити на практиці деякі типи атак із крадіжкою даних або оперативну пам’ять, але напевно це не дасть вам більше можливостей стежити за пам’яттю, які ви вже мали теоретично?

На жаль, це припущення не відповідає дійсності, якщо будь-яке програмне забезпечення в системі використовує Intel SGX, скорочення від Розширення Software Guard.

---

ДІЗНАЙТЕСЯ БІЛЬШЕ ПРО SGX

---

SGX підтримується багатьма останніми процесорами Intel і забезпечує ядру операційної системи спосіб «запечатати» фрагмент коду та даних у фізичний блок оперативної пам’яті, щоб утворити так званий анклав.

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

Після встановлення «блокування» SGX анклаву лише програмний код, що виконується всередині закритої області пам’яті, може читати та записувати вміст цієї оперативної пам’яті.

Як наслідок, внутрішні деталі будь-яких обчислень, які відбуваються після активації анклаву, невидимі для будь-якого іншого коду, потоку, процесу чи користувача в системі.

Включаючи саме ядро.

Існує спосіб викликати код, який було запечатано в анклаві, і спосіб повернути результат обчислень, які він може виконати, але немає способу відновити, або шпигувати, або налагодити код і його пов’язані дані під час його роботи.

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

Як ви можете собі уявити, якщо дані, які мають бути запечатані всередині анклаву SGX, колись випадково скопіюються в MMIO RAM, який використовується для «дзеркалювання» даних APIC, коли ви використовуєте режим «відображення пам’яті» xAPIC…

…це порушило б безпеку SGX, згідно з якою жодні дані ніколи не повинні з’являтися з анклаву SGX після його створення, якщо вони не навмисно експортовані за допомогою коду, який уже виконується в самому анклаві.

Що викликає цей епічний збій в APIC?

Дослідники за Папір для витоку ÆPIC виявив, що, організувавши зчитування даних APIC за допомогою хитрої та незвичної послідовності звернень до пам’яті…

…вони можуть обманом змусити процесор заповнити простір APIC MMIO не лише даними, щойно отриманими від самого APIC, але й даними, які нещодавно використовувалися процесором для інших цілей.

Така поведінка є побічним ефектом того факту, що хоча сторінка пам’яті APIC MMIO має розмір 4096 байт, мікросхема APIC у режимі xAPIC фактично не створює даних розміром 4096 байт, і ЦП не завжди правильно нейтралізує невикористані частини області MMIO, заповнивши її спочатку нулями.

Замість цього старі дані, що залишилися в кеші ЦП, були записані разом з новими даними, отриманими від самого чіпа APIC.

Як кажуть дослідники, помилка зводиться до того, що відомо як an читання неініціалізованої пам'яті, де ви випадково повторно використовуєте чужі дані, що залишилися в оперативній пам’яті, тому що ні вони, ні ви спочатку не очистили їх від попередніх секретів.

Чи впливає на мене витік ÆPIC?

Повний список чіпів, яких це стосується, див Власна консультація Intel.

Наскільки ми можемо судити, якщо у вас є процесор Intel 10-го або 11-го покоління, ви, ймовірно, постраждали.

Але якщо у вас абсолютно новий ЦП 12-го покоління (найновіший на момент написання статті), то, здається, це стосується лише чіпів серверного класу.

За іронією долі, у мікросхемах для ноутбуків 12-го покоління Intel відмовилася від SGX, тому ця помилка не стосується, оскільки неможливо мати будь-які «запечатані» анклави SGX, які могли б витікати.

Звичайно, навіть на потенційно вразливому чіпі, якщо ви не покладаєтеся на будь-яке програмне забезпечення, яке використовує SGX, ця помилка також не стосується.

І жучок, озвучений CVE-2022-21233, може використати лише зловмисник, який уже має локальний адміністративний (кореневий) доступ до вашого комп’ютера.

Постійні користувачі не може отримати доступ до блоку даних APIC MMIO, а отже, не має жодного способу заглянути в нього взагалі, не кажучи вже про секретні дані, які могли просочитися з анклаву SGX.

Крім того, гостьові віртуальні машини (Віртуальні машини), які працюють під керуванням операційної системи хоста в гіпервізорі, такому як HyperV, VMWare або VirtualBox, майже напевно не зможуть використати цей трюк для викрадення секретів інших гостей або самого хоста.

Це тому, що гостьові віртуальні машини зазвичай не отримують доступу до справжньої схеми APIC у головному процесорі; натомість кожна гостьова система отримує власний змодельований APIC, унікальний для цієї віртуальної машини.

Що ж робити?

Не панікуйте.

Якщо ви користуєтеся ноутбуком або настільним комп’ютером, ви можете взагалі не ризикувати, тому що у вас старий (або, на щастя, абсолютно новий!) комп’ютер, або тому, що ви все одно не покладаєтеся на SGX.

І навіть якщо ви ризикуєте, будь-хто, хто ввійде до вашого ноутбука як адміністратор/root, ймовірно, має достатньо влади, щоб створити вам цілий світ проблем.

Якщо у вас є вразливі сервери, і ви покладаєтеся на SGX як частину операційної безпеки, перегляньте рекомендації Intel щодо безпеки INTEL-SA-00657 для інформації про захист і пом'якшення.

За словами дослідників, які це написали, «Intel [випустила] оновлення мікрокоду та SGX Software Development Kit, щоб вирішити цю проблему».

Команда ядра Linux також, схоже, зараз працює над виправленням, яке дозволить вам налаштувати вашу систему таким чином, щоб вона завжди використовувала x2APIC (який, як ви пам’ятаєте раніше, не передає дані APIC через спільну пам’ять), і витончено запобігає примусовому поверненню системи в режим xAPIC після завантаження.

---