[Перевод] Как ошибку 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 не нужно, — писал он в последовавшем твите. — Основной вопрос, судя по всему, содержится в том, чтобы перетаскивать всё в кэш и из кэша».
Когда исследователи увидели этот твит, всё и завертелось. Команда из Граца твёрдо решила не раскрывать карты до Google или Intel, но после распространения доказательств возможности использования бага из Google поступило сообщение о том, что эмбарго будет отменено в тот же день, 3 января, в 2 часа дня по тихоокеанскому времени. В назначенный час полная версия исследования появилась на двух специально подготовленных сайтах, вместе с предварительно подготовленными логотипами каждой из уязвимостей. Сообщения потекли рекой из ZDNet, Wired и The New York Times, часто описывая информацию, собранную всего за несколько часов до этого. После более чем семи месяцев планирования секрет, наконец, вышел наружу.
Пока сложно сказать, во сколько обошёлся ранний выход. Патчи всё ещё разрабатываются, а измерители скорости ещё подсчитывают итоговые потери. Прошло бы всё более гладко, если бы на подготовку была ещё одна лишняя неделя? Или она просто оттянула бы неизбежное?
Можно найти множество формальных документов, описывающих, как должен происходит анонс подобных уязвимостей, например, у международной организации по стандартам, у министерства торговли США, у CERT — хотя у них можно найти мало чётких советов по поводу настолько серьёзной проблемы. Эксперты годами мучаются с подобными вопросами, и самые опытные из них уже отчаялись найти идеальный ответ.
Кэти Муссурис помогала писать в Microsoft инструкцию для подобных событий, совместно со стандартами ISO и бесчисленным количеством прочих инструкций. Когда я попросил её оценить реакцию общественности на этой неделе, она описала её мягче, чем я ожидал.
«Возможно, лучше уже нельзя было ничего сделать, — сказала она. — Стандарты ISO могут сказать вам, о чём нужно задуматься, но они не скажут вам, что делать на пике развития подобной ситуации. Это похоже на то, как вы читаете инструкции и выполняете парочку учебных тревог. Хорошо, когда есть план, но когда ваш дом горит, вы действуете не так, как написано в плане».
Чем больше технология централизуется и обрастает внутренними связями, тем сложнее становится избегать подобных пожарных тревог. С распространением протоколов типа OpenSSL увеличивается риск массивных багов вроде Heartbleed, интернет-версии болезни зерновых культур. Эта неделя продемонстрировала сходный эффект, влияющий на железо. Спекулятивное выполнение стало стандартом индустрии до того, как у нас было время на обеспечение его безопасности. И поскольку большая часть веб-сервисов выполняется на одних и тех же чипах и на одних и тех же облачных сервисах, этот риск увеличивается многократно. И когда уязвимость наконец проявилось, в результате задача её правильного освещения стала почти невыполнимой.
Подобной неразберихи тяжело избежать при любом отказе ключевых технологий. «В 90-х у нас был девиз — одна уязвимость, один производитель, и таких уязвимостей было большинство. А теперь практически где угодно присутствует элемент координации нескольких заинтересованных сторон, — говорит Муссурис. — Вот так и выглядит реальное освещение проблем, связанных с работой нескольких заинтересованных сторон».
