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

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:31, 18 декабря 2015.
Кража веб-страниц, запускаемых в браузере пользователя, с использованием уязвимостей графического процессора


Stealing Webpages Rendered on Your Browser by Exploiting GPU Vulnerabilities.png
Авторы Sangho Lee[@: 1]
Youngsok Kim[@: 2]
Jangwoo Kim[@: 3] and
Jong Kim[@: 4]
Опубликован 2014 г.
Сайт Технический комитет по безопасности и приватности компьютерного сообщества Института Инженеров Электротехники и Электроники (IEEE)
Перевели Yulia Gavrilova
Ekaterina Evtuhova
Год перевода 2015 г.
Скачать оригинал


Графические процессоры (GPU) являются важными компонентами современных вычислительных устройств для не только рендеринга графики, но и для эффективных параллельных вычислений. Тем не менее, их проблемы безопасности игнорируются, несмотря на их важность и актуальность. В этой статье мы сначала выполним углубленный анализ безопасности на графических процессорах для обнаружения уязвимостей безопасности. Заметим, что современные, широко используемые графические процессоры, как NVIDIA и AMD, не инициализируют вновь выделенные страницы памяти GPU, которые могут содержать конфиденциальные данные пользователя. Используя такие уязвимости, мы предлагаем методы атаки для выявления данных программы атакуемого, хранящихся в памяти GPU, как во время исполнения программы , так и сразу после ее окончания. Мы также покажем высокую применимость предложенных атак с применением их в браузерах Chromium и Firefox, которые используют графические процессоры для ускорения рендеринга веб-страницы. Мы обнаружили, что оба браузера оставляют изображенные текстуры веб-страницы в памяти GPU, так что мы можем заключить, какие веб-страниц посетил пользователь, пострадавший от анализа оставшихся текстуры. Точность нашей передовой атаки заключается в использовании и соответствия последовательности пикселей, и соответствия RGB гистограммы до 95,4%.

Содержание

Введение

Рисунок 1. Логотип Google и частичный дамп памяти текстуры веб-страницы Google, извлеченный из веб-браузера Chromium с NVIDIA GPU

Графические процессоры являются важными и мощными компонентами современных вычислительных устройств. Личные вычислительные устройства, в том числе настольные компьютеры, ноутбуки и смартфоны используют графические процессоры для поддержки различных графических приложений, например, графического пользовательского интерфейса (GUI), мультимедийных плееров и компьютерных игр. Крупномасштабные вычислительные устройства, в том числе рабочие станции, сервера и кластеры также используют графические процессоры для энергоэффективных, массивных параллельных вычислений. Графические процессоры используют большое количество процессорных ядер и большое количество независимой памяти для эффективной обработки графических операций и расчетных нагрузок. Например, NVIDIA Kepler GPU может иметь до 2880 ядер и 6 ГБ памяти, а его производительность операций с числами с плавающей запятой работы в девять раз выше, чем у последних процессоров.

Программисты могут использовать два типа интерфейсов прикладного программирования (API) для доступа к графическим процессорам: графические интерфейсы (например, DirectX и OpenGL) и вычислительные API, (например, CUDA и OpenCL). Во-первых, графические интерфейсы обеспечивают функции для графических операций, таких как проекции, штриховки и наложения текстур. Во-вторых, вычислительные интерфейсы обеспечивают функции для неграфических приложений, таких как финансовые или медицинские, анализ погодных данных, оптимизации запросов к базе данных, маршрутизации пакетов, системы обнаружения вторжений, и криптографические системы.

Наиболее существенные различия между графическими и вычислительными интерфейсами – в разделении и управлении памятью. Во-первых, вычислительные интерфейсы позволяют разным пользователям разделять между собой один и тот же GPU, в то время как графические интерфейсы поддерживают работу только одного пользователя. Число пользователей, которые могут совместно использовать один GPU с помощью вычислительных API, в режиме разделения времени формируется как (1) вычислительные интерфейсы, не требующие никаких специализированных экранов и (2) текущие графические процессы, поддерживающие только последовательное выполнение различных GPU процессов. Хотя некоторые методы (например, VirtualGL) позволяют удаленным пользователям использовать один и тот же GPU при использовании графических API, они предупреждают пользователей о возможных проблемах в безопасности (например, логгирование нажатия клавиш и чтение изображения обратно через X-сервер).

Во-вторых, в то время как драйверы GPU управляют GPU память с графическими API, программисты могут вручную управлять GPU памятью с вычислительными API, включая выделение памяти, передачу данных CPU-GPU и перевыделения. Графические процессоры имеют несколько типов памяти (например, глобальную, локальную и защищенную память), и программисты могут контролировать их с помощью вычислительных API, за исключением графически связанной памяти (например, фрейм-буфер и Z-буфер). Напротив, графические API не обеспечивают никаких функций управления такой памятью, обеспечивая при этом набор оптимизированных функций для выполнения графических операций, эффективно использующих память.

К сожалению, совместное использование и высокая управляемость памяти вычислительных интерфейсов может потребовать серьезных угроз безопасности, поскольку графические процессоры не инициализируют вновь выделенные буферы памяти. Несмотря на многочисленные исследования, рассматривающие такую проблему неинициализированной памяти в операционных системах, ни одно исследование не имеет дело с проблемой неинициализированной памяти графических процессоров. Если подобные угрозы безопасности существуют с вычислительными API, то такие угрозы имеют гораздо больший эффект, так как несколько пользователей разделяют же GPU.

В этой статье мы сначала выполним углубленный анализ безопасности на графических процессорах в отношении их архитектуры и вычислительных API, чтобы выявить любые потенциальные угрозы безопасности. Мы определили, что вычислительные интерфейсы имеют серьезную проблему неинициализированной памяти, потому что они (1) не очищают вновь выделенные страницы памяти, (2) имеют типы памяти, которые программисты не могут удалить, и (3) имеют встроенную память без механизма безопасности.

Во-вторых, мы разработаем эффективные атаки безопасности на графических процессорах, применимые к наиболее широко использующимся графическим процессорам - NVIDIA и AMD, используя выявленные угрозы безопасности. Наши атаки могут раскрыть конфиденциальные данные, хранящиеся в памяти GPU программы жертвы как во время исполнения программы, так и сразу после ее окончания.

В-третьих, мы демонстрируем высокую применимость наших атак через выведение истории просмов историю двух наиболее широко используемых веб-браузеров, Chromium и Firefox. Оба браузеры поддерживают GPU-ускорение рендеринга веб-страниц, которые загружают текстуры веб-страниц в память графического процессора, чтобы увеличить скорость рендеринга. Наши атаки могут извлечь перестроенные текстуры веб-страниц обоих браузеров через графические процессоры NVIDIA и AMD.

Наконец, мы предлагаем передовые логические атаки, которые могут правильно вывести оригинальную веб-страницу из перестроенное текстуры веб-страницы с точностью до 95,4%. Предлагаемые результаты логических атаки сравнивают текстуры либо с известными текстурами, либо снимками известных веб-страницы, чтобы определить первоначальную страницу, используя три метода сопоставления: (1) совпадающие последовательности пикселей, (2) совпадающие гистограммы RGB, и (3) комбинированное совпадение.

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

  • Новизна и критичность цели атаки. Наша работа расширяет сферу исследований безопасности на цели новых атак, на GPU. Несмотря на свою популярность и значение, до этой работы не было углубленного изучения их проблем безопасности.
  • Полное углубленное исследование. Мы представляем полный детальный анализ безопасности на графических процессорах, касающийся не только их архитектуры, но и их вычислительных интерфейсов. Мы определяем, что все виды GPU памяти, доступной для вычислительных интерфейсов, имеют проблемы безопасности.
  • Сильные и широко применимые атаки. Мы демонстрируем наши атаки, используя самые широко используемые графические процессоры и GPU-приложения: графические процессоры NVIDIA и AMD, и веб-браузеры Chromium и Firefox. Тем более, наши атаки выводят историю просмотров с точностью до 95,4%.

