В нашем посте, посвященном усовершенствованиям ASLR в последних версиях Windows, приводилась таблица со списком уязвимостей Remote Code Execution, которые использовали атакующие для удаленной установки вредоносного кода в систему (drive-by download). Более половины из этих уязвимостей относятся к типу т. н. use-after-free (UAF). UAF можно охарактеризовать как удобный для атакующих способ передачи управления на свой код. В такой схеме легитимный исполняемый код, например, браузера Internet Explorer, должен содержать неправильную логику работы с памятью, которая заключается в том, что на каком-то этапе фрагмент кода обращается по указателю на тот блок памяти кучи, который уже был освобожден ранее.
Очевидно, что такая ошибка при работе с памятью может просто вызвать аварийное завершение браузера, поскольку произойдет обращение по недействительному указателю. Однако, в случае с эксплойтом, атакующие используют ее в своих целях таким образом, чтобы заставить уязвимый код передать управление по нужному адресу. Как правило, для этого используется heap-spray, что способствует резервированию большого количества блоков памяти по предсказуемому адресу в куче с заполнением их необходимыми злоумышленнику инструкциями. В июньском и июльском куммулятивных обновлениях для браузера Internet Explorer 11 Microsoft ввела дополнительные технологии смягчения эксплуатации в виде изолированной кучи при выделении памяти для объектов и отложенного высвобождения блоков памяти. Такой подход обезопасит код браузера, который все еще может содержать ошибки при работе с памятью, от действий эксплойтов.
Обычно логика работы с памятью кучи выглядит следующим образом:
1) браузер выделяет блок памяти в куче;
2) использует его;
3) высвобождает.
В случае бага в коде, работа с памятью может иметь вид:
1) браузер выделяет блок памяти в куче;
2) использует его;
3) высвобождает;
4) повторно обращается к этому блоку по сохраненному в переменной указателю (напр., через vtable).
Самый общий макет эксплуатации может выглядеть следующим образом:
1) браузер выделяет блок памяти в куче;
2) использует его;
3) высвобождает;
4) пользователь посещает веб-страницу с эксплойтом;
5) эксплойт выполняет spray кучи (для обхода ASLR) и заполняет блоки необходимым кодом (например, шелл-код) или адресами памяти (для срабатывания уязвимости);
6) эксплойт создает условия для ситуации обращения кода браузера по недействительному указателю, который уже действителен, так как пункт 4;
7) браузер повторно обращается по указателю и передает управление на блок памяти с несанкционированным кодом (перед этим выполнив гаджеты эксплойта, которые отключают DEP для блоков кучи через ntdll!NtProtectVirtualMemory).
В такой ситуации для предохранения уязвимого кода от эксплуатации, может использоваться отдельная куча памяти и отложенное высвобождение памяти из нее. Так как блок памяти будет освобожден позднее, злоумышленники не смогут повторно зарезервировать этот адрес. Такой механизм и был введен Microsoft.
Рис. Выделение памяти в изолированной куче методом CMarkup::CreateInitialMarkup для инициализации объекта CMarkup, см. Microsoft Internet Explorer CMarkup Use-After-Free Remote Code Execution Vulnerability. До MS14-035 выделение производилось из общей кучи памяти процесса.
Рис. Июльский MS14-037 ввел отложенное высвобождение блоков памяти методом MemoryProtection::CMemoryProtector::ProtectedFree, который не выполняет фактического высвобождения блока, а просто помечает необходимые заметки о нем в системной структуре данных.
Рис. Методы, которые отвечают за реализацию логики отложенного высвобождения памяти.
Рис. Метод MemoryProtection::CMemoryProtector::ProtectedFree вводит отложенное высвобождение блоков памяти изолированной кучи _g_hIsolatedHeap и самой кучи процесса _g_hProcessHeap.
Рис. Отложенное освобождение памяти также используется классом CTreeNode, см. предыдущую эксплуатацию use-after-free CVE-2013-3893.
Таким образом, при работе на up-to-date версии Windows 8.1 x64 с браузером Internet Explorer 11 пользователь имеет необходимые возможности для предотвращения эксплуатации 0day уязвимостей.
be secure.
Автор: esetnod32
