Спускаем MAYHEM на двоичный код(часть 3)

Спускаем MAYHEM на двоичный код(часть 3)

В данном документе мы представляем MAYHEM, новую систему для автоматического поиска эксплуатируемых багов в двоичных файлах программ.

Авторы: Sang Kil Cha, Thanassis Avgerinos, Alexandre Rebert и David Brumley

VII Реализация

MAYHEM состоит из приблизительно 27 тысяч строк кода на C/C++ и OCaml. Наш фреймворк двоичного инструментирования построен на основе Pin [18], а все перехватчики моделируемой системы и API-вызовы написаны на C/C++. Движок символического выполнения написан целиком на OCaml и состоит из 10000 строк кода. Мы используем BAP [15] для преобразования ассемблерных инструкций в ПЯ. Мы используем Z3 [12] в качестве процедуры принятия решений, для которой мы построили прямые связки с OCalm. Чтобы сделать возможным удаленный обмен информацией между двумя данными компонентами, мы создали нашу собственную кроссплатформенную легковесную реализацию RPC-протокола (на C++ и OCalm). Кроме того, в целях сравнения мы реализовали все три режима символического выполнения: онлайновый, оффлайновый и гибридный.

VIII. Оценка

A. Экспериментальная установка

Мы оценивали нашу систему на двух виртуальных машинах, запущенных на настольном компьютере с процессором 3.40GHz Intel(R) Core i7-2600 и 16 ГБ оперативной памяти. Каждая ВМ имела 4ГБ памяти. На машинах были установлены Debian Linux (Squeeze) VM и Windows XP SP3.

B. Обнаружение эксплуатируемых багов

Мы загрузили 29 различных уязвимых программ, чтобы проверить эффективность MAYHEM. Таблица I обобщает наши результаты. Эксперименты проводились на немодифицированных, лишенных отладочной информации двоичных файлах как под Linux, так и под Windows. Одно из Windows-приложений (Dizzy) являлось упакованным.

ПрограммаТип эксплоитаИсточник входных данныхРазмер символических входных данныхСимв. памятьПредусловиеAdvisory ID.Время генерации эксплоита (с)
LinuxA2psStack OverflowEnv. Vars550crashingEDB-ID-816189
AeonStack OverflowEnv. Vars1000lengthCVE-2005-101910
AspellStack OverflowStdin750crashingCVE-2004-054882
AtphttpdStack OverflowNetwork800XcrashingCVE-2000-1816209
FreeRadiusStack OverflowEnv.9000lengthZero-Day133
GhostScriptStack OverflowArg.2000prefixCVE-2010-205518
GlftpdStack OverflowArg.300lengthOSVDB-ID-163734
GnugolStack OverflowEnv.3200lengthZero-Day22
HtgetStack OverflowEnv.vars350XlengthN/A7
HtpasswdStack OverflowArg.400XprefixOSVDB-ID-100684
IwconfigStack OverflowArg.400lengthCVE-2003-09472
Mbse-bbsStack OverflowEnv. vars4200XlengthCVE-2007-0368362
nCompressStack OverflowArg.1400lengthCVE-2001-141311
OrzHttpdFormat StringNetwork400lengthOSVDB-ID-609446
PSUtilsStack OverflowArg.300lengthEDB-ID-89046
RsyncStack OverflowEnv. Vars100XlengthCVE-2004-20938
SharUtilsFormat StringArg.300prefixOSVDB-ID-1025517
SocatFormat StringArg.600prefixCVE-2004-148447
Squirrel MailStack OverflowArg.150lengthCVE-2004-05242
TipxdFormat StringArg.250lengthOSVDB-ID-1234610
xGalagaStack OverflowEnv. Vars300lengthCVE-2003-04543
XtokkaetamaStack OverflowArg.100crashingOSVDB-ID-234310
WindowsCoolplayerStack OverflowFiles210XcrashingCVE-2008-3408164
DestinyStack OverflowFiles2100XcrashingOSVDB-ID-53249963
DizzyStack Overflow (SEH)Arg.519XcrashingEDB-ID-1556613,260
GAlanStack OverflowFiles1500XprefixOSVDB-ID-60897831
GSPlayerStack OverflowFiles400XcrashingOSVDB-ID-69006120
MuseStack OverflowFiles250XcrashingOSVDB-ID-67277481
SoritongStack Overflow (SEH)Files1000XcrashingCVE-2009-1643845