Остальная часть этой статьи организована следующим образом. В разделе II мы даем углубленный анализ безопасности на графических процессорах и мотивируем нашу работу. В разделе III мы объясняем модель угроз. В разделе IV мы объясняем наши атаки, раскрывая конфиденциальные данные, оставшиеся в памяти GPU. В разделе V мы предлагаем наши логические атаки, которые идентифицируют историю просмотра веб-браузеров, использующих GPU. В разделе VI мы обсудим возможные контрмеры против предложенных атак. В разделе VII подводятся итоги данной соответствующей работы. Наконец, мы приходим к выводу в разделе VIII.

Предпосылки и проблемы безопасности

В этом разделе мы сначала дадим краткий обзор графических процессоров с точки зрения их архитектур и моделей программирования. Затем, мы мотивируем нашу работу, представив неизбежные проблемы безопасности, исходящие от природы GPU. Мы используем терминологию OpenCL на протяжении всей статьи.

Архитектура GPU

Графический процессор состоит из (1) вычислительного устройства для выполнения инструкции и (2) памяти вычислительного устройства для хранения данных. На рисунке 2 показана структурная схема типичной OpenCL-совместимой архитектуры GPU. Вычислительное устройство состоит из нескольких вычислительных блоков (ВБ) и глобальной / постоянной памяти кэша, разделяемой всеми ВБ. Каждый ВБ состоит из элементов обработки (ЭО), также известный как ядра GPU, и локальной памяти вычислительного блока, разделяемой элементами обработки. Каждый ЭО также имеет свою собственную внутреннюю память.

Рисунок 2. Высокоуровневая архитектура GPU с поддержкой OpenCL.

Устройство хранения данных состоит из двух типов памяти: глобальной памяти и постоянной памяти. Глобальный память чтения-записи предназначена для хранения результатов вычислений GPU. Постоянной памяти может быть использована только для чтения и предназначена для хранения кода, исполняемого вычислительным устройством, и данных с доступом «только для чтения».

Модель вычислений на GPU

В типичной вычислительной модели GPU, графические процессоры запускают определенные программистами контексты GPU, похожие на CPU. Программисты строят контекст GPU с помощью написания ядра, управления памятью и очередей команд, используя вычислительные API. Ядрами являются функции, написанные для запуска на GPU. Управление памятью включает в себя распределение памятью GPU, передачу данных между памятью GPU и CPU. Очереди команд хранят команды, которые будут выполнены на GPU. Типичное исполнение контекста GPU выглядит следующим образом: программист ставит в очередь на выполнение (1) команды распределения памяти GPU, (2) команды передачи данных от CPU к GPU, (3) выполнение команд ядра, (4) команды передачи данных от GPU к CPU, и (5) освобождение памяти команд GPU в очереди команд. Когда программист помещает в очередь команду выполнения ядра, драйвер GPU передает указатели на выделенную память GPU через аргументы функций ядра. Графические процессоры выполняют все команды из очереди команд по принципу «first-in first-out»(FIFO).

OpenGL и текстуры

Проведем краткий обзор OpenGL, популярного графического интерфейса, широко поддерживаемого различными операционными системами, такими как Windows, Linux, Android, и iOS. Среди всех его функций, основной обзор будет посвящен текстурным функциям, так как текстуры хранят информацию о конфиденциальных данных изображений жертв.

Наложение текстур - это метод, позволяющий сделать объекты более реалистичными путем сопоставления изображений или цвета 2D / 3D-объектов. OpenGL предоставляет набор функций для наложения текстур, такие как glGenTextures() для генерации объекта текстуры, glBindTexture() для загрузки объекта текстуры, и glTexImage2D() для определения массива изображений объекта текстуры. Программист может либо загрузить файл изображения, либо сгенерировать какие-то данные изображения для glTexImage2D(). После того, как объект текстуры загружен в память GPU, программист может вызвать функцию glTexCoord(), чтобы координировать объект текстуры во время рисования объектов.

Текстуры находятся в глобальной памяти, и программист может удалить неиспользуемые текстуры с помощью функции glDeleteTextures(), чтобы увеличить объем доступной памяти. Эта функция, однако, не инициализирует соответствующие блоки памяти. Соответственно, злоумышленник может читать неинициализированные текстуры, которые остаются в глобальной памяти после вызова glDeleteTextures()

Вопросы безопасности

Приведем теперь три основные проблемы безопасности, основываясь нашем анализе архитектуры GPU и API.

  1. Отсутствие инициализации страничной памяти после нового распределения: определим основную проблему безопасности памяти GPU - графические процессоры не инициализируют содержимое вновь выделенных страниц памяти, которые, возможно, содержат конфиденциальные данные. Новый владелец может получить доступ к оставшимся в страничной памяти конфиденциальным данным, если предыдущий владелец не очистил их. Современные операционные системы страдают от подобных проблем, но они решают проблему, заполняя новые страницы памяти нулями, прежде чем предоставить их в распоряжение пространству пользователя. Тем не менее, графические процессоры не обеспечивают таких контрмер. Таким образом, отсутствие инициализации страничной памяти после нового распределения - одна из первых проблем безопасности GPU.
  1. Неочищенная память: часть памяти GPU не очищается ни пользователем, ни GPU. Как говорилось ранее, графические процессоры имеют несколько типов памяти. В то время как программисты могут очистить содержимое большинства типов памяти, GPU не позволяют программистам очистить содержимое нескольких видов памяти, содержащей конфиденциальные данные (например, постоянные данные, коды ядра и аргументы, передаваемые по значению). Кроме того, GPU не удаляют автоматически такой контент, даже если он больше не нужен. Таким образом, защита конфиденциальных данных, хранящихся в неочищенной памяти, становится второй из основных проблем безопасности GPU
  1. Память, управляемая программистом: потоки, запущенные на вычислительном блоке одного ядра , могут получить доступ к содержимому других ядер, хранящемуся в локальной и защищенной памяти ВБ. Модель вычисления на GPU позволяет программистам управлять вручную локальной и защищенной памятью для улучшения производительности. Для обеспечения безопасности, графические процессоры должны запрещать доступ потокам ядра к содержимому, хранящемуся в локальной и защищенной памяти, относящейся к потокам других ядер. Но нынешние GPU не предоставляют механизма изоляции для локальной и защищенной памяти. Приложения с GPU-ускорением используют локальную и защищенную память для хранения конфиденциальных данных (например, секретных ключей), и отсутствие такого механизма становится третьим основным вопросом безопасности графических процессоров.

Система и модели атак

Здесь предполагается система, которая оснащена GPU для графических операций и расчетов. Она является многопользовательской системой, так что несколько пользователей могут совместно использовать GPU. Жертвой является обычный пользователь системы, который часто использует программы, задействующие GPU, такие как ПО для 3D-рендеринга, веб-браузеры, и инструментов для анализа данных. Пострадавший открывает окна локально, используя графические API. Злоумышленник – это еще один обычный пользователь системы , который не может атаковать жертву на уровне операционной системы из-за недостатка привилегии. Злоумышленник, однако, может свободно получить доступ к GPU с помощью вычислительных API, так как любой пользователь системы может использовать этот интерфейс. Следовательно, злоумышленник использует GPU, чтобы раскрыть конфиденциальные данные жертвы, возможно оставшиеся в памяти GPU.

