Інформаційна безпека

Як помилку Spectre, здатну зламати індустрію, тримали в таємниці сім місяців

Коли дослідник Майкл Шварц з Грацского технічного університету вперше зв’язався з компанією Intel, він думав, що засмутить її. Він знайшов проблему в їх чіпах, працюючи спільно з колегами — йому допомагали Деніел Грасс, Моріц Лип і Стефан Мангард. Уразливість була глибокою і легко використовується. Його команда закінчила писати експлоїт 3-го грудня, недільним днем. Оцінивши можливі наслідки своєї знахідки, вони негайно написали в Intel.

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

Проблема, яку виявив Шварц — і, як він потім дізнався, багато хто ще — потенційно була катастрофічною. Уразливість на рівні схеми чіпа, яка могла сповільнити роботу будь-якого процесора в світі, при відсутності ідеального виправлення за винятком переробки всього чіпа. Вона вразила практично всі великі технокомпании світу, від серверних ферм Amazon до виробників чіпів зразок Intel та ARM. Але Шварц зіткнувся з ще однією проблемою: як зберігати у секреті таку серйозну уразливість досить довго, щоб її можна було виправити?

Розкриття — стара проблема в світі безпеки. Коли дослідник знаходить баг, зазвичай прийнято давати виробникам кілька місяці фори на виправлення проблеми до того, як вона стає доступною широкому загалу та у поганих людей з’являться шанси її використовувати. Але чим більше компаній і продуктів схильне знайденим проблем, тим складніше стає цей танець. Чим більше програм потрібно по-тихому розробити і просунути, тим більшій кількості людей потрібно повідомити про проблему і попросити тримати її в секреті. У випадку з Meltdown і Spectre ця координація по утриманню секретів провалилася і секрет виявився раніше, ніж хто-небудь встиг до нього підготуватися.

У передчасного розкриття є наслідки. Після оприлюднення інформації настає плутанина — наприклад, схильні чіпи від AMD атак Spectre (піддані) або характерний чи Meltdown тільки для Intel (чіпи від AMD теж постраждали). Антивірусні системи виявилися заскоченими зненацька, і ненавмисно заблокували безліч критичних патчів. Розробку інших патчів довелося призупинити після того, як комп’ютери переставали працювати з-за них. Один із кращих інструментів, придатних для виправлення уразливості, Retpoline, розробляла команда з реагування на події Google, і спочатку вони планували випустити його одночасно з інформацією про ба. Але хоча команда розробників Retpoline стверджує, що її не застали зненацька, код цього інструменту не викладали в загальний доступ аж до дня, наступного за тим, коли вперше було оголошено про наявність уразливості, зокрема з-за випадкового прориву секретності.

Що найбільше хвилює, так це що багато критично важливі групи, що реагують на уразливості, взагалі були не в курсі, що відбувається. Найвпливовіше попередження з приводу наявної уразливості прийшло з підрозділу CERT Карнегі-Мелон, що працює з Міністерством внутрішньої безпеки з питань оприлюднення уразливостей. Але, згідно головному аналітику вразливостей Уилу Дорману, в CERT не знали про цю проблему до тих пір, поки не були запущені сайти Meltdown і Spectre, що призвело до посилення хаосу. У початковому звіті заміна ЦП була вказана як єдине рішення. Технічно така рада був правильним у випадку з помилкою в схемі процесорів, але він лише примножив паніку серед менеджерів в сфері IT, які представили собі, як вони вибивають і замінюють ЦП на всіх підзвітних пристроях. Через кілька днів Дорман з колегами вирішили, що їх рада на практиці непридатний, і замінили рекомендацію на просту установку патчів.

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

Але, можливо цих проблем можна було уникнути? Навіть Дорман в цьому не впевнений. «Це найбільша множинна вразливість, з якою ми коли-небудь мали справу, — сказав він мені. — З вразливістю таких масштабів неможливо вийти сухим з води так, щоб всі залишилися задоволені».