Таблица 1: Список программ, в которых MAYHEM находит эксплуатируемые баги.

Столбец 3 показывает тип эксплоита, обнаруженный MAYHEM, один из описанных в §VI. Столбец 4 показывает источники символических данных, которые мы рассматривали для каждой из программ. Здесь представлены примеры всех типов источников символических входных данных, которые поддерживает MAYHEM, включая аргументы командной строки (Arg.), переменные окружения (Env. Vars), сетевые пакеты (Network) и символические файлы (Files). Столбец 5 – это размер символического источника. Столбец 6 описывает предусловия, которые мы предоставили MAYHEM для каждой из 29 программ. Они делятся на три категории: длина, префикс и данные, приводящие к аварийному завершению, как описано в §IV-D. Столбец 7 показывает консультативное заключение для всех продемонстрированных эксплоитов. MAYHEM смог найти две уязвимости нулевого дня в двух Linux-приложениях, о которых мы сообщили разработчикам.

Последний столбец показывает время генерации эксплоита для проанализированных MAYHEM программ. Мы измеряли время генерации эксплоита как промежуток от начала анализа до создания первого рабочего эксплоита. Требуемое время сильно разнилось в зависимости от сложности приложения и размера символических входных данных. Быстрее всего (1.9 секунды) эксплоит нашелся для утилиты конфигурации беспроводных сетей в Linux, iwconfig, а больше всего времени (около 4 часов) ушло на поиск эксплоита для Windows-программы Dizzy.

C. Масштабируемость гибридного символического выполнения

Мы измерили эффективность гибридного символического выполнения по двум шкалам: использование памяти и скорость.

Рисунок 7: Использование памяти в онлайновом, оффлайновом и гибридном режимах.

Требует меньше памяти, чем онлайновое выполнение. Рисунок 7 показывает среднее использование памяти MAYHEM за время анализа утилиты echo из coreutils в ходе онлайнового, оффлайнового и гибридного выполнений. После нескольких минут онлайновое выполнение достигает максимального количества действующих интерпретаторов и начинает прерывать пути выполнения. В данной точке память увеличивается линейно, поскольку исследуемые пути становятся глубже. Отметим, что в начале гибридное выполнение потребляет столько же памяти, что и онлайновое, не превосходя установленного порога, но использует ресурсы памяти более агрессивно, чем оффлайновое выполнение на всем протяжении работы. Оффлайновое выполнение требует гораздо меньшего количества памяти (в среднем менее 500КБ), но ценой более низкой производительности, что продемонстрировано ниже.

Рисунок 8: время исследования для различных ограничений на максимальное число действующих выполнителей.

Быстрее, чем оффлайновое выполнение. Рисунок 8 показывает время исследования путей для утилиты /bin/echo при различных ограничениях на максимальное количество действующих выполнителей. В данном эксперименте мы использовали 6 байтов символических аргументов для исследования всего пространства входных данных за разумное время. Когда максимальное количество действующих выполнителей равно 1, MAYHEM сохранял на диск контрольные точки – средний размер которых 30 КБ – для каждой символической ветви, что эквивалентно оффлайновому исполнению. Когда максимальное количество действующих выполнителей равнялось 128 или больше, MAYHEM не нужно было создавать контрольные точки, что эквивалентно онлайновому выполнению. В результате онлайновое выполнение заняло 25 секунд, тогда как оффлайновому понадобилось 1400. В рамках данного эксперимента онлайновое выполнение оказалось в 56 раз быстрее, чем оффлайновое. Мы выделили две основных причины такого улучшения производительности.