Кроме того, считаем, что удаленная система GPU использует VirtualGL, который в основном такой же, как и в основной системы. Здесь, потерпевший имеет права использовать VirtualGL, чтобы удаленно использовать графические интерфейсы, в то время как злоумышленник не имеет прав на использование VirtualGL. Таким образом, злоумышленник также должен использовать GPU для атаки на данные жертвы, хранящиеся в памяти GPU. Так как методы атаки в обеих системах одинаковы, мы не будем разграничивать их.

Взлом памяти графического процессора

В этом разделе будет объяснено, как предложенные атаки раскрывают конфиденциальные данные в памяти GPU, используя проблему неинициализированной памяти. Мы предлагаем два типа атак для кражи конфиденциальных данных программы жертвы - сразу после ее завершения и во время ее исполнения. Дополнительно обсудим реальные нападения на программы, использующие GPU.

Обычная атака

Рисунок 3. Обзор предлагаемых атак.

Мы определили, что современные GPU имеют проблемы с неинициализированной памятью, выполнив базовую атаку, которая пытается прочитать всю глобальную память после того, как исполнение контекста GPU жертвы завершается. Во-первых, мы выполняем простую программу жертвы, которая заполняет 1 ГБ значением 0x11111111 в 3 Гб глобальной памяти графического процессора NVIDIA GeForce GTX 780. Сразу после завершения программы жертвы, выполняем простую программу атаки, которая считывает всю глобальную память. Когда не существует активной программы на GPU, то дамп памяти, считываемый программой атаки содержит не данные жертвы, но фиктивные данные. Мы ожидаем, что драйвер GPU переводит графический процессор в режиме сна для экономии энергии, так что данные, записанные в глобальную память, исчезают. В отличие от этого, когда есть по крайней мере одна активная программа на GPU (например, Gnome), дамп памяти содержит не только данные в 1 ГБ, записанные программы жертвы, а также другие важные данные, такие как код ядра. Незатертые данные остаются в памяти GPU, так как драйвер GPU не удаляет их автоматически чтобы избежать возможного снижения производительности. Мы провели подобную атаку на локальной и защищенной памяти и обнаружили, что графические процессоры также не очищают ее автоматически. Соответственно, можно сделать вывод, что нынешние GPU игнорируют проблему неинициализированной памяти.

Обзор современных атак

Проведем атаки, чтобы получить данные, хранящиеся в глобальной, локальной и защищенной памяти GPU. Рассмотрим два типа атаки: конец выполнения контекста GPU и конец выполнения функций ядра GPU. На рисунке 3 представлен обзор предлагаемых атак. Нормальный поток исполнения на GPU создает контекст GPU (К), выделяет память для GPU(П), копирует данные из процессора в GPU (CC), выполняет функции ядра(AM), копирует резервные данные из CPU в GPU (DH), освобождает память GPU (FM), и очищает контекст (DC) (3а). В случае графических приложений, копирование результатов в буфер кадра заменяет DH. Когда жертва выполняет эту последовательность, атаки в конце выполнения контекста(EOC) и атаки в конце выполнения функций ядра (ЕОК) происходят в разные моменты времени. Атаки EoC читают всю память GPU сразу после того, как жертва освобождает свою память (рис 3b). Атака ЕОК крадет локальную и защищенную память ядра жертвы сразу после прекращения выполнения функций ядра жертвы (3С). Далее главным образом рассмотрим предлагаемые атаки с использованием графических процессоров NVIDIA, и обсудим различия между процессорами NVIDIA и AMD в плане осуществления предлагаемых атак.

Атака в конце выполнения контекста (EOC)

  1. Описание атаки: Атака EoC стремится получить данные, оставшиеся после завершения контекста GPU программы жертвы. Программа GPU может либо явно уничтожить этот контекст с помощью вызова функций API (например, clReleaseContext() и cudaDeviceReset()) или косвенно очистить контекст GPU по его окончании. Основная цель этой атаки - результаты вычислений ядра, такие как расшифровка текста и отображенные изображений. Если программа жертвы не очищает глобальную память, прежде чем завершить контекст GPU, злоумышленник может легко получить результаты вычислений с помощью этой атаки. Кроме того, мы видим, что уничтожение контекста также очищает другие важные данные, такие как код ядра, постоянные данные. Настоящие GPU не предоставляют методов удаления таких данных.
  1. Процедура атаки: Алгоритм 1 демонстрирует пример атаки EOC. Графические процессоры NVIDIA обеспечивают функции для измерения имеющегося и общего размера памяти графических процессоров, такие как cudaMemGetInfo().

__________________________________________________________

Algorithm 1 End-of-Context Attack
__________________________________________________________
Input: own ← the size of memory occupied by attacker
 1: context ← createGPUContext()
 2: total ← getT otalMemoryInfo()
 3: available ← getAvailableMemoryInfo()
 4: while available + own = total do // no victim exists
 5: sleep()
 6: available ← getAvailableMemoryInfo()
 7: end while
 8: available ← getAvailableMemoryInfo()
 9: while available + own ≠ total do // victim works
 10: sleep()
 11: available ← getAvailableMemoryInfo()
 12: end while
 13: alloc ← allocateMemory(total − own) // victim exits
 14: memoryCopyDeviceToHost(alloc)
__________________________________________________________
Постоянно отслеживая изменения в имеющемся размере памяти, используя такие функции, злоумышленник может различить , завершила ли программа жертвы контекст GPU.
Рисунок 4. Изменение размера доступной глобальной памяти согласно активности программы жертвы. Общий размер памяти 2687 MB (NVIDIA Tesla C2050 GPU).
Рисунок 4 показывает изменения в имеющемся размере памяти в соответствии с деятельностью потерпевшего. Злоумышленник может узнать, когда жертва начинает использовать графический процессор, выделяет и освобождает глобальную память и выходит из GPU путем использования истории использования памяти. Если жертва больше не использует графический процессор, злоумышленник пытается прочитать всю глобальную память GPU.
  1. Снижение анализа памяти: Мы предлагаем технику для уменьшения анализа места в памяти, потому что (1) обычные программы жертв используют только небольшую часть глобальной памяти и (2) изучение нескольких гигабайт памяти глобальной требует лишних усилий. Наша методика заключается в заполнении глобальной памяти достаточно длинными двоичными последовательностями, прежде чем жертва начинает свою работу, и игнорировании при анализе этих последовательностей. Модифицируем программу атаки для заполнения глобальной памяти графического предопределенным 1024-битным целым числом, прежде чем программа жертвы будет запущена. При анализе дампа памяти, мы игнорируем это число. Вероятность того, что программа жертвы содержит предопределенное число, является незначительной. Эта техника проверена с простыми программами жертва, использующих 64, 128, 256, 512, и 1024 Мб глобальной памяти. В среднем, размер анализа памяти только на 1,3 МБ больше, чем выделяемая память для хранения кодов ядра и постоянных данных.
  1. Система с несколькими пользователями: Атака EoC в алгоритме 1 не работает, когда несколько жертв последовательно используют GPU. Чтобы решить эту проблему, мы поменяем атаку, чтобы иметь возможность работать с многочисленными жертвами (алгоритм 2).

___________________________________________________________