Перший крок у розкритті вразливостей Meltdown і Spectre був зроблений шість місяців тому, до відкриття Шварца, в листі від 1 червня, відправленому Яном Хорном, учасником проекту Google Project Zero. Лист, надісланий до Intel, AMD і ARM, розписувалася нова уразливість, яка отримає назву Spectre, і демонструвався експлоїт процесорів Intel і AMD, і неприємні наслідки для ARM. Хорн підійшов до цього з обережністю і видав виробникам лише необхідний мінімум інформації. Він спеціально звернувся до трьох виробників чіпів, і закликав кожну компанію розібратися з тим, як їй самій зрадити справу розголосу і зв’язатися з іншими компаніями, на яких ситуація може позначитися. У той же час Хорн попередив їх, щоб вони не поширювали інформацію занадто далеко і занадто швидко.

«Врахуйте, що поки ми не повідомили про це в інші відділи Google, — писав Хорн. — Повідомляючи про це третім особам, намагайтеся не поширювати інформацію без потреби».

Досить складною справою виявилося встановити, хто саме схильний уразливості. Почалося все з виробників чіпів, але незабаром стало зрозуміло, що необхідно буде патчити операційні системи, що вимагало залучення ще одного кола дослідників. Це має вплинути і на браузери, а також на масивні хмарні сервіси, керовані компаніями Google, Microsoft і Amazon, які можна було вважати найбільш привабливими цілями для нового бага. У підсумку десяткам компаній зі всіх кінців світу доведеться випускати той чи інший патч.

Офіційною політикою Project Zero було надавати 90 днів перед публікацією новин, але чим більше компаній приєднувалося до кола обраних, тим сильніше Project Zero поступався своїм вимогам, і продовжив цей період більше, ніж у два рази. Йшли місяці, компанії почали випускати власні патчі, намагаючись приховати, що саме вони виправляли. Команда реагування на події з Google отримала інформацію в липні, через місяць після першого попередження від Project Zero. Програма Microsoft Insiders випустила тихий ранній патч в листопаді. У цей період директор Intel Брайан Кржаніч здійснював більш спірні дії, в жовтні замовивши автоматичну продаж акцій на 29-е листопада. 14 грудня клієнти Amazon Web Server отримали попередження, що 5 січня хвиля перезавантажень комп’ютерів може позначитися на швидкодії. Ще один патч від Microsoft був скомпільований і випущений в переддень Нового року, що говорить, що команда компанії, ймовірно, працювала над ним всю ніч. У кожному з випадків причини змін були розмитими, і користувачі мало що знали про те, що саме виправляється.

Однак не можна переписати основи інфраструктури інтернету, щоб це хтось не помітив. Самі товсті натяки прийшли зі світу Linux. Ця ОС, на якій працює більшість хмарних серверів в інтернеті, зобов’язана відігравати велику роль в будь-якому виправлення помилок Spectre і Meltdown. Але, так як вихідний код цієї системи відкритий, будь-які зміни доведеться пред’являти громадськості. Кожен апдейт викладався на відкритий Git-репозиторій, і всі офіційні обговорення проходили на загальнодоступному списку розсилки. Коли для загадкової функції page table isolation» один за одним почали виходити патчі для ядра ОС, пильно спостерігали за цим люди зрозуміли, що щось не так.

Найбільшим натяком стало подія від 8 грудня, коли Лінус Торвальдс прийняв новий патч, змінювало те, як ядро Linux працює з процесорами x86. «Це виправлення, крім того, що виправляє витоку KASLR), також посилює код для x86», — пояснив Торвальдс. А самий останній випуск ядра вийшов всього за день до цього. Зазвичай патч повинен був почекати включення в наступний реліз, але з якоїсь причини цей патч був дуже важливим. Чому ж зазвичай примхливий Торвальдс раптом так просто включив позаштатне оновлення, особливо якщо воно начебто може сповільнити роботу ядра?

Ще дивніше виглядало раптом з’явилося лист місячної давності, в якому пропонувалося оновити старі ядра новим патчем заднім числом. Підсумовуючи чутки, 20-го грудня ветеран Linux Джонатан Корбет написав, що проблема з таблицею сторінок «має всі ознаки патча безпеки, випущеного під тиском дедлайну».