Во-первых, издержки повторного выполнения больше, чем издержки переключения между контекстами двух состояний выполнения (§IV-B). В оффлайновой схеме MAYHEM тратит более 25% времени на повторное выполнение предыдущих путей. В онлайновом случае на переключение контекста было потрачено всего 2% времени. Во-вторых, в нашей реализации онлайновое выполнение является более эффективным относительно кэширования. В частности, онлайновое выполнение более эффективно использует кодовый кэш Pin [18] путем переключения между путями в памяти в ходе одного выполнения. В результате кодовый кэш делает онлайновое выполнение в 40 раз быстрее, чем оффлайновое.

Кроме того, мы запускали Windows-программу с графическим интерфейсом (MiniShare), чтобы сравнить производительность между оффлайновым и гибридным выполнением. Мы выбрали эту программу, поскольку она не требует взаимодействия с пользователем (например, кликов мышью), чтобы запустить символическое выполнение. Мы выполняли данную программу в течение часа для каждого режима выполнения. Гибридное выполнение оказалось в 10 раз быстрее, чем оффлайновое.

D. Обработка символической памяти в реальных приложениях

Как уже говорилось в §V, индексное моделирование памяти позволяет MAYHEM делать заключения о символических индексах. Результаты наших экспериментов из таблицы I показывают, что более 40% программ требуют моделирования символической памяти (столбец 6) для нахождения уязвимости. Другими словами, после нескольких часов анализа MAYHEM не мог генерировать эксплоиты для этих программ без индексного моделирования памяти. Чтобы понять причину этого, мы исследовали наши оптимизации индексного моделирования памяти на сервере atphttpd.

L HitsR HitsMisses# QueriesTime (sec)
No opt.N/AN/AN/A217,1791,841
+ VSAN/AN/AN/A49,424437
+ R cacheN/A3996710,331187
+ L cache394056724277

Таблица II: Эффективность оптимизаций разрешения границ. Кэши L и R – это соответственно кэши Лемм (Lemma) и Уточнений (Refinement), определенные в §V.

Разрешение границ. Таблица II показывает время, требуемое MAYHEM для нахождения уязвимости в atphttpd при разных уровнях оптимизации алгоритма разрешения границ. Время включает обнаружение эксплоита, но не включает его генерацию (поскольку алгоритм разрешения границ не оказывает на нее влияния). Строка 3 показывает, что VSA уменьшает среднее количество запросов к SMT-решателю на одно обращение к символической памяти с 54 до 14 и сокращает затраченное время на 75%.

Строка 4 показывает количество запросов, когда помимо VSA включен кэш уточнений (R-кэш). R-кэш уменьшает количество необходимых двоичных поисков с 4003 до 7, давая 57-процентный прирост скорости. Последняя строка показывает влияние кэша лемм (L-кэша), включенного поверх других оптимизаций. L-кэш берет на себя большую часть нагрузки R-кэша, что приводит к 59% ускорению. Мы не ожидаем, что L-кэш всегда будет столь эффективен, поскольку он сильно зависит от независимости формул в предикате пути. Общий прирост скорости составил 96%.

Представление формулыВремя (сек.)
Несбалансированное двоичное дерево1,754
Сбалансированное двоичное дерево425
Сбалансированное двоичное дерево + Линеаризация192

Таблица III: Сравнение производительности для различных представлений IST.

Представление дерева индексного поиска (IST). Как было упомянуто в §V-B, MAYHEM моделирует загрузки из символической памяти в виде IST. Чтобы показать эффективность этой оптимизации, мы запустили atphttpd с тремя различными представлениями формул (показано в таблице III). Сбалансированный IST оказался более чем в 4 раза быстрее, чем несбалансированное представление двоичного дерева, а с линеаризацией формул мы получили общее девятикратное ускорение. Отметим, что при использовании символических массивов (без IST) мы не смогли обнаружить эксплоит в рамках временных ограничений.