Algorithm 2 End-of-Context Attack on Multiple Victims
___________________________________________________________
Input: own ← the size of memory occupied by attacker
 1: context ← createGPUContext()
 2: total ← getT otalMemoryInfo()
 3: available ← getAvailableMemoryInfo()
 4: while available + own = total do // no victim exists
 5: sleep()
 6: available ← getAvailableMemoryInfo()
 7: end while
 8: available ← getAvailableMemoryInfo()
 9: while available + own ≠ total do // victims work
 10: sleep()
 11: avail new ← getAvailableMemoryInfo()
 12: if avail new > available then // victims deallocate
 memory
 13: alloc ← allocateMemory(avail new)
 14: if kernelDetectInstruction(alloc) = true then
 15: memoryCopyDeviceToHost(alloc) // only
 copy memory with code
 16: end if
 17: fillMemory(alloc)
 18: deallocateMemory(alloc)
 19: end if
 20: available ← getAvailableMemoryInfo()
 21: end while
 22: alloc ← allocateMemory(total − own) // victims exit
 23: memoryCopyDeviceToHost(alloc)
___________________________________________________________

Всякий раз, когда размер доступной памяти GPU увеличивается, этот алгоритм пытается выделить всю доступную память для получения недавно освобожденной памяти. Тем не менее, хранение всей доступной памяти требует много места для хранения и больших накладных расходов при передаче. Алгоритм позволяет избежать затрат на запуск функций ядра для проверки освобождения памяти из-за удаления контекста GPU. Это можно осуществлять путем проверки на содержание в перераспределенной памяти инструкции (например, 0x85800000001c3c02 - инструкция NOP из NVIDIA Kepler GPU). Наконец, алгоритм копирует память, содержащую инструкции и заполняет память фиктивными значениями прежде чем использовать ее, чтобы избежать избыточных обнаружений той же инструкции.

Атака в конце выполнения функций ядра GPU

  1. Описание атаки: Атака ЕОК стремится получить промежуточные данные, генерируемые при выполнении программы жертвы в ядре GPU. Модели вычислений на GPU препятствуют длительной работе функций ядра GPU, потому нынешние GPU не поддерживают преимущественное планирование. Длительно исполняющиеся программы GPU тем самым используют либо несколько ядер, либо же ядро неоднократно и обрабатывая промежуточные результаты. Основными целями этой атаки являются часто используемые данные, хранящиеся в локальной памяти вычислительного блока и локальной памяти каждого ядра. Например, libgpucrypto, криптографическая библиотека от SSLShader, загружает секретные ключи, AES S-Box, и значения p и q алгоритма RSA в локальную и защищенную память для того, чтобы повысить производительность. Если программа жертвы не очистит локальную память в конце каждого выполнения функций ядра, злоумышленник может легко прочитать данные.
  1. Процедура атаки: Алгоритм 3 демонстрирует пример атаки ЕОК. В этом алгоритме, мы выполняем функции ядра, которые пытаются прочитать локальную память GPU и скопировать результаты в память процессора. Также проверяются различия в имеющемся размере памяти, чтобы определить, когда программа жертвы динамически освобождает что-то из глобальной памяти. Когда мы обнаруживаем такое освобождение памяти, мы также пытаемся прочитать его. Цикл для чтения локальной памяти заканчивается, когда программа жертвой выходит из GPU, и мы, наконец, выполняем атаку EOC.
  1. Данные кэша L1 в графических процессоров NVIDIA: Атака ЕОК может получить конфиденциальные данные, хранящиеся в кэше данных L1 в графических процессоров NVIDIA. Графические процессоры NVIDIA использовать часть локальной памяти их вычислительных блоков в качестве кэша данных уровня L1 глобальной памяти. Программисты могут гибко конфигурировать размер локальной памяти и кэша данных L1: 16 Кбайт для локальной памяти и 48 Кб для кэша данных L1, или наоборот. Тем не менее, эта конфигурация позволяет злоумышленникам читать 32 KB перекрывающей области, используемой кэшем данных L1 программы жертвы.
Рисунок 5. Макеты памяти конфигурируемой локальной памяти и кэша данных L1 (графические процессоры NVIDIA).

Рисунок 5 показывает макет локальной памяти и кэша данных L1, проверяемых путем проведения следующего эксперимента. Сначала выполним программу жертвы, которая записывает нули в 16 КБ локальной памяти и считывает 512 Мб общей памяти, заполненной значением 0x11111111. Затем выполним программу атаки, которая считывает и сбрасывает 48 КБ локальной памяти. Мы обнаружим, что первые 16 Кбайт локальной памяти заполнены нулями, а следующие 32 КБ локальной памяти заполнены 0x11111111. Таким образом, злоумышленники могут получить первые 2/3 кэша данных L1 из программы жертвы, если жертва использует кэш данных L1 48 Кб.

Рисунок 6. Образец функции ядра для очистки кэша данных L1.

Программа, использующая GPU, может очистить кэшированные данные, читая непрерывный 48 KB блок глобальной памяти, заполненной фиктивным значением, поскольку кэш данных L1 из графических процессоров NVIDIA является ассоциативным кэшем. На рис.6 показан пример кода CUDA, который очищает кэш данных L1. Она подготавливает массив размером 48 KB, заполненный нулями, в глобальной памяти заранее и читает нули из массива, чтобы очистить кэш данных L1.

  1. Система с несколькими пользователями: Ограничение атаки ЕОК состоит в том, что он может читать только локальную память ядра жертвы, которое использует GPU только перед атакой на ядро. Это означает, что, когда несколько программ жертвы совместно используют GPU, атака ядра может видеть только из данных, хранящихся в локальной памяти.

Атаки на графический процессор AMD

  1. Различия и повышенная уязвимость: Атаки на графические процессоры AMD немного отличаются от атак на графические процессоры NVIDIA из-за динамического управления памятью чипов AMD и OpenCL1. В отличие от графических процессоров NVIDIA, процессоры AMD и OpenCL не обеспечивают API для проверки доступного объема памяти, так как они динамически управляют глобальной памятью. Когда новая программа, использующая GPU, запрашивает большие блоки памяти, превышающие имеющийся размер глобальной памяти, в то время как старая программа, занимающая часть глобальной памяти, является неактивной, графический процессор AMD автоматически перемещает данные старой программы обратно в память процессора, чтобы выполнить требования новой программы. Графические процессоры NVIDIA не обеспечивают такую функциональность, хотя они поддерживают OpenCL.

Тем не менее, мы обнаружили, что драйвер GPU AMD не обнуляет память для новой программы. Злоумышленник может прочитать глобальную память программы жертвы, когда она запрашивает память, прежде чем программа освобождает память GPU.

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

  1. Процедура атаки: Алгоритм 4 показывает атаку ЕОК на AMD GPU. Мы выполняем фиктивную функцию ядра и измеряем время ее выполнения, чтобы знать, использует ли программа жертвы GPU. Если это так, время выполнения фиктивной функции ядра, конечно, увеличивается, так как графические процессоры не может одновременно выполнять различные программы. Когда злоумышленник обнаруживает жертву, он выполняет функцию ядра для чтения локальной памяти. Кроме того, злоумышленник может также получить всю глобальную память из-за динамического управления памятью AMD GPU. Следовательно, атака EoC является необходимой при нападении на AMD GPU.

Тестовые платформы

Мы тестируем пять различных платформ, чтобы проверить защиту от предлагаемых атак (Таблица I). Тестовые платформы включают NVIDIA GeForce 210, NVIDIA Tesla C2050, NVIDIA GeForce GTX 780, AMD Radeon HD 7850, AMD и FirePro W9000 графические процессоры на Linux операционных системах с различными версиями драйверов. Мы проверяем, что наши атаки успешно проходят на тестовых платформах без ошибок.

