Уязвимость Meltdown и Spectre в Linux

meltdown spectre linux

Вы не могли пропустить новости о Meltdown и Spectre — двух наиболее широко распространенных уязвимостях безопасности, затронувших миллионы CPU, использующихся на данный момент. Они были обнаружены независимо друг от друга командами, включающими, помимо прочих, Google Project Zero и исследователей из Технического университета города Грац [Technical University of Graz] в Австрии.

Когда утих шок, вызванный масштабом и степенью уязвимостей, возникли две вещи. Одной была всеобщая громкая критика того, как раскрытие информации об уязвимостях было передано акционерам программного обеспечения. Другой — звездный ответ сообщества ядра Linux для смягчения ущерба и сдерживания угроз с помощью программных обходных решений, компенсирующих уязвимость оборудования.

При более чем 25 миллионов строк кода, распределенных более чем по 61 000 файлов, распространяемых более чем 4300 разработчиками, ядро Linux — самый большой совместный программный проект в мире. Ловкость, продемонстрированная этим тяжеловесным ПО при устранении аппаратной уязвимости, похвальна и заслуживает более подробного рассмотрения. Как и сам процесс разработки ядра, процесс изоляции ядра от уязвимостей десятками вовлекал людей по всему миру. Основная команда разработчиков ядра формирует команду безопасности ядра Linux, помогающую создавать программную защиту ядра. Они координируют свои усилия с усилиями нескольких команд безопасности ядра в проектах различных дистрибутивов, которые участвуют в тестировании заплаток [patch] до обнародования уязвимости. Весь процесс, от обнаружения уязвимости до выхода заплатки ядра с исправлением, проходит быстро.

Мы подробно рассмотрим уязвимости Meltdown и Spectre и то, как с ними справляются, вовлекая в это всех, и это даст нам прекрасную возможность взглянуть на процесс изнутри и понять, какие усилия прилагаются перед тем, как появляется уведомление о новом обновлении ядра.

Текущий куратор Linux — Грег Кроа-Хартман [Greg Kroah-Hartman] недавно написал в своем блоге о том, как команда ядра справляется с угрозами безопасности. Грег отмечает, что сообщество ядра Linux почти никогда не называет конкретные изменения «исправлениями безопасности». Он объясняет это сложностью в определении на момент создания, касается ли исправление безопасности или нет. Многие исправления ошибок классифицируются как связанные с безопасностью только спустя долгое время.

Когда о проблемах с безопасностью извещают сообщество ядра, они исправляют это как можно скорее (обычно примерно через неделю) и публично включают в дерево разработки и стабильные релизы. Грег объясняет: это делается для того, чтобы затрагиваемые стороны могли обновить свои системы, прежде чем обнаруживший проблему сообщит о ней.

Что такое CVE

CVE расшифровывается как Common Vulnerabilities and Exposures [Система идентификации уязвимостей]. Ее в 1999 г. воплотила в жизнь MITRE, некоммерческая организация, управляющая научно-исследовательскими центрами, которые спонсируются федеральным правительством США. Цель CVE — определять и классифицировать уязвимости в ПО или прошивках внутри базы данных,
предлагая компаниям улучшить их безопасность.

Иными словами, цель базы данных CVE — стандартизация способа определения каждой известной уязвимости или незащищенности. Каждая запись в базе данных CVE содержит стандартный идентификационный номер, индикатор статуса, краткое описание и ссылки на рекомендации и отчеты по уязвимости. База данных CVE
отображает только обнародованные уязвимости и незащищенности.

Организации, которые определяют и передают ID CVE для включения в первые публичные объявления о новых уязвимостях, известны как CVE Numbering Authorities или, для краткости, CNA. В более чем 60 компаний, назначенных как CNA, входят Canonical, Red Hat и Mozilla.

Жизненный цикл уязвимости

Проекты ПО обычно отслеживают список распространенных уязвимостей и системы идентификации уязвимостей (CVE) для определения и исправления уязвимостей в своих программах .