І все ж їм було відомо не все. Page Table Isolation, «ізоляція таблиці сторінок» — це спосіб відокремити простір ядра від простору користувачів, тому проблема явно була в якійсь витоку з ядра. Але залишалося незрозумілим, що саме неправильно працювало в ядрі або як далеко поширювалася дія цього бага.

Наступне звістка надійшла від самих виробників чіпів. У новому патчі Linux описав всі процесори x86 як вразливі, включивши туди і процесори від AMD. Оскільки патч занижував швидкодію, AMD була не рада включенню цього патча. На наступний день після Різдва [католицького, 25 грудня / прим. перекл.] інженер AMD Тому Лендаки відправив лист в список розсилки по ядра Linux, пояснюючи, чому саме чіпам AMD патч не вимагався.

«Мікроархітектура AMD не дозволяє оперувати такими посиланнями на пам’ять, у тому числі спекулятивними, які отримують доступ до привілейованих даними, працюючи в менш привілейованому режимі, в тих випадках, коли такий доступ може призвести до помилки „page fault“, — писав Лендаки.

Вся ця історія переповнена технічними термінами, але для всіх людей, які намагалися з’ясувати сутність помилки, вона звучала, як пожежна тривога. Інженер з AMD точно знав про уразливості, і говорив, що проблема ядра виникала з чогось такого, що процесори роблять вже майже 20 років. Якщо проблемою були спекулятивні посилання, ця проблема стосувалася всіх — і для її виправлення повинно знадобитися щось набагато більше, ніж просте виправлення ядра.

»Це послужило поштовхом, — говорить Кріс Вільямс, редактор The Register. — До того моменту ніхто не згадував спекулятивні посилання на пам’ять. Тільки після появи цього листа ми зрозуміли, що щось не так”.

Коли стало ясно, що проблема пов’язана зі спекулятивними посиланнями, дослідники змогли домалювати картину до кінця. Роками дослідники безпеки шукали методи злому ядра через спекулятивне виконання програм; команда Шварца з Граца опублікувала роботу з цього приводу аж у червні. Андерс Фог опублікував свої спроби схожих атак в липні, хоча вони і не увінчалися успіхом. Всього через два дні після листа з AMD дослідник під ніком brainsmoke представив роботу по цій темі на конференції Chaos Computer Congress в Лейпцигу. Всі ці роботи не привели до відкриття бага, придатного для експлуатації, але завдяки ним стало ясно, як він повинен виглядати і виглядав він вкрай погано.

Фог сказав, що з самого початку було зрозуміло — будь-який робочий баг обернеться катастрофою. «Коли ви починаєте вивчати щось подібне, ви вже знаєте, що ваш успіх призведе до дуже поганих наслідків», — сказав він мені. Після випуску Meltdown і Spectre і вибухнула хаосу, Фог вирішив не публікувати подальші дослідження з цієї теми.

На що послідувала тижня чутки про ба стали просочуватися через Twitter, списки розсилки і форуми. Звичайний вимірювач швидкості, коли м’ч пролетів у списку розсилки PostgreSQL, виявив 17% уповільнення швидкодії — жахливе число людей, що чекали патч. Інші дослідники писали неформальні пости, описуючи все, що їм відомо, і підкреслювали, що це всього лише чутки. «Ця стаття в основному надає здогадки, до тих пір, поки не буде скасовано ембарго», — писав один з авторів. «А в цей день слід очікувати феєрверків і драматичних подій».

До Нового року чутки стало неможливо ігнорувати. Вільямс вирішив, що пора щось написати. 2-го січня The Register опублікувала статтю про те, що вони назвали «недоліком в схемі процесорів Intel». Там описувалося те, що відбувалося в списку розсилки Linux, зловісне лист з AMD, і ранні дослідження. «З того, що описав програміст Тому Лендаки з AMD, слід, що ЦП від Intel грішать спекулятивним виконанням коду без перевірок на безпеку», — йшлося в статті. — Це дозволить користувача кодом рівня ring-3-level читати дані з рівня ядра ring-0-level. А це недобре”.