ПЛАТФОРМЫ ДЛЯ ПРОВЕДЕНИЯ ТЕСТОВЫХ АТАК (Таблица 1)
Графический процессор (поколение) Объём памяти графического процессора Драйвер ОС Ядро ЦПУ Объём памяти ЦПУ
NVIDIA
GeForce 210 (GT200) 0.5 ГБ 319.37 Ubuntu 12.04 3.5.0 Intel Pentium Dual-Core E6300 4 ГБ
Tesla C2050 (Fermi) 2.6 ГБ 304.108 CentOS 6.3 2.6.32 Intel Xeon X5650*2 24 ГБ
GeForce GTX 780 (Kepler) 3.0 ГБ 325.15 Ubuntu 12.04 3.5.0 Intel Core i7-2600 8 ГБ
AMD
Radeon HD 7850 (Pitcairn) 1.8 ГБ 13.1 CentOS 6.4 2.6.32 Intel Xeon E5430*2 8 ГБ
FirePro W9000 (Tahiti) 6.0 ГБ 12.104.2 CentOS 6.4 2.6.32 Intel Xeon E5430*2 8 ГБ

Атаки на "Реальные" программы

Пока мы объясняем наши атаки по раскрытию GPU памяти, используемые экспериментальной программой GPU, которую мы сделали, только для хранения неважных данных. Чтобы показать, что наши атаки не только широко применимы, но также имеет решающее значение и для GPUs и их пользователей, мы должны атаковать реальные программы,(1) использующие API для GPU, (2) имеющие дело с конфиденциальными данными, и (3) являющиеся популярными. Последние веб-браузеры, такие как Chromium и Firefox, удовлетворяют всем требованиям: (1) они используют графические интерфейсы для эффективного рендеринга веб-страниц, (2) они обрабатывают личные данные пользователя, такие как история поиска, и (3) они очень популярны. Таким образом, мы выбираем их в качестве наших целей атак, обсудим результаты в следующем разделе.

Выявление истории поиска веб-браузера с графическими процессорами

В этом разделе мы объясняем наши атаки на веб-браузеры для вывода веб-истории посещенных страниц из пользователя, ставшего жертвой, с использованием данных извлеченных из GPUs путем использования атаки объясненной в Разделе IV. Последние веб-браузеры, такие как Chromium и Firefox, поддерживают GPU-ускоренный рендеринг веб-страницы, таким образом, мы ожидаем, что текстуры веб-страниц, подвергнутых рендерингу, могут оставаться в GPU памяти. Наши атаки вывода сопоставляют GPU дамп памяти с известным дампом веб-страниц или с известным снимком веб-страниц, которые пострадавший пользователь посетил.

Мы определяем, что веб-страницы текстуры остаются не в локальной и закрытой памяти, а в глобальной памяти. Содержание локальной памяти и памяти с ограниченным доступом не изменится в соответствии с тем, какие веб-страницы посетила жертва, но изменяется в соответствии с тем, какие веб-браузеры использует жертва. Следовательно, мы ориентируемся на нападения на глобальную память, чтобы вывести историю веб-поиска в Интернете.

Веб-браузеры и конфигурации

Мы используем Chromium веб-браузер версии 30 и Firefox веб-браузер версии 25 в этом исследовании. Для веб-браузере Chromium, мы включаем опцию "GPU композитинг всей страницы", чтобы использовать композицию GPU-ускоренных веб-страниц. Для веб-браузере Firefox, мы позволяем layers.offmainthreadcomposition.enabled и layers.acceleration.force-enabl опции и отключаем опцию layers. use-deprecated-texture. Мы открываем веб-браузеры на трех системах Linux с NVIDIA GeForce210, с NVIDA GeForce GTX 780, и с AMD FirePro W9000 GPUs (Таблица I). Системы Linux с графическим процессором NVIDIA использует Xfce 4.8, а другая система Linux с AMD GPU использует Gnome 2.28.2.

GPU дамп памяти и преобразование текстуры

Когда мы рассматриваем GPU дамп памяти google.com извлеченный из веб-браузера Chromium с NVIDIA GeForce GTX 780 GPU, полученных путем проведения атаки EоC, мы находим ряд 32-битных значений, которые, кажется, представляют цвета, такие как 0x00FFFFFF, 0x00404040, 0x00e85947 и 0x00da3d29. Начиная с самого старшего бита, мы рассматриваем каждые два байта, как пробел, красное, зеленое и синее цветовое значений, соответственно. Построим рисунок 1b рассматривая каждое значение по правилу, игнорируя черные (нули).

Как показано на рисунке 1, GPU хранилища текстур в памяти GPU находится в несортированной форме, так что мы нужны решения для их распознавания. Тем не менее, восстановить исходные текстуры из перестроенных текстур трудно, потому что (1) поставщики GPU не ничего не задокументировали о аппаратном управлении уровня текстуры, (2) GPU имеют виртуальную и страничную память, и (3) дампы памяти GPU также содержат другие не цветовые данные. Таким образом, вместо того, чтобы восстановить исходные текстуры, мы стремимся разработать методы выведения посещенных веб-страниц из переорганизованных текстур.

Обзор сценариев атак

Рассмотрим три сценария атаки, чтобы знать, как злоумышленники могут вывести историю просмотров жертв путем использования графических процессоров в различных ситуациях. Во-первых, мы считаем, что злоумышленник готовит GPU копию содержимого памяти известных веб-страниц, извлеченных из того же GPU, используемого жертвой, и пытается сравнить их с GPU дампа памяти неизвестной веб-страницы. Мы подтверждаем, что эта атака может правильно вывести до 95,4% случайно выбранных 100 первых страницах Alexa Top 1000 сайтов. Во-вторых, мы считаем злоумышленником того, кто готовит изображение снимка известных веб-страниц и пытается сравнить их с GPU дампа памяти неизвестной веб-страницы. В отличие от первой атаки, эта атака не требует, чтобы злоумышленник и жертвы использовали один и тот же GPU. Эта атака правильно выводит ~50% случайно выбранных 100 первых страниц. В-третьих, мы считаем злоумышленником пытающимся атаковать жертву того, кто одновременно открывает множество веб-страниц, используя несколько вкладок или окон. Заметим, что злоумышленник может точно вывести веб-страницы первой вкладки или последнее открытое окне.

Атака с использованием известного дампа памяти GPU

В этой атаке, злоумышленник готовит GPU дампы памяти известных веб-страниц, чтобы сравнить их с новым GPU дампами памяти веб-браузера жертвы. Мы выбираем первые страницы Alexa Top 1000 сайтов, как наш набор данных. Мы посещаем каждый из них, используя Chromium и Firefox веб-браузеры с NVIDIA и AMD GPU, соответственно, и закрываем браузеры на 60 секунд позже, во время записи GPU дампа памяти с помощью атаки EоC. Мы повторяем эти процедуры 10 раз, чтобы усреднить результаты.

Мы используем три метода сопоставления для сравнения GPU дампов памяти: соответствующий пиксель последовательности, RGB гистограмма соответствия, и их комбинация.

1) Частота совпадающей последовательности: Согласование последовательности пикселей сравнивает не-чёрные и не-белые наборы смежных пикселей последовательности, извлеченные из двух GPU дампы памяти с помощью индекса Jaccard (СО). Мы игнорируем (1) черные пиксели, потому что не можем отличить их от нуля в памяти и (2) белые пиксели, потому что большинство веб-страниц имеют большое количество белых пикселей.

Например, если дамп GPU памяти содержит следующие пиксели , где - является кортежем из красных, синих, зеленых и цветовых значений (0-255), черный (0,0,0), и - белый (255,255,255), множество последовательность пикселей . Кроме того, JI из следующих двух наборов последовательностей пикселей



