Преди няколко дни бе разкрита уязвимост това беше идентифицирано в офисния пакет на Apache OpenOffice, този бъг, изброен под CVE-2021 33035- позволява изпълнение на код при отваряне на специално създаден файл във формат DBF.
Проблемът това е така, защото OpenOffice разчита на стойности fieldLength и fieldType в заглавката на DBF файловете, за да разпределите памет, без да проверявате действителния тип данни в полетата.
Относно уязвимостта
За да извършите атака, можете да посочите тип INTEGER в стойността на fieldType, но да поставите по -големи данни и посочете стойността fieldLength, която не съответства на размера на данните INTEGER, което ще доведе до факта, че данните за опашката на полето ще бъдат изписани от разпределения буфер.
В резултат на контролирано препълване на буфер, изследователят успя да предефинира връщащия показалец на функцията и използвайки техниките за ROP (Return Oriented Programming), да постигне изпълнението на своя код.
Един съвет, който получих в началото на изследването за уязвимости, беше да се съсредоточа върху файлов формат, а не върху конкретна част от софтуера. Има две основни предимства на този подход. Първо, като начинаещ, нямате опит за бързо идентифициране на уникални вектори на атака в отделни приложения, докато анализът на файловия формат има тенденция да бъде обща входна точка сред много приложения.
Освен това, общите файлови формати са добре документирани с помощта на заявки за коментари (RFCs) или код с отворен код, намалявайки размера на усилията, необходими за обратното проектиране на формата..
Когато използва техниката ROP, нападателят не се опитва да постави кода си в паметта, а по -скоро който действа върху частите на машинни инструкции, които вече са налични в заредените библиотеки, завършващ с оператор връщане на контрола (като правило това е краят на библиотеката с функции).
Работата на експлоита се свежда до изграждане на верига от обаждания към подобни блокове („джаджи“) за да получите необходимата функционалност.
Като джаджи в експлоита за OpenOffice се споменава, че е използван кодът от библиотеката libxml2, използвана в OpenOffice, която за разлика от OpenOffice се оказа сглобена без DEP (Data Execution Prevention) и ASLR (Address Space) механизми за защита. Рандомизация на оформлението).
Разработчиците на OpenOffice бяха уведомени за проблема на 4 май, след което публично разкриване на уязвимостта беше насрочено за 30 август.
Тъй като стабилният клон не е актуализиран на датата планирано иРазследващият отложи публикуването на подробности за 18 септември, но разработчиците на OpenOffice по това време нямаха време да създадат версия 4.1.11. Трябва да се отбележи, че в хода на същото проучване подобна уязвимост беше разкрита в кода в подкрепа на DBF формата в Microsoft Office Access (CVE-2021-38646), подробностите за който ще бъдат разкрити по-късно. В LibreOffice не са открити проблеми.
Документацията за файловия формат за dBase беше сравнително лесна за откриване; Уикипедия има просто описание на версия 5 на формата, а dBase LLC предоставя и актуализирана спецификация. Библиотеката на Конгреса изброява невероятен каталог с файлови формати, включително DBF. Различните версии и разширения на DBF формата предоставят широки възможности за програмистите да въведат уязвимости при сканиране.
Форматът DBF се състои от два основни раздела: заглавката и тялото. Заглавката включва префикс, който описва версията на базата данни dBase, времевата марка за последната актуализация и други метаданни. По -важното е, че той определя дължината на всеки запис в базата данни, дължината на структурата на заглавката, броя на записите и полетата с данни в запис.
Изследователят, който идентифицира проблема предупреди за създаване на функционален експлойт за платформата Windows. Поправката за уязвимостта е достъпна само като кръпка в хранилището на проекта, която е включена в тестовите компилации на OpenOffice 4.1.11.
И накрая, ако се интересувате да научите повече за него, можете да се консултирате с оригиналната бележка на адрес следната връзка.