E. Сравнение покрытия кода

Чтобы оценить способность MAYHEM охватывать новые пути, мы загрузили символический выполнитель с открытым кодом (KLEE) и сравнили его производительность с MAYHEM. Отметим, что KLEE работает с исходными кодами, а MAYHEM с двоичными.

Рисунок 9: зависимость покрытия кода, достигнутого MAYHEM, от времени для 25 приложений из набора coreutils.

Мы измеряли покрытие кода 25 приложений из набора coreutils как функцию от времени. MAYHEM запускался для каждого из этих приложений не более, чем на час. Мы использовали сгенерированные тест-кейсы для измерения покрытия кода с помощь утилиты gcov. Результаты показаны на рисунке 9.

Мы использовали 21 утилиту с наименьшим размером кода и еще 4 выбранных нами утилиты большего размера. MAYHEM достиг среднего покрытия 97.56% на приложение и получил 100% покрытие для 13 утилит. Для сравнения KLEE достиг 100% покрытия на 12 утилитах без симулирования сбоев системных вызовов (чтобы иметь одинаковую с MAYHEM конфигурацию). Таким образом, MAYHEM кажется способным конкурировать с KLEE на данном наборе данных. Отметим, что MAYHEM не разработан специально для максимизации покрытия кода. Однако, наши эксперименты позволяют выполнить черновое сравнение с другими символическими выполнителями.

F. Сравнение с AEG

AEGMAYHEM
ProgramTimeLLVMTimeASMTainted ASMTained IL
iwconfig0.506s10,8761.90s394,8762,20012,893
aspell8.698s87,05624.62s696,27526,647133,620
aeon2.188s18,5399.67s623,6847,08743,804
htget0.864s12,7766.76s576,0052,67016,391
tipxd2.343s82,0309.91s647,4982,04319,198
ncompress5.511s60,86011.30s583,3308,77871,195

Таблица IV: Сравнение с AEG: исключительно двоичное выполнение требует большего количества инструкций.

Мы отобрали 8 различных программ из рабочих образцов AEG [2] и запустили оба инструмента для сравнения времени генерации эксплоита для каждой из этих программ, используя одинаковую конфигурацию (Таблица IV). MAYHEM оказался в среднем в 3.4 раза медленнее AEG. AEG использует исходный код, а значит имеет преимущество работы на более высоком уровне абстракции. На двоичном уровне нет типов и высокоуровневых структур вроде функций, переменных, буферов и объектов. Количество исполняемых инструкций (таблица IV) – другой фактор, подчеркивающий разницу между анализом исходного кода и чисто двоичным анализом. Учитывая это, мы полагаем, что данный результат является положительным и показывает конкурентноспособность MAYHEM.

Рисунок 10: время генерации эксплоита в зависимости от размера предусловия.

Размер предусловия. В качестве дополнительного эксперимента мы измеряли, как наличие предусловия влияет на время генерации эксплоита. Мы отобрали 6 программ, которым для нахождения эксплуатируемого бага нужны входные данные, приводящие к аварийному завершению, и стали итеративно уменьшать размер предусловия и измерять время генерации эксплоита. Рисунок 10 обобщает наши результаты в терминах нормализованного размера предусловия – например, нормализованное предусловие размером 70% для 100-байтных данных, приводящих к аварийному завершению, означает, что мы предоставляем MAYHEM 70 байтов данных в качестве предусловия. Хотя поведение кажется зависящим от программы, в большинстве программ мы наблюдали внезапный фазовый переход, когда удаление одного символа могло привести к тому, что MAYHEM переставал обнаруживать эксплуатируемый баг за установленное время. Мы полагаем, что это интересная тема для дальнейших работ в данной области.

G. Настройка производительности