представляется следующей формулой:


Рис.7 Сходство последовательностей пикселей между дампами страниц, взятых из процессоров NVIDIA и AMD.
Рис. 8 Количество памяти графического процессора (NVIDIA GTX 780), выделяемой браузером Chrome для запуска 4-х веб-страниц.
Рис. 9 Сходство последовательностей пикселей одинаковых веб-страниц, извлечённых из разных браузеров(NVIDIA GeForce GTX 780; между различными поколениями графических процессоров (NVIDIA GeForce 210 и GTX 780, браузер Chrome); между различными поставщиками(NVIDIA GTX 780 и AMD 9000, браузер Chrome).

На рисунке 7 изображены графики сходства последовательностей пикселей одинаковых и разных веб-страниц (полученные с использованием процессоров NVDIA и AMD). Заметим, что сходство последовательностей пикселей между одинаковыми страницами гораздо выше, чем при рассмотрении разных страниц, во всех случаях. Средний коэффициент сходства между одинаковыми страницами - 0,865, в то время как между одинаковыми - 0,014 в браузере Chrome с графическим процессором от NVIDIA; для браузера Firefox с тем же процессором коэффициенты 0,478 и 0,029, соответственно; а для процессора AMD коэффициенты следующие - 0,671 и 0,007 у браузера Chrome, 0,888 и 0,060 у браузера Firefox (для одинаковых и разных страниц, соответственно). При определении взаимного сходства между разными веб-страницами используется усреднённый набор последовательности пикселей для каждой страницы, чьё среднее сходство между наборами последовательностей пикселей одинаковых страниц - наибольшее.

Далее проверим (1) одинаковые веб-страницы с низким сходством последовательности пикселей и (2) разные страницы, у которых сходство последовательностей - высокое. Во-первых, большинство одинаковых веб-страниц с низким сходством – динамические страницы, показывающие различные изображения при каждом посещении, такие как apple.com и tumblr.com. Если злоумышленники подготовят некоторое количество дампов памяти графического процессора, соответствующих динамическому содержимому (котенту), они могут преодолеть это ограничение.

Во-вторых, большинство различных страниц с высоким сходством – тоже похожие или вообще одинаковые страницы только с разными именами домена, такие как (google.com, google.co.uk) и (facebook.com, fbcdn.net). Мы уверены, что различать страницы не так важно, потому что злоумышленники могут сделать выводы о предпочтениях пользователя используя лишь одну из похожих страниц. Кроме того, мы можем отличить их, если отследим изменения в использовании памяти графического процессора с помощью браузеров, таких как Memento [1], например. Рисунок 8 демонстрирует, что веб-браузер Chrome имеет различные шаблоны использования памяти графического процессора, при визуализации четырёх различных веб-страниц. Однако, такой мониторинг работает только с графическими процессорами от NVDIA, потому что процессоры AMD не предоставляют прикладных интерфейсов, чтобы проверить доступный размер глобальной памяти. Ограничением сопоставления последовательностей пикселей является то, что последовательности в значительной степени зависят от того, какой графический процессор и веб-браузер использует жертва (Рисунок 9). По этой причине злоумышленники должны подготовить веб-браузер и графический процессор, эквивалентные тем, что используются жертвой, чтобы выполнить такую атаку.

2) Сопоставление RGB-гистограмм: процедура сопоставления RGB-гистограмм сравнивает «не чёрные» и «не белые» гистограммы, полученные от двух дампов памяти графического процессора, с использованием расстояния Евклида. RGB-гистограмма – это кортеж из 256 величин красных, синих и зелёных каналов, что можно представить в виде формулы:

Рис. 10 Расстояние RGB-гистограмм между дампами страниц, извлечённых из графических процессоров NVIDIA и AMD.
Рис. 11 Расстояние RGB-гистограмм между дампами, извлеченными из различных браузеров (на NVIDIA GeForce GTX 780 ); графических процессоров различных поколений (GeForce 210 и GTX 780, браузер Chrome); и различных производителей (NVIDIA GTX 780 и AMD W9000), браузер Chrome.
Рис. 12 Процент правильно полученных страниц в зависимости от графических процессоров, браузеров и методов сравнения.

Например, пиксель (128, 64, 32) сопоставляется 128, 320 и 544 величинам кортежа, соответственно. Проверим различие кортежей RGB-гистограмм, разделив их на сумму всех 768 значений (нормализация) и вычислив Евклидово расстояние, используя метод случайной проекции для снижения размерности [2].

Рисунок 10 показывает коробчатые диаграммы расстояния RGB-гистограмм одинаковых и разных страниц с графическими процессорами от NVIDIA и AMD. Определяем, что расстояние гистограмм между одинаковыми страницами короче, чем между разными страницами, в любых случаях. Среднее расстояние между одинаковыми страницами – 0,004, в то время как между разными страницами – 0,210 в браузере Chrome с графическим процессором NVIDIA; в браузере Firefox с процессором NVIDIA – 0,011 и 0,093; в браузере Chrome с процессором AMD – 0,003 и 0,196; в браузере Firefox с процессором AMD – 0,004 и 0,150. Опять же, динамические веб-страницы и похожие или одинаковые страницы с разными именами домена снижают риск возникновения ошибок также, как и сопоставление последовательности пикселей.

Поскольку RGB-гистограмма обладает более слабой корреляцией с графическими процессорами, чем последовательности точек, подготовка такого же процессора, каким пользуется жертва – обязательный этап при проведении подобного рода атаки. На рисунке 11 показано, что RGB-гистограмма расстояний между одинаковыми дампами страниц, извлечённых из разных графических процессоров, короче, чем между разными страницами при использовании одного и того же браузера. В отличии от этого, дампы из разных браузеров заметно отличаются, так что злоумышленникам придётся подготовить различные наборы дампов для разных браузеров.

3) Точность вывода и комбинированное сравнение: Оценим точность вывода предлагаемых методов сравнения. Случайным образом выберем 100 начальных страниц из Alexa Top 1000 сайтов и будем посещать их, записывая при этом дампы памяти. Затем сравним каждый новый дамп с уже известными, чтобы вывести соответствующие веб-страницы. Когда обнаружим, что известный дамп имеет большое сходство или меньшее расстояние с новым дампом (ближайшим соседом), будем утверждать, что они оба соответствуют одинаковым страницам. В добавок к этому, если предложенные методы сравнения решат, что одинаковые или похожие страницы с разным доменом совпадают, то можно будет считать, что методы работают верно, потому как посещение сайта google.com или google.fr имеет незначительную разницу при выводе предпочтений жертвы. Проведём эту процедуру 10 раз и вычислим результат в среднем. Рисунок 12 показывает оценочную точность выводов предложенных методов. В среднем, сравнение последовательностей пикселей может вывести 69,4% из 100 случайно выбранных веб-страниц, а сравнение RGB-гистограмм выдаст 60,9% из них. Можно определить, что браузер Chrome с графическим процессором NVIDIA и Firefox браузер с процессором AMD – более уязвимы.

В конце, одновременно применим способы сопоставления пикселей и гистограмм при сравнении дампов для того, чтобы увеличить точность выводов. Процедура заключается в следующем. Вначале, мы используем сопоставление последовательностей пикселей для определения k самых похожих дампов на новые (k ближайших соседа). Затем, применим сравнение гистограмм для определения одного дампа из выбранных k, который будет находится на наименьшем расстоянии от нового. Положим, что новый дамп будет соответствовать странице нового дампа. Как показано на рисунке 12, комбинированное сравнение достигло наивысшего результата: оно корректно определяет 84,6% от 100 случайно выбранных веб-страниц в среднем. В частности, в большей опасности те, кто используют браузер Chrome с графическим процессором NVIDIA, потому что атака с применением комбинированного сопоставления может определить страницы, которые посещал пользователь с 95,4% точностью.

