Текущий 2018 год интересен тем, что чуть ли не каждый месяц появляется информация о новых аппаратных уязвимостях: Spectre и Meltdown.


Совсем недавно — пару недель назад! — были опубликованы громкие новости об уязвимостях Foreshadow и L1Terminal Fault, которые, как сообщается, могут обойти даже механизм SGX (Sofware Guard Extensions), ранее считавшийся практически невзламываемым.


Насколько опасны эти уязвимости? Можно ли от них защититься и если можно, то как? Обо всём этом мы поговорим ниже.


Краткая справка


Foreshadow, или L1TF — это целая группа уязвимостей, в которую входят:


  • CVE-2018-3615 — для обхода SGX;
  • CVE-2018-3620 — для атаки на ядро операционной системы, а также на режим SMM (System Management Mode);
  • CVE-2018-3646 — для атаки на виртуальные машины.

Авторы многих публикаций высказывают особую тревогу в связи с возможностью обхода защиты SGX: этого не умели Spectre и Metldown, и это делает беззащитными любые конфиденциальные данные. Чтобы понять, насколько эта тревога обоснована, разберём принципы работы механизма SGX.


Что такое SGX и как его можно обойти


Аббревиатура SGX означает Software Guard Extensions. Так называется набор инструкций процессоров Intel, используемых для выделения приватных областей кода и данных. В 2015 году один из создателей SGX Мэттью Хойкстра (Matthew Hoeskstra) опубликовал статью (см. также русский перевод), в которой выделил следующие цели создания этой технологии:


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

В процитированной статье маркетинга гораздо больше, чем технических подробностей. В ней рассказано в общих чертах о том, ЧТО позволяет делать технология SGX, но нет ни слова о том, КАК это делается. Об этом мы подробно расскажем ниже. В своём изложении мы будем в первую очередь опираться на подробную статью, опубликованную Международной организацией исследований в области криптологии (IACR, International Association for Cryptologic Research).


SGX создаёт в памяти защищённый регион — PRM (Processor Reserved Memory), который также называют анклавом. Процессор защищает анклав от любых попыток доступа, в том числе и со стороны ядра, гипервизора и SMM (System Management Mode), а также от попыток доступа со стороны периферийных устройств.


У PRM есть специальный кэш, так называемый EPC (Enclave Page Cache), который состоит из четырёхкилобайтных страниц, хранящих код анклава и данные. При вызове доверенной функции приложение «видит» только данные анклава; любой внешний доступ, в том числе и со стороны ОС, запрещён.


При любой попытке доступа к анклаву происходит процедура так называемой аттестации. Анклав запрашивает аппаратно подписанный отчёт, содержащий в том числе и сведения о его ценности. Этот отчёт отправляется на сервер аттестации. Анклаву высылается открытая часть ключа приложения; далее генерируется приватный ключ, зависящий от анклава и платформы. Ключ шифруется подписывающим ключом и сохраняется для дальнейшего использования.


Как отмечено в официальных публикациях Intel, SGX может защищать от разного рода атак на данные и код: как со стороны системного и пользовательского ПО, так и со стороны загрузчика. А вот от так называемых side-channel-атак SGX защитить не может. Обойти SGX не могут и пресловутые Spectre и Meltdown.


Однако в последнее время появились атаки (собственно, ещё до Foreshadow — см., например, здесь), которые позволяют обходить защиту SGX. Причём Foreshadow — это всего лишь самая громкая и нашумевшая из них.


В документации к SGX отмечено, что «из анклавов невозможно читать и в них невозможно ничего записывать вне зависимости от наличия привилегий любого уровня». Однако на самом деле всё обстоит далеко не так.


Ещё весной этого года появилась информация об атаке под названием SGX Spectre, с помощью которой можно извлекать данные из анклавов. Как показали исследователи из университета штата Огайо (см., например, здесь), это возможно благодаря «дырам» в SDK, с помощью которых разработчики могут интегрировать поддержку SGX в свои приложения. В числе затронутых SDK оказались Intel SGX SDK, Rust-SGX и Graphene-SGX. С детальным разбором этой атаки можно ознакомиться в этой статье; на Youtube также было опубликовано видео с наглядной демонстрацией примера.



Видео, конечно, неубедительное: сам факт проникновения в анклав не означает, что важные данные могут быть украдены. Тем не менее, нужно констатировать: целостность и конфиденциальность механизма SGX нарушены.


Foreshadow нарушает изоляцию, используя так называемую атаку по стороннему каналу (side-channel attack).


Как и в пресловутых Spectre и Meltdown, уязвимость использует механизм спекулятивного исполнения команд. В её основе лежит следующий момент: при доступе к памяти по виртуальному адресу, приводящему к исключению (terminal page fault) из-за отсутствия флага Present в таблице PTE (Page Table Entries), процессоры Intel спекулятивно рассчитывают физический адрес и загружают данные, если они имеются в L1-кэше. Спекулятивные расчёты осуществляются до проверки наличия данных в физической памяти и до проверки доступности этих данных для чтения. Если флага Present в PTE нет, то операция отбрасывается; но данные при этом «оседают» в кэше и могут быть из него извлечены. Данные могут быть извлечены абсолютно по любому физическому адресу; это открывает обширные возможности для злоумышленников и позволяет, например, извлечь данные на хосте из гостевой машины. Видео с демонстрациями уже появились:



Впрочем, видео выглядит, прямо скажем, не очень убедительно и напоминает многочисленные демонстрации работы уязвимостей Spectre и Meltdown, что гуляли по Интернету в начале этого года: вроде бы и удалось преодолеть защиту — но что дальше? Конечно, обход SGX — прецедент явно не очень хороший


Чего бояться?


В отличие от нашумевших Spectre и Meltdown, Foreshadow угрожает только процессорам Intel. В описаниях отмечается, что с помощью этой атаки можно извлечь из анклава не просто конфиденциальные данные, но и приватный ключ аттестации, что подрывает доверие ко всей SGX-экосистеме.


Различные вариации Foreshadow угрожают так называемому System Management Mode (SMM), ядру операционной системы гипервизоров. Некоторые эксперты отмечают, что с помощью Foreshadow можно воровать данные из виртуальных машин в стороннем облаке. Есть публикации, где отмечается, что новая атака даже позволяет обойти патчи, вычисленные ранее для защиты от атак Spectre и Meltdown.


Однако — как и в случае со Spectre и Meltdown — ко всем громким заявлениям следует относиться крайне осторожно. Ни одного случая кражи значимых и конфиденциальных данных с помощью нашумевших атак пока что зафиксировано не было. Опубликованные прототипы эксплойтов (как и предупреждают сами их авторы) представляют собой не более чем экспериментальные образцы, оторванные от реальной практики, и будут работать далеко не всегда и не у всех, особенно если речь идёт о виртуальных машинах. Поэтому паниковать пока что рано: чтобы не просто проникнуть в пределы анклава, а извлечь из него действительно важную информацию, нужно очень и очень постараться.


На текущий момент действительно серьёзных атак зафиксировано не было.


Патчи и производительность


Тема патчей, защищающих от аппаратных уязвимостей (а если не защищающих, то нивелирующих их последствия), тоже очень актуальна. Вспомним недавнюю историю со Spectre и Meltdown: многие меры были приняты в пожарном порядке, что привело к не самым лучшим последствиям: внезапные перезагрузки системы, резкое падение производительности и т.п. Компании Microsoft пришлось даже выпустить обновления, отключающие патчи Intel. За первые три месяца текущего года только против Intel было подано 32 судебных иска.


На публикацию информации об уязвимости Foreshadow крупные компании отреагировали оперативно: с соответствующими заявлениями выступили Intel, Red Hat, SUSE, VMware, Oracle. Не менее оперативно были выпущены обновления для продукции Cisco и для ядра Linux.


Не обошлось и без казусов: компания Intel быстро выпустила обновления микрокода, но при этом без странных казусов: неожиданно был провозглашен запрет на публикацию результатов тестирования производительности до и после обновления (потом, правда, запрет был отменён). Что это было — сказать сложно. А тема влияния патчей на производительность несомненно заслуживает отдельного исследования и отдельной статьи. И не исключено, что такую статью мы в ближайшем будущем опубликуем.


Заключение


В этой статье мы привели краткий обзор уязвимостей класса Foreshadow. Естественно, в рамках одной статьи рассказать обо всех аспектах уязвимостей группы Foreshadow невозможно. Поэтому приводим подборку полезных ссылок для желающих узнать больше:



Если у вас есть опыт работы по анализу аппаратных уязвимостей и их последствий — добро пожаловать в комментарии.

Комментарии (3)


  1. igrblkv
    03.09.2018 16:57

    Кроилово ведет к попадалову.
    Думаю, это только начало и дальше спекулятивное выполнение кода себя ещё не раз проявит…


  1. Wolf4D
    04.09.2018 08:32
    +2

    Интересно, много приложений, где реально на практике используется SGX? Все эти вещи выглядят интересно, но поддержка только одним из производителей процессоров… да и если данные так дико важно защитить именно от кражи злоумышленником, имеющим частичный доступ, можно подумать уже и о выполнении части кода на внешних аппаратных средствах — недавно вроде была статья на Хабре про токен, внутри которого крутится часть функционала программы.


    1. force
      04.09.2018 18:46

      Как я понимаю, тут проблема больше актуальна для виртуалок в облаках. Т.е. нам дают инструмент вида: «несмотря на то, что виртуалка в облаке, и вы её не контролируете, её данные могут быть защищены от всех с помощью данной технологии». И тут находят дыру такого вида, что соседняя с вами виртуалка, грязными способами может узнать эти ваши данные, которые никто не должен видеть (ну, или владелец хост-машины). Что бьёт как раз по облачным провайдерам.

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