Оптимизация формул. Как говорилось в разделе §IV-E, MAYHEM использует различные методы оптимизации для ускорения запросов к решателю. Для сравнения оптимизированной версии с обычной, мы выключали некоторые или все оптимизации.

Рисунок 11: время генерации MAYHEM эксплоита для различных оптимизаций.

Мы выбрали 15 Linux-программ для оценки ускорения, получаемого при включении различных уровней оптимизации. Рисунок 11 показывает непосредственное сравнение (по количеству найденных эксплоитов и времени их генерации) четырех опций оптимизации формул. Алгебраические упрощения, как правило, ускоряли наш анализ и показали 10% ускорение для 15 тестовых программ. Значительное ускорение имеет место, когда включена оптимизация разбиения на независимые формулы вместе с упрощениями, что дает ускорение в 10-100 раз.

Z3 поддерживает инкрементальное решение, поэтому в качестве дополнительного эксперимента мы измерили время генерации эксплоита в инкрементальном режиме Z3. В большинстве случаев время решения для инкрементальных формул сравнимо с временем, которое мы получали для оптимизации разбиения на независимые формулы. По существу, для половины наших образцов (7 из 15) инкрементальные формулы превзошли независимые формулы. В отличие от предыдущих результатов из этого следует, что использование решателя в инкрементальном режиме может убрать необходимость во многих упрощениях и оптимизациях формул. Недостатком использования решателя в инкрементальном режиме было то, что это делало состояние символического выполнения изменчивым, то есть снижало эффективность использования памяти в длинных тестах.

Рисунок 12: Процент тентированных инструкций для 24 Linux-приложений.

Тентированные инструкции. MAYHEM символически выполняет только блоки тентированных инструкций – все прочие блоки выполняются нативно. Рисунок 12 показывает процент тентированных инструкций для 24 программ (взятых из таблицы I). Более чем 95% инструкций в наших образцах не были тентированы, и данная оптимизация давала приблизительно восьмикратное ускорение.

IX. Обсуждение

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

Мы подчеркиваем, что назначение MAYHEM – информирование пользователя о существовании эксплуатируемых багов. Производимые им эксплоиты предназначены для демонстрации серьезности проблемы и для помощи в отладке и исправлении соответствующих недостатков. MAYHEM не пытается обойти защитные механизмы ОС вроде ASLR или DEP, которые вероятно защитят системы от генерируемых нами эксплоитов. Однако, наша предыдущая работа над Q [25] показывает, что сломанный эксплоит (который перестал работать из-за ASLR или DEP) может быть автоматически трансформирован – с высокой вероятностью – в эксплоит, который обходит оба упомянутых средства защиты современных ОС. Хотя мы могли бы передавать сгенерированные MAYHEM эксплоиты напрямую в Q, в данной работе мы не исследовали эту возможность.

Ограничения. У MAYHEM есть модели не для каждого из системных/библиотечных вызовов. Текущая реализация моделирует около 30 системных вызовов в Linux и 12 библиотечных вызовов в Windows. Для анализа больших и более сложных программ необходимо моделировать большее количество системных вызовов. Это следствие символического выполнения на уровне процесса. Символические выполнители целых систем вроде S2E [28] или BitBlaze [5] могут выполнять код как пользователя, так и ядра, и, таким образом, не имеют данного ограничения. Недостаток таких систем в том, что анализ целой системы может быть гораздо более затратным из-за большей стоимости восстановления состояния и времени, тратящегося на анализ кода ядра. Другое ограничение состоит в том, что MAYHEM может анализировать лишь один поток выполнения при каждом запуске. MAYHEM не может обрабатывать многопоточные программы, в которых потоки взаимодействуют друг с другом (через передачу сообщений или разделяемую память). Наконец, MAYHEM выполняет только тентированные инструкции, а потому обладает теми же недостатками, что и taint-анализ, включая недотентирование, перетентирование и неявные потоки [24].

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

X. Работы, связанные с данной