4) Эффективность: Наконец, мы проверим эффективность наших методов сопоставления. Для этих измерений мы используем тестовую платформу, работающую на ядре Intel Core i7-2600 CPU и имеющую в своём распоряжении 8 Гб памяти. В среднем, уходит приблизительно 0,451 и 0,002 секунды, чтобы выполнить сопоставление последовательности пикселей и сопоставление РГБ гистограмм между двумя дампами памяти графического процессора, соответственно. Среднее время выполнения комбинированного сравнения – сумма двух средних величин. Теперь, когда мы можем получить каждое сравнение двух дампов памяти графического процессора параллельно, мы также можем ускорить работу методов сопоставления, используя параллельные системы данных (например, мультиядровый процессор или вычислительные интерфейсы прикладного программирования графических процессоров). Мы опустим детали подобного рода ускорений в этой работе, потому что уменьшение издержек на атаки – не главная наша цель.

Атака с использованием снимка страницы

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

Мы представляем другой метод для дальнейшего уменьшения вычислительных расходов на атаки: использование известных скриншотов страниц вместо дампов памяти графического процессора. Для начала, мы используем PhantomJS [3] для загрузки начальных страниц сайтов из списка Alexa Top 1000, в то же время будем делать их снимки. Затем, мы сравним снимки с дампами памяти графического процессора, используя сопоставление с помощью RGB- гистограмм. Отметим, что мы не сможем применить сопоставление последовательностей пикселей, используя скриншоты, из-за перераспределения текстур.

Рис. 13 Расстояние RGB-гистограмм между снимками веб-страниц и их дампами.
Рис. 14 Сравнения между комбинированными дампами и дампами страниц переднего и заднего плана в двух вкладках (Chrome и GTX 780).
Рис. 15 Сравнения между комбинированными дампами и дампами страниц, вызываемых одна за другой, в двух разных окнах (Chrome и GTX 780).

Когда мы делаем снимок интернет-страницы, мы устанавливаем page.clipRect в PhantomJS, чтобы подойти под размер экрана для создания снимка размером с наш экран. Это делается потому, что дампы памяти графического процессора содержат только часть страниц, отображённых на экране, в то время как PhantomJS по умолчанию также содержит часть страниц, не отображённых на экране (полный снимок веб-страницы).

Рисунок 13 показывает графики различия RGB-гистограмм между снимками страниц и дампами. Мы можем определить, что RGB-гистограмма, совпадающая между снимками и дампами, полученными из браузеров Chrome, совместно с хорошей работой графических процессоров: средняя дистанция между одинаковыми страницами – 0,064, в то время как то же самое между разными страницами – 0,214 в графическом процессоре от NVIDIA, и средняя дистанция между одинаковыми страницами – 0,009, в то время как то же самое между разными страницами – 0,225 в графических процессорах от AMD. В сравнении, гистограмма сравнения получилось не очень хорошей, когда сравнивались браузеры Firefox с графическими процессорами: их различия очень велики даже при сравнении одинаковых страниц. Это происходит из-за того, что дампы, извлечённые из браузеров Firefox, также содержат нетекстурные данные, которые сказываются на результате низкой выводимой точности.

После мы проверили предполагаемую точность, как было объяснено в секции V-D. Мы корректно определили приблизительно 50% и 22% случайно выбранных 100 начальных страниц, используя веб-браузер Chrome с графическими процессорами от NVIDIA и AMD, соответственно, что хуже, чем атака с использованием известных дампов памяти графических процессоров, но тем не менее результаты процессоров NVIDIA довольно значимы.

Атака на пользователей, которые загружают несколько страниц одновременно

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

Для начала, мы посетим каждую стартовую страницу сайтов из списка Alexa Top 100 одновременно вместе со случайно выбранной страницей из этого же списка, используя две вкладки, параллельно записывая дампы памяти графического процессора (10 раз). Затем, проверим схожесть последовательностей пикселей и расстояние на RGB-гистограмме между записанными дампами и уже имеющимися дампами страниц первого и второго плана, соответственно. Для упрощения задачи будем использовать только веб-браузер Chrome и графический процессор NVIDIA GTX 780, выполняя такую атаку.

Можем наблюдать, что полученные дампы памяти страниц с двумя вкладками по большей части содержат последовательности пикселей и RGB-гистограммы страниц переднего плана (Рисунок 14). Из этого делаем вывод, что браузер Chrome не использует графические процессоры для предоставления страниц заднего плана, так как передние поглощают их.

Во-вторых, посетим каждую страницу из списка сайтов Alexa Top 100 сразу после посещения случайно выбранной страницы среди них, используя два разных окна, и запишем дампы памяти графических процессоров (10 раз). Отрегулируем размеры и расположения двух окон, чтобы избежать наложения их друг на друга. Затем проверим, насколько схожи последовательности пикселей и расстояние на RGB-гистограмме между полученными и известными дампами первой и второй воспроизведённой страницы, соответственно.

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

В конце, проверим точность сделанных выводов: комбинированное сопоставление корректно выводит 98,6% веб-страниц, загруженных на активных вкладках (вкладках первого плана), и 90,8% страниц, загруженных во второстепенно-вызываемых окнах. Предположим, что такая относительно низкая точность результатов на окнах, вызываемых вторыми, получается из-за неперезаписанных текстур первого окна. Следовательно, когда жертва посещает некоторое количество страниц, используя браузер с ускоренным графическим процессором, злоумышленники могут достаточно точно вывести какую-либо из страниц так же, как и при загрузке в основной вкладке или на странице, запущенной в последнем открывавшемся окне.

Обсуждение

Простое решение, помогающее избежать предполагаемые атаки – очистка вновь выделенных страниц глобальной памяти так, как это делает WebGL [4]. Более того, графические процессоры должны очищать per-CU локальную память и per-PE закрытую память при переключении контекстов графических процессоров. К сожалению, мы ожидаем, что поставщики графических процессоров несклонны к принятию таких методов, потому что они приведут к деградации работы процессоров. Например, NVIDIA старается уменьшить время переключения между контекстами процессора до 25 мкс и ниже [5]. Тем не менее, полная очистка локальной и закрытой памяти занимает 79 мкс, когда мы запускаем оптимизированную программу по очистке памяти процессора в NVIDIA GeForce GTX 780, что в три раза дольше, чем указанное ранее время переключения. Поставщики графических процессоров могут не согласиться с такими большими затратами времени, так как их главный приоритет – исполнение и производительность. Следовательно, требуются решения новых аппаратных и программных уровней для эффективного очищения памяти процессора, которые не могут быть достигнуты без помощи поставщиков.

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

Похожие работы

В этой главе мы представим некоторые близкие исследования к этой теме.

Удалённая кража пикселей в HTML5

Большое количество исследователей [6][7][8] рассматривают атаки на систему безопасности с помощью фильтров HTML5 CSS, которые позволяют веб-разработчикам применять различные графические эффекты на страницы с использованием хостовых графических процессоров. С применением CSS фильтров на целевой странице, загруженной во фрейм, пока идёт подсчёт времени завершения, фильтровые CSS-атаки могут узнать статус логина пользователя и украсть пиксели этой страницы. Тем не менее, злоумышленники обладают ограниченным полем действий, потому что (1) они должны обманом заставить жертву посетить их подозрительные веб-страницы, и (2) многие страницы не позволяют браузерам загружать себя во всплывающих окнах, чтобы избежать атаки.

