Содержание статьи
Итак, что нам недоступно в анклаве? Мы не можем делать системные вызовы. Мы не можем выполнять операции ввода-вывода. Мы не знаем базового адреса сегмента кода хост-приложения. Мы не можем переходить к коду хост-приложения при помощи jmp и call. Мы не имеем представления о структуре адресного пространства, которой руководствуется хост-приложение (например, какие именно страницы промаппены или что за данные размещены на этих страницах). Мы даже не можем попросить операционную систему промаппить нам кусок памяти хост-приложения (например, через proc/pid/maps).
INFO
Логичней всего думать о технологии SGX (Software Guard Extensions) и анклавах как о «песочнице наоборот». В sandbox-приложениях, как правило, запускается потенциально опасный код, который требуется изолировать от операционной системы и сторонних программ. Анклав же, напротив, исходит из того, что окружение уже может быть скомпрометировано злоумышленниками, и поэтому предотвращает любой несанкционированный доступ извне. Подробности ты найдешь на сайте Intel.
Наивные попытки прочитать вслепую произвольную область памяти хост-приложения рано или поздно приведут к принудительному завершению анклавной программы (и скорее рано, чем поздно). Так происходит всякий раз, когда запрашиваемая анклавом область виртуального адресного пространства оказывается недоступной хост-приложению. О возможности записать «что-то свое» даже заикаться смешно.
Поэтому принято считать, что анклав способен лишь обслуживать хост-приложение и что анклав не может проявлять собственную инициативу, в том числе злонамеренную. А значит, для создателей вирусов практической ценности он не представляет. Это поспешное предположение стало одной из причин того, почему защита анклава несимметрична: код хост-приложения не может получать доступ к его памяти, тогда как анклавный код может читать и писать по любому адресу памяти хост-приложения.
Поэтому случись так, что вредоносному анклаву удастся делать произвольные системные вызовы от имени хост-приложения, выполнять произвольный код, сканировать память и находить в ней пригодные для злоупотребления ROP-цепочки, — и он сможет захватить полный контроль над хост-приложением в стелс-режиме. Он будет способен не только красть и шифровать пользовательские файлы, но и действовать от его имени. Например, отправлять фишинговые письма или проводить DoS-атаки. При этом даже самые современные защитные механизмы, такие как стековые канарейки и санитарная обработка адресов, окажутся бессильными.
В статье я покажу несколько приемов, при помощи которых злодеи преодолевают перечисленные ограничения и используют SGX в своих корыстных интересах при проведении ROP-атак. Делается это либо для выполнения произвольного кода, замаскированного под процесс хост-приложения (аналогично process hollowing, который часто используется малварью), либо для маскировки уже готовой малвари — чтобы избавиться от преследований со стороны антивирусов и других защитных механизмов.
WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
