Ошибки переполнения буфера извне и изнутри как обобщенный опыт реальных атак — Архив WASM.RU
мы живем в суровом мире. программное обеспечение, окружающее нас, содержит дыры, многие из которых размерами со слона. в дыры лезут хакеры, вирусы и черви, совершающие набеги изо всех концов сети. червям противостоят антивирусы, заплатки, брандмаузеры и другие умные слова, существующие лишь на бумаге и бессильные сдержать размножение червей в реальной жизни. сеть небезопасна – это факт. можно до потери пульса закидывать Билла Гейтса тухлыми яйцами и кремовыми тортами, но ситуация от этого вряд ли измениться.
анализ показывает, что подавляющее большинство червей и хакерских атак основаны на ошибках переполнения буфера, которые носят фундаментальный характер и которых не избежало практически ни одно полновесное приложение. попытка разобраться в этой, на первый взгляд довольно скучной и незатейливой проблеме безопасности, погружает вас в удивительный мир, полный приключений и интриг. захват управления системой путем переполнения буфера – сложная инженерная задача, требующая нетривиального мышления и превосходной экипировки. диверсионный код, заброшенный на выполнение, находится весьма в жестких и агрессивных условиях не обеспечивающих и минимального уровня жизнедеятельности.
если вам нужен путеводитель по стране переполняющихся буферов, снабженный исчерпывающим руководством по выживанию – эта статья для вас!
введение
Чудовищная сложность современных компьютерных систем неизбежно приводит к ошибкам проектирования и реализации, многие из которых позволяют злоумышленнику захватывать контроль над удаленным узлом или делать с ним что-то нехорошее. Такие ошибки называются дырами или уязвимостями (holes и vulnerability соответственно).
Мир дыр чрезвычайно многолик и разнообразен: это и отладочные люки, и слабые механизмы аутентификации, и функционально-избыточная интерпретация пользовательского ввода, и некорректная проверка аргументов и т. д. Классификация дыр чрезвычайно размыта, взаимно противоречива и затруднена (во всяком случае, своего Карла Линнея дыры еще ждут), а методики их поиска и "эксплуатации" не поддаются обобщению и требуют творческого подхода к каждому отдельно взятому случаю. Было бы наивно надеяться, что одна-единственная публикация сможет описать весь этот зоопарк! Давайте лучше сосредоточимся на ошибках переполнения буферов (buffer overflow/overrun) – как на наиболее важном, популярном, перспективном и приоритетном направлении.
Большую часть статьи мы будем витать в бумажных абстракциях теоретических построений и лишь к концу спустимся на ассемблерную землю, обсуждая наиболее актуальные проблемы практических реализаций. Нет, не подумайте! Никто не собирается в сотый раз объяснять, что такое стек, адреса памяти и откуда они растут! Эта публикация рассчитана на хорошо подготовленную читательскую аудиторию, знающую ассемблер и бегло изъясняющуюся на Си/Си++ без словаря. Как происходит переполнение буфера вы, вероятно, уже представляете и теперь хотели бы ознакомится с полным списком возможностей, предоставляемых переполняющимися буферами. Какие цели может преследовать атакующий? По какому принципу происходит отбор наиболее предпочтительных объектов атаки? Ну и т. д…
Другими словами, в данной статье мы будем говорить исключительно о том, что можно сделать с помощью переполнения и лишь в следующих статьях перейдем к вопросу "как именно это сделать".
Описанные приемы работоспособны на большинстве процессорных архитектур и операционных систем (например, UNIX/SPARC). Пусть вас не смущает, что приводимые примеры в основном относятся к Windows NT и производным от нее системам. Просто, в момент написания статьи другой операционной системы не оказалось под рукой.
мясной рулет ошибок переполнения
или попытка классификации (скукота смертная)Согласно "Новому Словарю Хакера" Эрика Раймонда ошибки переполнения буфера это "то, что с неизбежностью происходит при попытке засунуть в буфер больше, чем тот может переварить". На самом деле, это всего лишь частный случай последовательного переполнения при записи. Помимо него существуют индексное переполнение, заключающееся в доступе к произвольной ячейке памяти за концом буфера, где под "доступом" понимаются как операции чтения, так и операции записи.
Переполнение при записи приводит к затиранию, а следовательно, искажению одной или нескольких переменных (включая служебные переменные, внедряемые компилятором, такие, например, как адреса возврата или указатели this), нарушая тем самым нормальный ход выполнения программы и вызывая одно из следующих последствий:
- нет никаких последний
- программа выдает неверные данные или, попросту говоря, делает из чисел винегрет
- программа "вылетает", зависает или аварийно завершается с сообщением об ошибке
- программа изменяет логику своего поведения, выполняя незапланированные действия
Переполнение при чтении менее опасно, т. к. "всего лишь" приводит к потенциальной возможности доступа к конфиденциальным данным (например, паролям или идентификаторам TCP/IP соединения).
Листинг 1 пример последовательно переполнения буфера при записиКод (Text):
Листинг 2 пример индексного переполнения буфера при чтенииКод (Text):
За концом буфера могут находится данные следующих типов: другие буфера, скалярные переменные и указатели или же вовсе может не находится ничего (например, невыделенная страница памяти). Теоретически, за концом буфера может располагаться исполняемый код, но на практике такая ситуация практически никогда не встречается.
Наибольшую угрозу для безопасности системы представляют именно указатели, поскольку они позволяют атакующему осуществлять запись в произвольные ячейки памяти или передавать управление по произвольным адресам, например, на начало самого переполняющегося буфера в котором расположен машинный код, специально подготовленный злоумышленником, и обычно называемый shell-кодом.
Буфера, располагающиеся за концом переполняющегося буфера, могут хранить некоторую конфиденциальную информацию (например, пароли). Раскрытие чужих паролей, равно как и навязывание атакуемой программе своего пароля – вполне типичное поведение для атакующего.
Скалярные переменные могут хранить индексы (и тогда они фактически приравниваются к указателям), флаги, определяющие логику поведения программы (в том числе и отладочные люки, оставленные разработчиком) и прочую информацию.
В зависимости от своего местоположения буфера делаться на три независимые категории: а) локальные буфера, расположенные в стеке и часто называемые автоматическими переменными; б) статичные буфера, расположенные в секции (сегменте) данных; в) динамические буфера, расположенные в куче. Все они имеют свои специфичные особенности переполнения, которые мы обязательно рассмотрим во всех подробностях, но сначала немного пофилософствуем.
неизбежность ошибок переполнения в исторической перспективе
Ошибки переполнения – это фундаментальные программистские ошибки, которые чрезвычайно трудно отслеживать и фундаментальность которых обеспечивается самой природой языка Си – наиболее популярного языка программирования всех времен и народов, – а точнее его низкоуровневым характером взаимодействия с памятью. Поддержка массивов реализована лишь частично и работа с ними требует чрезвычайной аккуратности и внимания со стороны программиста. Средства автоматического контроля выхода за границы отсутствуют, возможность определения количества элементов массива по указателю и не ночевала, строки, завершающиеся нулем, – вообще песня…
Дело даже не в том, что малейшая небрежность и забытая или некорректно реализованная проверка корректности аргументов, приводит к потенциальной уязвимости программы. Корректную проверку аргументов невозможно осуществить в принципе! Рассмотрим функцию, определяющую длину переданной ей строки, и посимвольно читающую эту строку до встречи с завершающим ее нулем. А если завершающего нуля на конце не окажется? Тогда функция вылетит за пределы утвержденного блока памяти и пойдет чесать непаханую целину посторонней оперативной памяти! В лучшем случае это закончится выбросом исключения. В худшем – доступом к конфиденциальным данным. Можно, конечно, передать максимальную длину строкового буфера с отдельным аргументом, но кто поручиться, что она верна? Ведь этот аргумент приходится формировать вручную и, следовательно, он не застрахован от ошибок. Короче говоря, вызываемой функции ничего не остается как закладывается на корректность переданных ей аргументов, а раз так – о каких проверках мы вообще говорим?!
С другой стороны – выделение буфера возможно лишь после вычисления длины принимаемой структуры данных, т. е. должно осуществляется динамически. Это препятствует размещению буферов в стеке, поскольку, стековые буфера имеют фиксированный размер, задаваемый еще на стадии компиляции. Зато стековые буфера автоматически освобождаются при выходе из функции, снимания это бремя с плеч программиста и предотвращая потенциальные проблемы с утечками памяти. Динамические буфера, выделяемые из кучи, намного менее популярны, поскольку их использование уродует структуру программы. Если раньше обработка текущих ошибок сводилась к немедленному return'у, то теперь перед выходом из функции приходится выполнять специальный код, освобождающий все, что программист успел к этому времени понавыделять. Без критикуемого goto (которое само по себе нехилый глюкодром) эта задача решается только глубоко вложенными if'ами, обработчиками структурных исключений, макросами или внешними функциями, что захламляет листинг и служит источником многочисленных и трудноуловимых ошибок.
Многие библиотечные функции (например, gets, sprintf) не имеют никаких средств ограничения длины возвращаемых данных и легко вызывают ошибки переполнения. Руководства по безопасности буквально кишат категорическим запретами на использование последних, рекомендуя их "безопасные" аналоги – fgets и snprintf, явно специфицирующие предельно допустимую длину буфера, передаваемую в специальном аргументе. Помимо неоправданного загромождения листинга посторонними аргументами и естественных проблем с их синхронизацией (при работе со сложными структурами данных, когда один-единственный буфер хранит много всякой всячины, вычисления длины оставшегося "хвоста" становится не такой уж очевидной арифметической задачей и здесь очень легко допустить грубые ошибки), программист сталкивается с необходимостью контроля целостности обрабатываемых данных. Как минимум необходимо убедиться, что данные не были варварски обрезаны и/или усечены, а как максимум – корректно обработать ситуацию с обрезанием. А что мы, собственно, здесь можем сделать? Увеличить буфер и повторно вызывать функцию, чтобы скопировать туда остаток? Не слишком-то элегантное решение, к тому же всегда существует вероятность потерять завершающий нуль на конце.
В Си++ ситуация с переполнением обстоит намного лучше, хотя проблем все равно хватает. Подержка динамических массивов и "прозрачных" текстовых строк наконец-то появилась (и это очень хорошо), но подавляющее большинство реализаций динамических массивов работают крайне медленно, а строки тормозят еще сильнее, поэтому в критических участках кода от них лучше сразу же отказаться. Иначе и быть не может, поскольку, существует только один способ построения динамических массивов переменной длины – представление их содержимого в виде ссылочной структуры (например, двунаправленного списка). Для быстрого доступа к произвольному элементу список нужно индексировать, а саму таблицу индексов где-то хранить. Таким образом, чтение/запись одного-единственненного символа выливается в десятки машинных команд и множество обращений к памяти (а память была, есть и продолжает оставаться самым узким местом, существенно снижающим общую производительность системы).
Даже если компилятор вдруг решит заняться контролем границ массива (одно дополнительное обращение к памяти и три-четыре машинных команды), это не решит проблемы, поскольку при обнаружении переполнения откомпилированная программа не сможет сделать ничего умнее, чем аварийно завершить свое выполнение. Вызов исключения не предлагать, поскольку если программист забудет его обработать (а он наверняка забудет это сделать), мы получим атаку типа отказ в обслуживании. Конечно, это не захват системы, но все равно нехорошо.
Так что ошибки переполнения были, есть и будут! От этого никуда не уйти, и коль скоро мы обречены на длительное сосуществование с последними, будет нелишним познакомиться с ними поближе…
окутанные желтым туманом мифов и легенд
Журналисты, пишущие о компьютерной безопасности, и эксперты по безопасности, зарабатывающие на жизнь установкой этих самых систем безопасности, склоны преувеличивать значимость и могущество атак, основанных на переполнении буфера. Дескать, хакеры буфера гребут лопатой и если не принять адекватных (и весьма дорогостоящих!) защитных мер, ваша информация превратится в пепел.
Все это так (ведь и на улицу лишний раз лучше не выходить – случается, что и балконы падают), но за всю историю существования компьютерной индустрии не насчитывается и десятка случаев широкомасштабного использования переполняющихся буферов для распространения вирусов или атак. Отчасти потому, что атаки настоящих профессионалов происходят бесшумно. Отчасти – потому, что настоящих профессионалов среди современных хакеров практически совсем не осталось…
Наличие одного или нескольких переполняющихся буферов еще ни о чем не говорит и большинство ошибок переполнения не позволяет атакующему продвинуться дальше банального DoS'а. Вот неполный перечень ограничений, с которыми приходится сталкивается червям и хакерам:
- строковые переполняющиеся буфера (а таковых среди них большинство) не позволяют внедрять символ нуля в середину буфера и препятствуют вводу некоторых символов, которые программа интерпретирует особым образом;
- размер переполняющихся буферов обычно оказывается катастрофически мал для вмещения в них даже простейшего загрузчика или затирания сколь ни будь значимых структур данных;
- абсолютный адрес переполняющегося буфера атакующему чаще всего неизвестен, поэтому приходится оперировать относительными адресами, что очень непросто с технической точки зрения;
- адреса системных и библиотечных функций меняются от одной операционной системы к другой – это раз. ни на какие адреса уязвимой программы так же нельзя закладываться, поскольку они непостоянны (особенно это актуально для UNIX-приложений, компилируемых каждым пользователем самостоятельно) – а это два;
- наконец, от атакующего требуется глубокое значение команд процессора, архитектуры операционной системы, особенности различных компиляторов языка, свободное от академических предрассудков мышление, плюс уйма свободного времени для анализа, проектирования и отладки shell-кода.
А теперь для контраста перечислим мифы противоположной стороны – стороны защитников информации, с какой-то детской наивностью свято верящих, что от хакеров можно защититься хотя бы в принципе.
- не существуют никаких надежных методик автоматического (или хотя бы полуавтоматического) поиска переполняющихся буферов, дающих удовлетворительный результат и по-настоящему крупные дыры не обнаруживаются целенаправленным поиском. их открытие – игра слепого случая;
- все разработанные методики борьбы с переполняющимися буферами снижают производительность (под час очень значительно), но не исключают возможность переполнения полностью, хотя и портят атакующему жизнь;
- межсетевые экраны отсекают лишь самых примитивнейших из червей, загружающих свой хвост через отдельное TCP/IP соединение, отследить же передачу данных в контексте уже установленных TCP/IP соединений никакой межсетевой экран не в силах;
Существуют сотни тысяч публикаций, посвященных проблеме переполнения, краткий список которых был приведен в предыдущей статье этого цикла. Среди них есть как уникальные работы, так и откровенный поросячий визг, подогреваемый собственной крутизной (мол, смотрите, я тоже стек сорвал! Ну и что, что в лабораторных условиях?!). Статьи теоретиков от программирования элементарно распознаются замалчиванием проблем, с которыми сразу же сталкиваешься при анализе полновесных приложений и проектировании shell-кодов (по сути своей являющихся высоко-автономными роботами).
Большинство автором ограничивается исключительно вопросами последовательного переполнения автоматических буферов, оттесняя остальные виды переполнений на задний план, в результате чего у многих читателей создается выхолощенное представление о проблеме. На самом деле, мир переполняющихся буферов значительно шире, многограннее и интереснее, в чем мы сейчас и убедимся.
похороненный под грудой распечаток исходного и дизассемблерного кода
Как происходит поиск переполняющихся буферов и как осуществляется проектирование shell-кода? Первым делом выбирается объект нападения, роль которого играет уязвимое приложение. Если вы хотите убедиться в собственной безопасности или атаковать строго определенный узел, вы должны исследовать конкретную версия, конкретного программного пакета, установленного на конкретной машине. Если же вы стремитесь прославиться на весь мир или пытаетесь сконструировать мощное оружие, дающее вам контроль над десятками тысяч, а то и миллионами машин, ваш выбор становится уже не так однозначен.
С одной стороны, это должна быть широко распространенная и по возможности малоисследованная программа, исполняющаяся с наивысшими привилегиями и сидящая на портах, которые не так-то просто закрыть. Разумеется, с точки зрения межсетевого экрана все порты равноценны и ему абсолютно все равно что закрывать. Однако, пользователи сетевых служб и администраторы придерживаются другого мнения. Если от 135-порта, используемого червем Love San, в подавляющем большинстве случаев можно безболезненно отказаться (лично автор этой статьи именно так и поступил), то без услуг того же WEB-сервера обойдешься едва ли.
Чем сложнее и монстроузнее исследуемое приложение, тем больше вероятность обнаружить в нем критическую ошибку. Следует так же обращать внимание и на формат представления обрабатываемых данных. Чаще всего переполняющиеся буфера обнаруживаются в синтаксических анализаторах, выполняющих парсинг текстовых строк, однако, большинство этих ошибок уже давно обнаружено и устранено. Лучше искать переполняющиеся буфера там, где до вас их никто не искал. Народная мудрость утверждает: хочешь что-то хорошо спрятать – положи это на самое видное место. На фоне нашумевших эпидемий Love San'a и Slapper'а с этим трудно не согласиться. Кажется невероятным, что такие очевидные переполнения до последнего времени оставались необнаруженными!
Наличие исходных текстов одновременно желательно и нежелательно. Желательно – потому что они существенно упрощают и ускоряют поиск переполняющихся буферов, а нежелательно… по той же самой причине! Как говориться: больше народу – меньше кислороду. Действительно, трудно рассчитывать найти что-то новое в исходнике, зачитанном всеми до дыр. Отсутствие исходных текстов существенно ограничивает круг исследователей, отсекая многочисленную армию прикладных программистов и еще большую толпу откровенных непрофессионалов. Здесь, в прокуренной атмосфере ассемблерных команд, выживает лишь тот, кто программирует быстрее, чем думает, а думает быстрее, чем говорит. Тот, кто может удержать в голове сотни структур данных, буквально на физическом уровне ощущая их взаимосвязь, и каким-то шестым чувством угадывая в каком направлении нужно копать. Собственный программистский опыт может только приветствоваться. Во-первых, так легче вжиться в привычки, характер и образ мышления разработчика исследуемого приложения. Задумайтесь: а как бы вы решили данную задачу, окажись на его месте? Какие бы могли допустить ошибки? Где бы проявили непростительную небрежность, соблазнившись компактностью кода и элегантностью листинга?
Кстати, об элегантности. Бытует мнение, что неряшливый стиль программного кода неизбежно провоцирует программиста на грубые ошибки (и ошибки переполнения в том числе). Напротив, педантично причесанная программа ошибок скорее всего не содержит и анализировать ее означает напрасно тратить свое время. Как знать… Автору приходилось сталкиваться с вопиюще небрежными листингами, которые работали как часы, потому что были сконструированы настоящими профессионалами, наперед знающими где подстелить соломку, чтобы не упасть. Встречались и по академически аккуратные программы, дотошно и не по одному разу проверяющие все, что только можно проверить, но буквально нашпигованные ошибками переполнения. Тщательность сама по себе еще ни от чего не спасает. Для предотвращения ошибок нужен богатый программистский опыт, – и опыт оставленный граблями в том числе. Но вместе с опытом зачастую появился и вальяжная небрежность – своеобразный "отходяк" от юношеского увлечения эффективностью и оптимизаций.
Признаком откровенного непрофессионализма является пренебрежение #defin'ами или безграмотное использование последних. В частности, если размер буфера buff определяется через MAX_BUF_SIZE, то и размер копируемой в него строки должен ограничиваться им же, а не MAX_STR_SIZE, заданным в отдельном define. Обращайте внимание и на характер аргументов функций, работающих с блоками данных. Передача функции указателя без сообщения размера блока – частая ошибка начинающих, равно как и злоупотребление функциями strcpy/strncpy. Первая – небезопасна (отсутствует возможность ограничить предельно допустимую длину копируемой строки), вторая – ненадежна (отсутствует возможность оповещения о факте "обрезания" хвоста строки, не уместившегося в буфер, что само по себе может служить весьма нехилым источником ошибок).
Хорошо, ошибка переполнения найдена. Что дальше? А дальше только дизассемблер. Не пытайтесь выжать из исходных текстов хоть какую-то дополнительную информацию. Порядок размещения переменных в памяти не определен и практически никогда не совпадает с порядком их объявления в программе. Может оказаться так, что большинства из этих переменных в памяти попросту нет и они размещены компилятором в регистрах, либо же вовсе отброшены оптимизатором как ненужные (Попутно заметим, что все демонстрационные листинги, приведенные в этой статье, рассчитывают, что переменные располагаются в памяти в порядке их объявления).
Впрочем, не будем забегать вперед. Дизассемблирование – это тема для отдельной статьи, которую планируется опубликовать в следующих номерах журнала.
цели и возможности атаки
Конечная цель любой атаки – заставить систему сделать что-то "нехорошее". Такое, что нельзя добиться легальным путем. Существует по меньшей мере четыре различных способа реализации атаки:
- чтение секретных переменных;
- модификация секретных переменных;
- передача управления на секретную функции программы;
- передача управления на код, переданный жертве самим злоумышленником;
Чтение секретных переменных. На роль секретных переменных в первую очередь претендуют пароли на вход в систему, а так же пароли доступа к конфиденциальной информации. Все они так или иначе содержатся в адресном пространстве уязвимого процесса, зачастую располагаясь по фиксированным адресам (под "входом в систему" здесь подразумевается имя пользователя и пароль, обеспечивающие удаленное управление уязвимым приложением).
Еще в адресном пространстве процесса содержатся дескрипторы секретных файлов, сокеты, идентификаторы TCP/IP соединений и многое другое. Разумеется, вне текущего контекста они не имеют никакого смысла, но могут быть использованы кодом, переданном жертве злоумышленником, и осуществляющим, например, установку "невидимого" TCP/IP-соединения, прячась под "крышей" уже существующего.
Ячейки памяти, хранящие указатели на другие ячейки, "секретными" строго говоря не являются, однако, знание их содержимого значительно облегчает атаку. В противном случае атакующему придется определять опорные адреса вслепую. Допустим, в уязвимой программе содержится следующий код: char *p = malloc(MAX_BUF_SIZE); где p – указатель на буфер, содержащий секретный пароль. Допустим так же, что в программе имеется ошибка переполнения, позволяющая злоумышленнику читать содержимое любой ячейки адресного пространства. Весь вопрос в том: как этот буфер найти? Сканировать всю кучу целиком не только долго, но и небезопасно, т. к. можно легко натолкнуться на невыделенную страницу памяти и тогда выполнение процесса аварийно завершиться. Автоматические и статические переменные в этом отношении более предсказуемы. Поэтому, атакующий должен сначала прочитать содержимое указателя p, а уже затем – секретный пароль, на который он указывает. Разумеется, это всего лишь пример, которым возможности переполняющего чтения не ограничиваются.
Само же переполняющее чтение реализуется по меньшей мере четырьмя следующими механизмами: "потерей" завершающего нуля в строковых буферах, модификаций указателей (см. "указатели и индексы"), индексным переполнением (см. там же) и навязываем функции printf (и другим функциям форматированного вывода) лишних спецификаторов.
Модификация секретных переменных. Возможность модификации переменных дает значительно больше возможностей для атаки, позволяя: а) навязывать уязвимой программе "свои" пароли, дескрпиторы файлов, TCP/IP идентификаторы и т. д.; б) модифицировать переменные, управляющие ветвлением программы; в) манипулировать индексами и указателями, передавая управление по произвольному адресу (и адресу, содержащему код, специально подготовленный злоумышленником в том числе).
Чаще всего модификация секретных переменных реализуется посредством последовательного переполнения буфера, по обыкновению своему поражающему целый каскад побочных эффектов. Например, если за концом переполняющегося буфера расположен указатель на некоторую переменную, в которую после переполнения что-то пишется, злоумышленник сможет затереть любую ячейку памяти на свой выбор (за исключением ячеек, явно защищенных от модификации, например кодовой секции или секции .rodata, разумеется).
Передача управления на секретную функцию программы. Модификация указателей на исполняемый код привод к возможности передачи управления на любую функцию уязвимой программы (правда, с передачей аргументов имеются определенные проблемы). Практически каждая программа содержит функции, доступные только root'у, и предоставляющие те или иные управленческие возможности (например, создание новой учетной записи, открытие сессии удаленного управления, запуск файлов и т.д.). В более изощренных случаях управление передается на середину функции (или даже на середину машинной инструкции), с таким расчетом, чтобы процессор выполнил замысел злоумышленника, даже если разработчик программы не предусматривал ничего подобного.
Передача управления обеспечивается либо за счет изменения логики выполнения программы, либо за счет подмены указателей на код. И то, и другое опирается на модификацию ячеек программы, кратно рассмотренную выше.
Передача управления на код, переданный жертве самим злоумышленником является разновидностью механизма передачи управления на секретную функцию программу, только сейчас роль этой функции выполняет код, подготовленный злоумышленником и тем или иным способом переданный на удаленный компьютер. Для этой цели может использоваться как сам переполняющийся буфер, так и любой другой буфер, доступный злоумышленнику для непосредственной модификации и в момент передачи управления на shell-код присутствующий в адресном пространстве уязвимого приложения (при этом он должен располагаться по более или менее предсказуемым адресам, иначе передавать управление будет некому и некуда).
жертвы переполнения или объекты атаки
Переполнение может затирать ячейки памяти следующих типов: указатели, скалярные переменные и буфера. Объекты языка Си++ включают в себя как указатели (указывающие на таблицу виртуальных функций, если таковые в объекте есть), так и скалярные данные-члены (если они есть). Самостоятельной сущности они не образуют и вполне укладываются в приведенную выше классификацию.
указатели и индексы
В классическом Паскале и других "правильных" языках указали отсутствуют, но в Си/Си++ они вездесущи. Чаще всего приходится иметь дело с указателями на данные, несколько реже встречаются указатели на исполняемый код (указатели на виртуальные функции, указатели на функции, загружаемые динамической компоновкой и т. д.). Современный Паскаль (раньше ассоциируемый с компилятором TurboPascal, а теперь еще и DELPHI) также немыслим без указателей. Даже если в явном виде указатели и не поддерживаются, на них держатся динамические структуры данных (куча, разряженные массивы), используемые внутри языка.
Указатели удобны. Они делают программирование простым, наглядным, эффективным и естественным. В то же время указатели во всех отношениях категорически небезопасны. Попав в руки хакера или пищеварительный тракт червя они превращаются в оружие опустошительной мощности, – своеобразный аналог BFG-900 или, по крайней мере, плазмогана. Забегая вперед отметим, что указатели обоих типов потенциально способны к передаче управления на несанкционированный машинный код.
Вот с указателей на исполняемый код мы и начнем. Рассмотрим ситуацию, когда следом за переполняющимся буфером buff, расположен указатель на функцию, которая инициализируется до и вызывается после переполнения буфера (возможно, вызывается не сразу, а спустя некоторое время). Тогда, мы заполучим аналог функции call или говоря, другими словами, инструмент для передачи управления по любому (ну или почти любому) машинному адресу, в том числе и на сам переполняющийся буфер (тогда управление получит код, переданный злоумышленником).
Листинг 3 фрагмент программы, подверженной переполнению с затиранием указателя на исполняемый кодКод (Text):
Подробнее о выборе целевых адресов мы поговорим в другой раз, сейчас же сосредоточимся на поиске затираемых указателей. Первым в голову приходит адрес возврата из функции, находящийся внизу кадра стека. (правда, чтобы до него дотянуться требуется пересечь весь кадр целиком и не факт, что нам это удастся, к тому же его целостность контролируют многие защитные системы, подробнее о которых планируется рассказать в следующей статье).
Другая популярная мишень – указатели на объекты. В Си++ программах обычно присутствует большое количество объектов, многие из которых создаются вызовом оператора new, возвращающим указатель на свежесозданный экземпляр объекта. Невиртуальные функции-члены класса вызываются точно так же, как и обычные Си-функции (т. е. по их фактическому смещению), поэтому они неподвластны атаке. Виртуальные функции-члены вызываются намного более сложным образом, через цепочку следующих операций: указатель на экземпляр объекта à указатель на таблицу виртуальных функций à указатель на конкретную виртуальную функцию. Указатели на таблицу виртуальных функций не принадлежат объекту и внедряются в каждый его экземпляр, который чаще всего сохраняется в оперативной памяти, реже – в регистровых переменных. Указатели на объекты так же размещаются либо в оперативной памяти, либо в регистрах, при этом на один и тот же объект может указывать множество указателей (среди которых могут встретиться и такие, которые расположены непосредственно за концом переполняющегося буфера). Таблица виртуальных функций (далее просто виртуальная таблица) принадлежит не экземпляру объекта, а самому объекту, т. е. упрощенно говоря, мы имеем одну виртуальную таблицу на каждый объект. "Упрощенно" потому, что в действительности виртуальная таблица помещается в каждый obj-файл, в котором встречается обращение к членам данного объекта (раздельная компиляция дает о себе знать). И хотя линкеры в подавляющем большинстве случаев успешно отсеивают лишние виртуальные таблицы, иногда они все-таки дублируются (но это уже слишком высокие материи для начинающих). В зависимости от "характера" выбранной среды разработки и профессионализма программиста виртуальные таблицы размещаются либо в секции .data (не защищенной от записи), либо в секции .rodata (доступной лишь на чтение), причем последний случай встречается значительно чаще.
Давайте для простоты рассмотрим приложения с виртуальными таблицами в секции .data. Если злоумышленнику удастся модифицировать один из элементов виртуальной таблицы, то при вызове соответствующей виртуальной функции управление получит не она, а совсем другой код! Однако, добиться этого будет непросто! Виртуальные таблицы обычно размещаются в самом начале секции данных, т. е. перед статическими буферами и достаточно далеко от автоматических буферов (более конкретное расположение указать невозможно, т. к. в зависимости от операционной системы стек может находится как ниже, так и выше секции данных). Так что последовательное переполнение здесь непригодно и приходится уповать на индексное, все еще остающееся теоретической экзотикой, робко познающий окружающий мир.
Модифицировать указатель на объект и/или указатель на виртуальную таблицу намного проще, поскольку они не только находятся в области памяти, доступной для модификации, но и зачастую располагаются в непосредственной близости от переполняющихся буферов.
Модификация указателя this приводит к подмене виртуальных функций объекта. Достаточно лишь найти в памяти указатель на интересующую нас функцию (или вручную сформировать его в переполняющемся буфере) и установить на него this с таким расчетом, чтобы адрес следующей вызываемой виртуальной функции попал на подложный указатель. С инженерной точки зрения это достаточно сложная операция, поскольку кроме виртуальных функций объекты еще содержат и переменные, которые более или менее активно используют. Переустановка указателя this искажает их "содержимое" и очень может быть, что уязвимая программа рухнет раньше, чем успеет вызвать подложную виртуальную функцию. Можно, конечно, сымитировать весь объект целиком, но не факт, что это удастся. Сказанное относится и к указателю на объект, поскольку с точки зрения компилятора они скорее похожи, чем различны. Однако, наличие двух различных сущностей дает атакующему свободу выбора, – в некоторых случаях предпочтительнее затирать указатель this, в некоторых случаях – указатель на объект.
Листинг 4 фрагмент программы, подверженной последовательному переполнению при записи, с затираем указателя на таблицу виртуальных функцийКод (Text):
Листинг 5 дизассемблерный листинг переполняющийся программы с краткими комментариямиКод (Text):
Рассмотрим ситуацию, когда следом за переполняющимся буфером, идет указатель на скалярную переменную p и сама переменная x, которая в некоторый момент выполнения программы по данному указателю и записывается (порядок чередования двух последних переменных не существенен, главное, чтобы переполняющийся буфер затирал их всех). Допустим так же, что с момента переполнения ни указатель, ни переменная не претерпевают никаких изменений (или изменяются предсказуемым образом). Тогда, в зависимости от состояния ячеек, затирающих оригинальное содержимое переменных x и p, мы сможем записать любое значение x по произвольному адресу p, осуществляя это "руками" уязвимой программы. Другими словами, мы получаем аналог функций POKE и PatchByte/PatchWord языков Бейсик и IDA-Си соответственно. Вообще-то, на выбор аргументов могут быть наложены некоторые ограничения (например, функция gets не допускает символа нуля в середине строки), но это не слишком жесткое условие и имеющихся возможностей вполне достаточно для захвата управления над атакуемой системой.
Листинг 6 фрагмент программы, подверженной последовательному переполнению при записи и затиранием скалярной переменной и указателя на данные, поглощающими затертую переменнуюКод (Text):
Индексы являются своеобразной разновидностью указателей. Грубо говоря, это относительные указатели, адресуемые относительно некоторой базы. Смотрите, p[i] можно представить и как *(p+i), практически полностью уравнивая p и i в правах.
Модификация индексов имеет свои слабые и сильные стороны. Сильные – указатели требуют задания абсолютного адреса целевой ячейки, который обычно неизвестен, в то время как относительный вычисляется на ура. Индексы, хранящиеся в переменных типа char, лишены проблемы нулевых символов. Индексы, хранящихся в переменных типа int, могут беспрепятственно затирать ячейки, расположенные "выше" стартового адреса (т. е. лежащие в младших адресах), при этом старшие байты индекса содержат символы FFh, которые значительно более миролюбивы, чем символы нуля.
Однако, если обнаружить факт искажения указателей практически невозможно (дублировать их значение в резервных переменных не предлагать), то оценить корректность индексов перед их использованием не составляет никакого труда и многие программисты именно так и поступают (правда, "многие" еще не означает "все"). Другой слабой стороной индексов является их ограниченная "дальнобойность", составляющая ±128/256 байт (для индексов типа signed/unsignedchar) и ‑2147483648 байт для индексов типа signedint.
Листинг 7 фрагмент программы, подверженной последовательному переполнению при записи, с затиранием индекса;Код (Text):
скалярные переменные
Скалярные переменные, не являющиеся ни индексами, ни указателями, намного менее интересны для атакующих, поскольку в подавляющем большинстве случаев их возможности очень даже ограничены, однако, на безрыбье сгодятся и они (совместное использование скальных переменных вместе с указателями/индексами мы только что рассмотрели, сейчас же нас интересуют скальные переменные сами по себе).
Рассмотрим случай, когда вслед за переполняющимся буфером расположена переменная buks, инициализируемая до переполнения, а после переполнения используемая для расчетов количества денег, снимаемых со счета (не обязательно счета злоумышленника). Допустим, программа тщательно проверяет входные данные и не допускает использования ввода отрицательных значений, однако, не контролирует целостность самой переменной buks. Тогда, варьируя ее содержимым по своему усмотрению, злоумышленник без труда обойдет все проверки и ограничения.
Листинг 8 фрагмент программы, подверженный переполнению с затираем скалярной переменной.Код (Text):
При всей своей искусственности, приведенный пример чрезвычайно нагляден. Модификация скалярных переменных только в исключительных случаях приводит к захвату управления системой, но легко позволяет делать из чисел винегрет, а на этом уже можно сыграть! Но что же это за исключительные случаи? Во-первых, многие программы содержат отладочные переменные, оставленные разработчиками, и позволяющие, например, отключить систему аутентификации. Во-вторых, существует множество переменных, хранящих начальные или предельно допустимые значения других переменных, например, счетчиков цикла – for (a =b; a < c; a++) *p++ = *x++; очевидно, что модификация переменных b и c приведет к переполнению буфера p со всеми отсюда вытекающими последствиями. В-третьих… да мало ли что можно придумать – всего и не перечислишь! Затирание скалярных переменных при переполнении обычно не приводит к немедленному обрушению программы, поэтому такие ошибки могут долго оставаться не обнаруженными. Будьте внимательными!
массивы и буфера
Что интересного можно обнаружить в буферах? Прежде всего это строки, хранящиеся в PASCAL-формате, т. е. с полем длины вначале, затирание которого порождает каскад вторичных переполнений. Про уязвимость буферов с конфиденциальной информацией мы уже говорили, а теперь, пожалуйста – конкретный, хотя и несколько наигранный пример:
Листинг 9 фрагмент программы, подверженной последовательному переполнению при записи с затиранием постороннего буфераКод (Text):
Еще интересны буфера, содержащие имена открываемых файлов (можно заставить приложение записать конфиденциальные данные в общедоступный файл или, напротив, навязать общедоступный файл взамен конфиденциального), тем более, что несколько подряд идущих буферов вообще говоря не редкость.
заключение
Изначально статья задумывалось как исчерпывающее руководство, снабженное большим количеством листингов и избегающее углубляться в академические теоретизирования. Теперь, вычитывая статью перед заключительной правкой и внося в нее мелкие, косметические улучшения, я с грустью осознаю, что выполнить свой замысел мне так и не удалось… До практических советов разговор вообще не дошел и львиная часть подготовленного материала осталось за кадром. Ох, и не следовало мне пытаться объять необъятное…
Надеюсь, что следующие статьи этого цикла исправят положение. В первую очередь планируется рассказать о передовых методиках переполнения кучи, приводящих к захвату управления удаленной машиной, обсудить технические аспекты разработки shell-кода (приемы создания позиционно-независимого кода, проблема вызова системных функций, оптимизация размера и т. д.), затем будет можно перейти к разговору о способах поиска переполняющихся буферов и о возможных мерах по заблаговременному предотвращению оных. Отдельную статью хотелось бы посвятить целиком червям Love Sun и Slapper, поскольку их дизассемблерные листинги содержат очень много интересного.
© Крис Касперски
Ошибки переполнения буфера извне и изнутри как обобщенный опыт реальных атак
Дата публикации 7 июн 2004