Рішення про публікації цієї статті виявилося суперечливим. Індустрія передбачала існування ембарго на поширення інформації, що дає компаніям час на випуск патчів. Раннє поширення новин урізав цей час, і давало злочинцям шанси використовувати уразливості до появи патчів. Але Вільямс стверджує, що до часу виходу статті секрет вже був розкритий. «Я вважав, ми повинні попередити людей, що, коли ці патчі вийдуть, їх необхідно точно встановлювати, — каже Вільямс. — Якщо ви досить розумні, щоб використовувати такий баг, ви б і без нас про нього здогадалися».

І в будь-якому випадку ембарго протрималося б ще один день. Офіційний випуск планувався на 9 січня, одночасно з четверговыми патчами від Microsoft і прямо в розпал виставки споживчої електроніки Consumer Electronics Show, що могло б приглушити погані новини. Але комбінація з диких чуток і доступних дослідників зробила неможливим стримування новин. Репортери закидали дослідників листами, і всі, хто мав до цього відношення, з усіх сил намагався зберігати мовчання, оскільки ймовірність того, що секрет протримається ще тиждень, постійно зменшувалася.

Переломний момент настав завдяки brainsmoke. Він був одним з малого числа дослідників ядра, на яких не поширювалося ембарго, тому він сприйняв чутки як керівництво до дії і вирішив відшукати цей баг. На наступний ранок після статті в The Register він його знайшов, і твитнул скріншот свого терміналу в якості доказу. «Ніяких page fault не потрібно, — писав він у подальшій твіті. — Основне питання, судячи з усього, міститься в тому, щоб перетягнути все в кеш і з кешу».

Bingo! #kpti #intelbug pic.twitter.com/Dml9g8oywk

— brainsmoke (@brainsmoke) January 3, 2018

Коли дослідники побачили цей твіт, все і закрутилося. Команда з Граца твердо вирішила не розкривати карти Google або Intel, але після поширення доказів можливості використання бага з Google надійшло повідомлення про те, що ембарго буде скасовано в той же день, 3 січня, в 2 години дня за тихоокеанським часом. У призначену годину повна версія дослідження з’явилася на двох спеціально підготовлених сайтах, разом з попередньо підготовленими логотипами кожної з вразливостей. Повідомлення потекли рікою з ZDNet, Wired і The New York Times, часто описуючи інформацію, зібрану всього за кілька годин до цього. Після більш ніж семи місяців планування секрет, нарешті, вийшов назовні.

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

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

Кеті Муссурис допомагала писати в Microsoft інструкцію для подібних подій, спільно зі стандартами ISO і безліччю інших інструкцій. Коли я попросив її оцінити реакцію громадськості на цьому тижні, вона описала її м’якше, ніж я очікував.

«Можливо, краще вже не можна було нічого зробити, — сказала вона. — Стандарти ISO можуть сказати вам, про що потрібно задуматися, але вони не скажуть вам, що робити на піку розвитку подібної ситуації. Це схоже на те, як ви читаєте інструкції і виконуєте парочку навчальних тривог. Добре, коли є план, але коли ваш будинок горить, ви дієте не так, як написано в плані».

Чим більше технологія централізується і обростає внутрішніми зв’язками, тим складніше стає уникати подібних пожежних тривог. З поширенням протоколів типу OpenSSL збільшується ризик масивних багів начебто Heartbleed, інтернет-версії хвороби зернових культур. Цей тиждень продемонструвала подібний ефект, що впливає на залізо. Спекулятивне виконання стало стандартом індустрії до того, як у нас був час на забезпечення його безпеки. І оскільки велика частина веб-сервісів виконується на одних і тих же чіпах і на одних і тих же хмарних сервісах, цей ризик збільшується багаторазово. І коли уразливість нарешті виявилося, в результаті завдання її правильного освітлення стала майже нездійсненним.

Подібної плутанини важко уникнути за будь відмову ключових технологій. «У 90-х у нас був девіз — одна уразливість, один виробник, і таких вразливостей було більшість. А тепер практично де завгодно присутній елемент координації кількох зацікавлених сторін, — говорить Муссурис. — Ось так і виглядає реальне висвітлення проблем, пов’язаних з роботою кількох зацікавлених сторін».

Related Articles

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Close