Атаки с использованием графических процессоров

Основанные на графических процессорах способы взлома паролей или значений хэша также являются хорошо известными видами атак [9]. Некоторые академические исследования также используют графические процессоры для проведения обыкновенных атак. Василиадис и др. [10] описывают возможность наведения полного беспорядка с помощью вредоносных программ с использованием графических процессоров. Вначале, они загружают зашифрованный вирус в основную память хостового компьютера и помещают её адрес в память графического процессора, чтобы получить прямой доступ к основной памяти через процессор, это также известно, как память нулевого копирования [11]. Затем их код расшифровывает вредоносный код, а хост-компьютер запускает его. Клавиатурный перехватчик Ладакиса и др. [12] также полагается на системы с распределением памяти. Перехватчик, для начала, использует руткит-программу для отображение буфера клавиатуры, находящегося в памяти ядра, в память графического процессора. Затем, часть перехватчика, принадлежащая процессору записывает нажатия клавиш через отображённый буфер клавиатуры, а потом возвращает записанные нажатия хосту.

Главные способы применения графических процессоров

Некоторые исследователи проводят различные работы по применению графических процессоров для решения важных и требующих интенсивных вычислений проблем. Например, исследователи попытались использовать графические процессоры для улучшения характеристик работы алгоритмов AES [13][14] и RSA [15][16]. Другие реализовали высокоскоростную систему обнаружения вторжений (IDs) [17][18] и ускоритель SSL сертификата безопасности [19]. Остальные исследователи представили роутеры для сетей IP, ускоренные с помощью графических процессоров [20], и ускорители баз данных [21][22].

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

Заключение

Графические процессоры стали более мощными и повсеместными, благодаря им многие приложения улучшили свои рабочие показатели. Тем не менее, никакие тщательные исследования не учитывали их проблем в сфере безопасности. В этой статье были рассмотрены уязвимости графических процессоров, описаны виды атак, которые раскрывают важные данные жертвы, хранящиеся в графических процессорах. Далее, предполагаемые атаки были направлены на известные программы, использующие графические процессоры: веб-браузеры Chrome и Firefox, использующие процессоры для ускорения визуализации веб-страниц. При этом получилось успешно завладеть текстурами страниц, оставшихся в памяти процессора, и вывести их первоначальный вид. Поэтому и поставщики, и разработчики графических процессоров должны осознавать, что программы, зависящие от процессоров, могут быть в опасности, и принять контрмеры, чтобы разобраться с подобными угрозами.

Благодарности

Авторы хотели бы поблагодарить анонимных рецензентов за их содержательные комментарии и предложения. Это исследование было проведено при поддержке министерства науки, информационных и коммуникационных технологий и планирования (MSIP) (Корея), по программе межгосударственных технологий и совета по регулированию (ITRC) национальным агентством по продвижению IT-индустрии (NIPA) (NIPA- 2013-H0301-13-3002) и гранта национальной исследовательской организации (NRF), профинансированным правительством Кореи (NRF-2012-Global Ph.D. Fellowship Program).

Контакты авторов

  1. Department of Computer Science and Engineering POSTECH, Korea. Email: sangho2@postech.ac.kr
  2. Department of Computer Science and Engineering POSTECH, Korea. Email: elixir@postech.ac.kr
  3. Department of Computer Science and Engineering POSTECH, Korea. Email: jangwoo@postech.ac.kr
  4. Department of Computer Science and Engineering POSTECH, Korea. Email: jkim@postech.ac.kr

Ссылки

  1. S. Jana and V. Shmatikov, “Memento: Learning secrets from process footprints,” in Proceedings of the 33rd IEEE Symposium on Security and Privacy (Oakland), 2012.
  2. E. Bingham and H. Mannila, “Random projection in dimensionality reduction: Applications to image and text data,” in Proceedings of the 17th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD), 2001.
  3. A. Hidayat. PhantomJS: Headless WebKit with JavaScript API. http://phantomjs.org.
  4. Khronos, “WebGL security,” http://www.khronos.org/webgl/security/.
  5. NVIDIA, “NVIDIA’s next generation CUDA compute architecture: Fermi,” 2009.
  6. R. Kotcher, Y. Pei, P. Jumde, and C. Jackson, “Crossorigin pixel stealing: Timing attack using CSS filters,” in Proceedings of the 20th ACM Conference on Computer and Communications Security (CCS), 2013
  7. P. Stone, “Pixel perfect timing attacks with HTML5,” in Blackhat USA, 2013
  8. A. Barth, “Adam barth’s proposal,” http://www.schemehostport.com/2011/12/timing-attack-on-css-shaders.html.
  9. D. Goodin, “25-GPU cluster cracks every standard Windows password in <6 hours.”
  10. G. Vasiliadis, M. Polychronakis, and S. Ioannidis, “GPUassisted malware,” in Proceedings of the 5th International Conference on Malicious and Unwanted Software (Malware), 2010.
  11. CUDA C programming guide version 5.5. http://docs.nvidia.com/cuda/cuda-c-programming-guide/.
  12. E. Ladakis, L. Koromilas, G. Vasiliadis, M. Polychronakis, and S. Ioannidis, “You can type, but you can’t hide: A stealthy GPU-based keylogger,” in Proceedings of the 6th European Workshop on System Security (EuroSec), 2013.
  13. D. L. Cook, J. Ioannidis, A. D. Keromytis, and J. Luck, “CryptoGraphics: Secret key cryptography using graphics cards,” in Proceedings of The Cryptographer’s Track at RSA Conference 2005 (CT-RSA), 2005.
  14. O. Harrison and J. Waldron, “Practical symmetric key cryptography on modern graphics hardware,” in Proceedings of the 17th USENIX Security Symposium, 2008
  15. “Efficient acceleration of asymmetric cryptography on graphics hardware,” in Proceedings of the 2nd International Conference on Cryptology in Africa (AFRICACRYPT), 2009.
  16. R. Szerwinski and T. G¨uneysu, “Exploiting the power of GPUs for asymmetric cryptography,” in Proceedings of the 10th Workshop on Cryptographic Hardware and Embedded Systems (CHES), 2008.
  17. G. Vasiliadis, M. Polychronakis, and S. Ioannidis, “MIDeA: A multi-parallel intrusion detection architecture,” in Proceedings of the 18th ACM Conference on Computer and Communications Security (CCS), 2011.
  18. M. Jamshed, J. Lee, S. Moon, I. Yun, D. Kim, S. Lee, Y. Yi, and K. Park, “Kargus: a highly-scalable softwarebased intrusion detection system,” in Proceedings of the 19th ACM Conference on Computer and Communications Security (CCS), 2012.
  19. K. Jang, S. Han, S. Han, S. Moon, and K. Park, “SSLShader: Cheap SSL acceleration with commodity processors,” in Proceedings of the 8th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2011.
  20. S. Han, K. Jang, K. Park, and S. Moon, “PacketShader: a GPU-accelerated software router,” in Proceedings of the ACM SIGCOMM 2010 Conference, 2010.
  21. P. Bakkum and K. Skadron, “Accelerating SQL database operations on a GPU with CUDA,” in Proceedings of the 3rd Workshop on General-Purpose Computation on Graphics Processing Units (GPGPU), 2010.
  22. H. Wu, G. Diamos, S. Cadambi, and S. Yalamanchili, “Kernel weaver: Automatically fusing database primitives for efficient GPU computation,” in Proceedings of the 45th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 2012.