Вразливість MS14-063 у драйвері FastFat в ОС Windows. Розбір польотів

В даному дослідженні проведемо аналіз вразливості MS14-063, пов'язаної з некоректною роботою драйвера fastfat.sys і привідного (принаймні, за словами Microsoft) до несанкціонованого підвищення привілеїв. Даної уразливості до недавнього часу були схильні Win Server 2003/2008 і Win Vista (Win7 ця діра була виправлена давним давно, до речі кажучи, але це вже зовсім інша історія — про це докладніше розповідається в статті на ресурсі xakep.ru). Тут же ми поговоримо про те, які можливості могла насправді надати дана уразливість зловмиснику, який вирішив реализоващью атаку типу BadUSB.

Отже, почнемо з короткого опису пристрою файлової системи FAT — роботу з якої як раз реалізує уразливий драйвер fastfat.sys. Детальну документацію можна побачити в специфікації (посилання). Ми ж зупинимося лише на нас цікавлять положеннях.

image
Ілюстрація побудови файлової системи FAT, взята з ресурсу c-jump.com посилання)

На початку томи (по нульового зсуву) знаходиться так званий Boot Sector (насправді BIOS Parameter Block, або, скорочено, BPB). Це структура, що описує загальне пристрій тома і необхідна для того, щоб тому було правильно оброблений драйвером. У цій структурі безліч корисних полів, і до деяких з них ми ще повернемося. Головне, що зараз варто відзначити — це те, що ми говоримо саме про файловій системі Fat32, т. к. в інших реалізаціях FAT зміщення в BPB будуть іншими, причому не тільки вони.

Далі, за BPB, слід сама FAT — структура (FAT Data Structure), по суті своїй, є однозв'язний списком кластерів файлу (весь диск розбитий на кластери (причому файл може займати тільки кластер цілком, навіть якщо не повністю), розмір яких визначається при форматуванні диска — в свою чергу, кластери розбиті на сектори)

image
Ілюстрація пристрої області зберігання інформації (Data Area) на диску, взята з ресурсу technet.microsoft.com посилання)

На даному етапі необхідно згадати про BPB, а точніше звернути увагу на полі NumFats. Згідно специфікації, це поле визначає кількість копій FAT — структури для кожного файлу. У тієї ж специфікації стверджується, що стандартне значення (яке, відповідно, гарантує сумісність ФС з різними драйверами) для даного поля це 2, тобто для кожного файлу існує 2 копії FAT-структури — це необхідно для запобігання втрати файлу у разі появи bad sector'ів. Саме в обробці цього поля і криється вразливість. У разі, коли numfat > 2 відбувається умовний перехід на ділянку коду, невірно виділяє пам'ять в kernel pool (т. к. код виповнюється всередині драйвера).

image
Ілюстрація ділянки уразливого коду функції FatCommonWrite драйвера fastfat.sys, взята з ресурсу blog.beyondtrust.com — блогу фахівців з компанії BeyondTrust, також досліджували дану уразливість (посилання)

Уразливість знаходиться у функції FatCommonWrite, а точніше у виклику ExAllocatePoolWithTag, де в якості аргументу — необхідного місця передається значення numfat — кількість копій структур IoRuns, не помножене на їх розмір. В коді, наведеному на ілюстрації, в регістрі ecx знаходиться вказівник на структуру BPB, а по зсуву 96h від нього знаходиться поле NumFats, яке, як видно з ілюстрації, потрапляє на стек в якості аргументу NumberOfBytes у функції ExAllocatePoolWithTag (до речі кажучи, в якості патча, випущеного від Microsoft, є як раз додавання відсутнього множення в блоці, наведеному на ілюстрації).

На даному етапі варто детальніше поговорити про пристрої пам'яті драйверів (дуже хороший розбір даного класу вразливостей є на хабре — посилання). Резюмуючи її, маємо: пам'ять драйверів розбита на Pool'и, кожен з яких є списком Chunk'ів, в яких, відповідно лежить необхідна драйверу інформація.

Таким чином, тут має місце вразливість типу kernel pool overflow в ділянці пам'яті, і, як наслідок, існує можливість її експлуатації посредеством перебиття chunk'а пам'яті іншого драйвера, що лежить в пам'яті відразу за переполняемым chunk'ом.

image
Ілюстрація процесу переповнення chunk'а, взята статті на хабре про Kernel Pool Overflow (посилання)

На даному етапі ми вже домоглися деякого результату — ми корраптим пам'ять іншого драйвера, що призводить до BSOD'у з помилкою Bad Pool Header. Але цього мало, т. к. Memory Corruption це ще далеко не підвищення привілеїв.

Нашою метою є зміна header'а атакується (лежачого відразу за переполняемым) чанка на коректний, але не дійсний, а довільний (з метою захоплення потоку пам'яті драйвера). Це потенційно призведе до того, що у атакуючого буде можливість виконати код від імені драйвера, тобто з підвищенням привілеїв. Однак, як показав аналіз даних, якими ми переповнюючи chunk, такої можливості в даній ситуації немає. Для обґрунтування цього розглянемо структуру IoRuns, для якої якраз і виділяється пам'ять в вразливою функції. Імовірно (знову ж таки виходячи з вихідних Windows 2000), структура IoRuns служить інструментом, використовуваним при запису FAT-структур у файлову систему (оскільки функція FatCommonWrite викликає якраз при записі файлів на диск, тобто створення/зміна FAT-структур). Сенс в тому, що всі копії (їх кількість регламентується полем NumFats в BPB) записуються асинхронно, для цього кожній копії ставиться у відповідність свій примірник IoRuns, в якому вказано, за яким оффсету писати(поля Vbo і Lbo) і скільки писати (ByteCount).

image
Ілюстрація циклу ініціалізації структур IoRuns (згідно з исходниками WDK 8.0 Samples )

Таким чином, значення в полях структур IoRuns не так просто підмінити, причому всі інші структури будуть залежати, а вірніше, однозначно обчислюватися, із значень полів першої структури. Що ми маємо: перше поле — зміщення, за яким починається запис копій FAT-структур, друге поле — зміщення, за якою записується ця копія (відповідно до значення літератора), третє поле — ймовірно, потрібна для обробки додаткового прологу до FAT-структурі. І останнє поле задається безпосередньо з BPB — воно одно полю BPB_BytsPerSec, оскільки кожна копія FAT-структура займає один сектор.

Звідси випливає, що задати такі дані, які перепишуть наступний chunk і залишать його коректним, просто неможливо, т. до. ми контролюємо всього одне ULONG полі, що приводить до висновку про неможливість реалізації підвищення привілеїв.

Підіб'ємо підсумок: дане дослідження призводить до питання, чи мають рацію фахівці з Microsoft, кажучи про те, що MS14-063 дійсно суттєва і може призвести до ескалації привілеїв? Згідно з проведеним аналізом, можливість «нашкодити» у даній уразливості є тільки у виклику BSOD, але говорити про BadUSB і якихось ескалацій говорити не доводиться.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.