Black_mirror
у меня к тебе несколько вопросов..
1.Ты сам проверял работоспособность _своего_ предложенного метода?
2.На какой системе ты тестируешь? у меня на linux-boxe адрес
возврата из bob() в main() находится в стеке по %6$n.
3.Обьем в 1.5 Гб, за какое приблизительно время будет обсчитан?
я даже затрудняюсь ответить, т.к. на моём домашнем P4-2Ghz
ширина поля вывода ~131Mb обсчитывалась на данной программе
около 40 минут.
4.Мог бы ты привести пример строки формата, по данному алгоритму,
хотя бы для своего случая? т.к. я могу утверждать, что на 90%
этот алгоритм не рабочий(без обид).
5.Шеллкод, который ты используеш для эксплойтинга, содержит
fork()?

PS: я нашел способ эксплойтинга данной уязвимости за ~1-3
секунды в зависимости от скорости процессора, без вывода
громадных обьемов информации.

intuit
1. Что адрес возврата затирается, это я проверил.
2. Тестировал на FreeBSD версии 4.2(или 4.6?). gcc там выравнивает стек при передаче параметров на 16 байт. Причем при резервировании места для переменных иногда лишних 16 байт берёт(и здесь он тоже выравнивает). По-этому и %10$n.
3. Что касается ширины поля вывода, то она составляется около 256Мб(но выводится оно будет 6 раз), потому что код программы вместе с массивами распологается тоже где-то в этом районе. Выводится такое поле где-то за минуту, и при этом, символы fprintf считает правильно.
4. А что касается самой строки то я могу сказать как она должна выглядеть, на 6-ой итерации до конца цикла в функции bob, но вот ксорить ее у меня нет никакого желания. 5. Тем более что для юниксов, я программ не писал и условие задачи не совсем понял. Но метод этот по моему должен работать. (Узнать бы еще как в юниксе вводить символы по их коду).

Black_mirror wrote:
> ...и при этом, символы fprintf считает правильно.

это самое главное :)

> Узнать бы еще как в юниксе вводить символы по их коду

Кидаем в файл:
[user@localhost vuln]$ printf "\x12\x34\xab\xcd\" > file

далее:
[user@localhost vuln]$ cat file | ./a.out

или если тестируешь в gdb перед запуском(run,r):
set args < file
r

ЗЫ:
Очень хотелось бы, чтобы ты проверил свой вариант у себя
на системе.

Что-то меня сглючило. %11$n никакой адрес позврата не перезапишет, так как нам нужен адрес адреса возврата, а в стеке его нет 8(

Ячейки, адреса которых есть в стеке на момент вызова fprintf и которые можно перезаписать:

BFBFFC68
BFBFFC60 - эти ячейки не интересны, так как находятся
BFBFFC58 выше пареметров функции main

BFBFFC0C - ebp функции main
BFBFFB98 - а это гдето в области локальных переменных функции fprintf, но перезапись этой ячейки на работу программы никак не влияет.

Вобщем будем думать дальше ...

Black_mirror
могу дать небольшую подсказку ;)
среди адресов которые я использовал для решения задачи был
адрес 0xBFBFFC68(у меня на boxe 0xBFFFFC68) и одну из
разновидностей спецификатора %n, которая _очень_ редко
встречается(по крайней мере я использовал её первый раз
только здесь).

Что-то я не представляю что за разновидность спецификатора такая 8(
Вижу только одно решение, которое будет работать только для фиксированных адресов, и выводится при этом будут гигабайты, а перезаписать адрес возврата из fprintf получется только при втором вызове функции bob 8((((

моё решение отчасти тоже завязано на фиксированных адресах в
стеке, но оно очень легко модифицируется под конкретную систему
при взгляде на стек после отработки функции fprintf в bob().
На stdout при этом выводится не более ~293Кб мусора.

одну из разновидностей спецификатора %n

Это что за хрень? Ты %p имеешь в виду или какую-то довеску к %n?

volodya
если можно так сказать, то "довеску" к %n.

Да уж лучше звучит, чем "одну из разновидностей спецификатора". У мя на этой фразе вообще крышу набекрень сдвинуло. СПЕЦИФИКАТОР-то всего ОДИН! В твоем случае - это %n. А уж формат длины, флаги, точность - ты об этом?

volodya wrote:
>У мя на этой фразе вообще крышу набекрень сдвинуло.
гы-гы.
>А уж формат длины, флаги, точность - ты об этом?
да, об этом..
сорри, что не так выразился..

если интересно, я описАл один из методов использования
данной уязвимости в небольшой статье.
см.тут

Вот это: http://rootshell.be/~intuit/core.txt
кажется смутно знакомым :)

volodya
не спорю :)
спасибо за этот тест.
взял отсюда с форума. да бы сохранить "в веках", в назидание
потомкам.

у кого-нибудь открывается bffffab0.info?