Вредоносный код в овечьей шкуре. Как работает атака на анклав SGX

За годы хаотичной эволюции набор команд ассемблера x86-64 стал порождать самые причудливые сочетания. Сегодня мы рассмотрим творческий подход к использованию TSX-инструкций изнутри анклавов — защищенных участков памяти. Результатом будет рабочий эксплоит, который позволит выполнять любой код с привилегиями хост-приложения.

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

Итак, что нам недоступно в анклаве? Мы не можем делать системные вызовы. Мы не можем выполнять операции ввода-вывода. Мы не знаем базового адреса сегмента кода хост-приложения. Мы не можем переходить к коду хост-приложения при помощи jmp и call. Мы не имеем представления о структуре адресного пространства, которой руководствуется хост-приложение (например, какие именно страницы промаппены или что за данные размещены на этих страницах). Мы даже не можем попросить операционную систему промаппить нам кусок памяти хост-приложения (например, через proc/pid/maps).

Наивные попытки прочитать вслепую произвольную область памяти хост-приложения рано или поздно приведут к принудительному завершению анклавной программы (и скорее рано, чем поздно). Так происходит всякий раз, когда запрашиваемая анклавом область виртуального адресного пространства оказывается недоступной хост-приложению. О возможности записать «что-то свое» даже заикаться смешно.

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

Поэтому случись так, что вредоносному анклаву удастся делать произвольные системные вызовы от имени хост-приложения, выполнять произвольный код, сканировать память и находить в ней пригодные для злоупотребления ROP-цепочки, — и он сможет захватить полный контроль над хост-приложением в стелс-режиме. Он будет способен не только красть и шифровать пользовательские файлы, но и действовать от его имени. Например, отправлять фишинговые письма или проводить DoS-атаки. При этом даже самые современные защитные механизмы, такие как стековые канарейки и санитарная обработка адресов, окажутся бессильными.

В статье я покажу несколько приемов, при помощи которых злодеи преодолевают перечисленные ограничения и используют SGX в своих корыстных интересах при проведении ROP-атак. Делается это либо для выполнения произвольного кода, замаскированного под процесс хост-приложения (аналогично process hollowing, который часто используется малварью), либо для маскировки уже готовой малвари — чтобы избавиться от преследований со стороны антивирусов и других защитных механизмов.

Источник: xakep.ru