Brumley и пр. [7] представили автоматическую генерацию эксплоитов на основе патчей (APEG). APEG использует патч для выяснения нахождения бага и затем использует расщепление для построения формул путей выполнения кода от источника входных данных до уязвимой строки. MAYHEM находит уязвимости и сами уязвимые пути кода. Кроме того, понятия эксплоита для APEG является более абстрактным: любые входные данные, которые нарушают проверки, вводимые путем выполнения, считаются эксплоитами. Здесь мы рассматриваем именно эксплоиты, перехватывающие поток управления, которые не генерируются APEG автоматически.

Heelan [14] первым описал метод, который принимает на вход входные данные, приводящие к аварийному завершению программы, вместе с регистром перехода и автоматически генерирует эксплоит. Наше исследование исследует пространство состояний для поиска таких входных данных.

AEG [2] была первой системой, которая решала как проблему обнаружения эксплуатируемых багов, так и автоматичесую генерацию эксплоитов. AEG работает только с исходным кодом и вводит предусловное символическое выполнение как способ сфокусировать символическое выполнение на определенной части пространства поиска.. MAYHEM является логичным расширением AEG на двоичный код. На практике работа с бинарным кодом открывает возможность генерации эксплоитов для более широкого класса программ и сценариев.

Существуют фреймворки исключительно двоичного символического выполнения, например, Bouncer [10], BitFuzz [8], BitTurner [6] FuzzBall [20], McVeto [27], SAGE [13], и S2E [28], которые использовались в разнообразных доменах приложений. При создании MAYHEM мы главным образом решали вопрос расширения двоичного символического выполнения для поиска и демонстрации эксплуатируемых багов. Гибридное символическое выполнение, представленное в данном документе, полностью отличается от гибридного консимволического тестирования [19], которое чередует случайное тестирование с консимволическим выполнением для достижения лучшего покрытия кода.

XI. Заключение

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

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

Мы благодарим нашего руководителя, Кристиана Кадара и анонимных рецензентов за их полезные комментарии и обратную связь. Это исследование было поддержано грантом a DARPA, выданным CyLab в университете Carnegie Mellon (N11AP20005/D11AP00262), грантом NSF Career grant (CNS0953751), и частично DAAD19-02-1-0389 и W911NF-09-1-0273. Содержимое документа не обязательно отражает точку зрения или политику государства.


Примечания

1 Здесь используется менее формальный, но более емкий термин "баг" вместо "программная ошибка"

2 Заметим, что термин "контрольная точка" отличается от "зерна" оффлайнового выполнения, которое является лишь конкретными входными данными.


Ссылки