«Каждый рабочий день сотрудник службы безопасности Ubuntu сортирует вновь присвоенные CVE. Мы сканируем базу данных MITRE, рассылку oss-security, списки CVE, находящиеся в ведении других дистрибутивов — включая Debian и репозитории исходников для многих проектов с открытым кодом — для определения вновь присвоенных общедоступных CVE», говорит Эмили Рэтлифф [Emily Ratliff], глава отдела безопасности в Canonical. Служба безопасности проверяет каждую CVE, чтоб определить, затронут ли Ubuntu: «Каждая CVE проверяется в нашей базе данных CVE. Каждый рабочий день несколько членов службы безопасности Ubuntu проверяют нерешенные проблемы в базе данных и готовят обновления к выпуску».

CVE — это не обычные отправные точки для исправления проблем с безопасностью в Fedora. Джастин Форбс [Justin Forbes], один из кураторов ядра из Fedora, говорит, что на самом деле они даже не связаны друг с другом: «Многие CVE запрашиваются еще долго после того, как исправление попало в основную ветвь или даже в ядра многих дистрибутивов». Джастин говорит, что большинство проблем не являются огромными и сами по себе оказывают небольшое влияние, но «они тем не менее нуждаются в исправлении, поскольку можно выстроить эксплойты в цепь, чтобы добиться большего посредством множества небольших атак».

Залатайте их

По словам Джастина, потенциальная ошибка системы безопасности обычно обнаруживается во время анализа кода или тестирования случайным методом (для обеспечения качества): «Ошибка либо латается и затем кто-то запрашивает CVE, либо нашедший сообщает об ошибке (надеемся, правильным людям) и кто-нибудь составляет запрос CVE, а кто-то пишет заплатку-исправление». Джастин добавляет, что еще один распространенный случай — когда создано исправление ошибки и кто-то замечает, что ошибка на самом деле способна стать проблемой безопасности через эксплойт. Обсуждения исправления таких проблем происходят в сообществе, делится Джастин, как правило, через комбинацию списков рассылок людям из соответствующего вышележащего [upstream] ПО и тем, кто занимается безопасностью.

Помимо уязвимостей, возникающих при анализе кода, Джастин указывает на то, что ядро и дистрибутивы также должны справляться с проблемами, для которых какой-либо исследователь, возможно, написал экспериментальный код и показал, что их легко можно эксплуатировать или что они могут причинить серьезный вред из-за эксплойтов. Джастин добавляет, что такие проблемы часто переправляются в службы безопасности различных дистрибутивов или на внутренние списки адресов электронной почты, например, [email protected]

Эмили описывает процесс более подробно. Она говорит, что исследователи безопасности раскрывают информацию об уязвимостях Службе безопасности Ubuntu [Ubuntu Security Team] в частном порядке через зашифрованное по GPG электронное письмо. Когда уязвимости применяются к проектам с открытым кодом, сотрудник службы безопасности Ubuntu будет координировать работу с исследователем и вышележащими сообществами, чтобы сообщить об этой уязвимости разработчикам проекта.

«Для уязвимостей в проектах, созданных или поддерживаемых Canonical, служба безопасности Ubuntu зафиксирует ошибку в Launchpad и будет работать над устранением уязвимости с внутренними разработчиками», говорит она, добавляя, что «Canonical — это CNA (CVE Numbering Authority) для проектов, начатых разработчиками Canonical, так что в данном случае Canonical присвоит CVE уязвимости и уведомит MITRE о ее деталях».

Многие проблемы обсуждаются в частном порядке до предания их огласке. Эмили подчеркивает, что подробности этих проблем подвергаются эмбарго до достижения соглашения по поводу скоординированной даты релиза [Coordinated Release Date]. Существует масса способов собрать вместе представителей дистрибутивов и других затрагиваемых сторон для обсуждения этих частных вопросов. По словам Эмили, большие проекты имеют свои собственные списки служб безопасности, которые будут затронуты уязвимостями безопасности в проекте. «Один из таких списков — список рассылки [email protected], по обсуждениям вопросов безопасности в ядре Linux, — говорит она. — OpenWall обладает списком дистрибутивов (http://oss-security.openwall.org/wiki/mailing-lists/distros), которые часто используются для обсуждения вопросов, подвергнутых эмбарго, в самых разных пакетах с открытым кодом».

Джастин указывает, что когда проблема отправляется на адрес [email protected], происходит координация процесса разработки и тестирования исправления, прежде чем такая проблема будет обнародована: «Цель в том, чтобы выдать исправления пользователям либо до, либо сразу после раскрытия информации, чтобы ограничить воздействие на системы пользователи. И конечно, как у дистрибутива Linux, реальная цель в том, чтобы исправить вышележащее ПО».

Ремонт ядра

Как только уязвимость обнаруживается и о ней сообщается, исправление создается так же, как любое другое. Эмили говорит, что иногда сообщивший о проблеме включает заплатку или тестовый случай, воспроизводящий проблему. Кураторы могут принять заплатку или создать свое собственное исправление. Иногда, добавляет она, заплатки создают дистрибутивы — и вносят изменения в проекты вышележащего ПО.

Говоря с точки зрения ядра дистрибутива, Джастин говорит, что их целью является обеспечение максимально возможного уровня безопасности пользователей: «Поскольку Fedora продвигается так быстро, кончается тем, что мы закрываем многие CVE со словами „мы исправили это две недели назад с версией ядра x.y.z.“». Джастин связывает это с тем, что многие из этих проблем проходят через вышележащее ядро, прежде чем кто-либо запросит CVE или свяжет данную проблему с безопасностью.

«Для других проблем мы часто обнаруживаем, что заплатка болтается где-то поблизости, но ее просто не включили в вышележащий релиз», добавляет он. Эти заплатки затем извлекаются и высылаются пользователям в следующей сборке ядра. Джастин рассказывает, что проект Fedora выпускает обновления ядра почти каждую неделю. Более срочные проблемы решаются с помощью сборки, специально изготовляемой для их исправления. Однако он говорит, что множество CVE вряд ли являются угрозами и ближе к обычным ошибкам: «Проблемы типа „пользователь с физическим доступом к компьютеру может вызвать DoS“, „владелец экзотической аппаратуры может поломать систему“ и т. п. могут подождать до очередной плановой сборки».

Если заплатки для уязвимости не существует, говорит Джастин, проект обращается к разработчикам, которые поддерживают этот раздел кода, или пишется исправление и им отсылается. Он рассказывает, что Fedora весьма весом как «основной источник», и далее говорит, что «в идеале нам бы вообще не стоило заниматься исправлениями, потому что нам нужен только оригинал ядра, и вам не увидать заплаток безопасности в дереве Fedora, которые не были отправлены ядру. В случае с попавшими под эмбарго проблемами мы должны тестировать исправления внутренне, но они попадают в дерево Fedora на момент обнародования».

Маркус Мейсснер [Marcus Meissner], сотрудник команды безопасности openSUSE, кратко характеризует весь процесс целиком. «Что касается проблем, подпавших под эмбарго, большинство из них происходит через рассылки по координации дистрибутивов и дистрибутивов Linux, где обычно исправления публикуются в виде заголовков, и дата эмабрго согласовывается только при некоторых технических обсуждениях. От ряда проектов, таких как Xen, CURL и ряд других, мы также получаем отчеты об эмбарго непосредственно, обычно сопровождаемые заплатками».

Теневая зона

Возможно, самые распространенные уязвимости безопасности в последнее время — это CVE-2017-5754, CVE-2017-5753 и CVE-2017-5715, прозванные Meltdown и Spectre. По большинству оценок, эти проблемы влияют на все компьютеры, собранные в последнее десятилетие, независимо от их операционной системы. Три этих угрозы не одинаковы, но они эксплуатируют похожий механизм воздействия для получения доступа к привилегированным данным. Вкратце, уязвимости читают области памяти, которые должны быть защищены и резервированы для использования ядром. Они применяют архитектурную технологию, известную как «вдумчивое выполнение», которая была создана для улучшения производительности компьютера.

Как только уязвимости были обнаружены, все заинтересованные круги, включая производителей оборудования и операционных систем, в том числе нескольких дистрибутивов Linux, сошлись на том, что 9 января 2018 г. будет скоординированной датой релиза для обнародования уязвимости. В этот день они все должны были выпустить обновления релизов для решения проблем. Однако, в силу обстоятельств, проблемы стали известны публике раньше запланированной даты, 3 января 2018 г. В итоге для некоторых дистрибутивов заплатки не были доступны на момент обнародования уязвимостей.

Работа, связанная с уязвимостями, началась в ядре Linux в конце октября с набора заплат KAISER. Набор заплат KAISER разделяет таблицы страниц, которые в данный момент делятся между областями пользователя и ядра, на два набора таблиц — по одному для каждой стороны. Впоследствии эта работа была переименована как изоляция таблиц страниц ядра [kernel page-table isolation] или KPTI. Заплатки послужили фундаментальным изменением функции управления памятью ядра. Обычно подобное важное изменение активно обсуждается. Но поскольку это ускорилось через релизы ядра, многие заподозрили, что работа велась под эмбарго.

Через пару дней после раскрытия информации все исправления для Meltdown на оборудовании x86 были портированы обратно в самое последнее стабильное ядро v4.14, а также в деревья ядра v4.4 и v4.9 LTS. Линус Торвальдс выпустил первое новое ядро Linux 2018 г., v4.15, 28 января, после самого долгого цикла разработки нового ядра Linux за семь лет с девятью кандидатами на релиз.

Джастин упоминает, что разработчики Fedora понимали, что Meltdown является самым большим риском, поскольку его было очень просто задействовать: «Мы работали с заплатками KPTI без выходных, чтобы обеспечить готовность предложить исправления, как только информация будет раскрыта, и, я думаю, мы выпустили их через несколько часов после раскрытия информации». Далее он признает, что до сих пор ведется работа над другими архитектурами, но уверяет нас, что они исправляются так быстро, как только возможно, и менее уязвимы.

Практически та же история имела место в Canonical. В соответствии с постом в блоге, Canonical стало известно об уязвимостях под эмбарго в ноябре 2017 г., и их инженеры работали «все рождественские и новогодние праздники над тестированием и интеграцией невероятно сложного набора заплат в широкий набор ядер Ubuntu и архитектур CPU».

Из этих двух Spectre более хитрый, и, как Грег пишет в своем блоге, к нему разработчики ядра обратились в последнюю очередь: «Все мы работали над проблемой Meltdown, и у нас не было реальной информации о том, в чем, собственно, заключалась проблема Spectre и какие заплатки были выпущены, и были еще в худшей форме, чем обнародовалось». К проблеме Spectre обратились в ядре v4.15 через код Retpoline, изначально разработанный в Google.

Джастин соглашается, что, хотя Spectre намного труднее внедрить, всё же критически важно его исправить: «Мы следовали за ним [Spectre] вверх по коду, иногда производя по нескольку сборок в день, чтобы протестировать новые версии этих заплаток. Опять же, главным приоритетом была x86_64, потому что именно ею пользуются большинство пользователей». Лора Эбботт [Laura Abbott], еще один инженер безопасности ядра Fedora, добавляет, что поскольку Fedora так близок к исходному ядру, они смогли по большей части взять заплатки в предоставленном виде и просто применить их к ядру Fedora: «Дистрибутивы с более старыми ядрами должны были приложить намного больше усилий для обратного портирования в их ядра».

Линии коммуникации

Говоря об оповещениях, Маркус объясняет, что для более глубоких и дольше существующих технических проблем, как, например, Meltdown и Spectre, созданы специальные коммуникационные каналы/списки. Например, для Meltdown создали специальный внешний список рассылки, на который подписались заинтересованные разработчики ядра. Здесь они обсуждали интеграцию средств для предотвращения негативных последствий и проверенных обратных портов.

Было изрядное количество обсуждений того, как этот процесс работал (см. врезку внизу), и Ли-нус Торвальдс был весьма громогласен — как всегда — в своей критике Intel и их подхода ко всей этой ситуации. Джастин тоже недоволен: «На самом деле, во всем этом был некий бардак, и я надеюсь, что мы кое-чему научились и в следующий раз, если произойдет нечто похожее, лучше справимся с координированным раскрытием информации».

Хотя немедленная угроза была ликвидирована, Джастин считает, что уязвимости будут преследовать нас некоторое время. «Я полагаю, исходя из того, что природой данных проблем является архитектура, а не просто код, некоторое время это будет продолжаться».

«Заткните дыры по возможности быстрее, а потом оптимизируйте исправления — вот путь вперед», говорит Джастин, комментируя стратегию разработчиков ядра. Как только пыль поуляжется и все перестанут тыкать друг в друга пальцами, окажется, что опять всех спасло сообщество разработчиков с открытым кодом. Джастин идеально подводит итог: «Неважно, каким дистрибутивом вы пользуетесь, или какой продукт вы выпускаете: в конечном итоге пользователь должен быть защищен».

Понравилась статья? Поделиться с друзьями:
Добавить комментарий