[1] "Orzhttpd, a small and high performance http server," http://code.google.com/p/orzhttpd/.
[2] T. Avgerinos, S. K. Cha, B. L. T. Hao, and D. Brumley, "AEG: Automatic exploit generation," in Proc. of the Network and Distributed System Security Symposium, Feb. 2011.
[3] D. Babi´ c, L. Martignoni, S. McCamant, and D. Song, "Statically-Directed Dynamic Automated Test Generation," in International Symposium on Software Testing and Analysis. New York, NY, USA: ACM Press, 2011, pp. 12–22.
[4] G. Balakrishnan and T. Reps, "Analyzing memory accesses in x86 executables." in Proc. of the International Conference on Compiler Construction, 2004.
[5] "BitBlaze binary analysis project," http://bitblaze.cs.berkeley.edu, 2007.
[6] BitTurner, "BitTurner," http://www.bitturner.com.
[7] D. Brumley, P. Poosankam, D. Song, and J. Zheng, "Automatic patch-based exploit generation is possible: Techniques and implications," in Proc. of the IEEE Symposium on Security and Privacy, May 2008.
[8] J. Caballero, P. Poosankam, S. McCamant, D. Babic, and D. Song, "Input generation via decomposition and re-stitching: Finding bugs in malware," in Proc. of the ACM Conference on Computer and Communications Security, Chicago, IL, October 2010.
[9] C. Cadar, D. Dunbar, and D. Engler, "KLEE: Unassisted and automatic generation of high-coverage tests for complex systems programs," in Proc. of the USENIX Symposium on Operating System Design and Implementation, Dec. 2008.
[10] M. Costa, M. Castro, L. Zhou, L. Zhang, and M. Peinado, "Bouncer: Securing software by blocking bad input," in Symposium on Operating Systems Principles, Oct. 2007.
[11] J. R. Crandall and F. Chong, "Minos: Architectural support for software security through control data integrity," in Proc. of the International Symposium on Microarchitecture, Dec. 2004.
[12] L. M. de Moura and N. Bjørner, "Z3: An efficient smt solver," in TACAS, 2008, pp. 337–340.
[13] P. Godefroid, M. Levin, and D. Molnar, "Automated whitebox fuzz testing," in Proc. of the Network and Distributed System Security Symposium, Feb. 2008.
[14] S. Heelan, "Automatic Generation of Control Flow Hijacking Exploits for Software Vulnerabilities," Oxford University, Tech. Rep. MSc Thesis, 2002.
[15] I. Jager, T. Avgerinos, E. J. Schwartz, and D. Brumley, "BAP: A binary analysis platform," in Proc. of the Conference on Computer Aided Verification, 2011.
[16] J. King, "Symbolic execution and program testing," Commu- nications of the ACM, vol. 19, pp. 386–394, 1976.
[17] Launchpad, https://bugs.launchpad.net/ubuntu, open bugs in Ubuntu. Checked 03/04/12.
[18] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wallace, V. J. Reddi, and K. Hazelwood, "Pin: Building customized program analysis tools with dynamic instrumentation," in Proc. of the ACM Conference on Programming Language Design and Implementation, Jun. 2005.
[19] R. Majumdar and K. Sen, "Hybrid concolic testing," in Proc. of the ACM Conference on Software Engineering, 2007, pp. 416–426.
[20] L. Martignoni, S. McCamant, P. Poosankam, D. Song, and P. Maniatis, "Path-exploration lifting: Hi-fi tests for lo-fi emulators," in Proc. of the International Conference on Architectural Support for Programming Languages and Operating Systems, London, UK, Mar. 2012.
[21] A. Moser, C. Kruegel, and E. Kirda, "Exploring multiple execution paths for malware analysis," in Proc. of the IEEE Symposium on Security and Privacy, 2007.
[22] T. Newsham, "Format string attacks," Guardent, Inc., Tech. Rep., 2000.
[23] J. Newsome and D. Song, "Dynamic taint analysis for automatic detection, analysis, and signature generation of exploits on commodity software," in Proc. of the Network and Distributed System Security Symposium, Feb. 2005.
[24] E. J. Schwartz, T. Avgerinos, and D. Brumley, "All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask)," in Proc. of the IEEE Symposium on Security and Privacy, May 2010, pp. 317–331.
[25] E. J. Schwartz, T. Avgerinos, and D. Brumley, "Q: Exploit hardening made easy," in Proc. of the USENIX Security Symposium, 2011.
[26] K. Sen, D. Marinov, and G. Agha, "CUTE: A concolic unit testing engine for C," in Proc. of the ACM Symposium on the Foundations of Software Engineering, 2005.
[27] A. V. Thakur, J. Lim, A. Lal, A. Burton, E. Driscoll, M. Elder, T. Andersen, and T. W. Reps, "Directed proof generation for machine code," in CAV, 2010, pp. 288–305.
[28] G. C. Vitaly Chipounov, Volodymyr Kuznetsov, "S2E: A platform for in-vivo multi-path analysis of software systems," in Proc. of the International Conference on Architectural Support for Programming Languages and Operating Systems, 2011, pp. 265–278.

Где кванты и ИИ становятся искусством?

На перекрестке науки и фантазии — наш канал

Подписаться