(решено)Случайный фактор при формировании стека процесса (просто засада какая-то)

Женя Подсыпальников · 23.06.2009 10:39

А тута - почему-та, гутарят за некий "финальный" адрес во стэке...

When program invoked stack has following layout:
argc <- stack pointer
argv[0]
argv[1]
...
argv[argc-1]
0
envp[0]
envp[1]
...
envp[n]
0
auxv[0]
auxv[1]
...
auxv[n], with auxv[n].a_type = AT_NULL
argv0 - NULL-terminated string, pointed by argv[0]
argv1 - NULL-terminated string, pointed by argv[1]
...
argv-last - NULL-terminated string, pointed by argv[argc-1]
env0 - NULL-terminated string, pointed by envp[0]
env1 - NULL-terminated string, pointed by envp[1]
...
envn - NULL-terminated string, pointed by envp[n]
argv0 - once more time - filename of the program, NULL-terminated.
0 - final dword of 0 <- address 0xBFFFFFFF

korisk · Сообщение **korisk** » 23.06.2009 19:56

Женя Подсыпальников писал(а): ↑
23.06.2009 10:39
А тута - почему-та, гутарят за некий "финальный" адрес во стэке...

Все правильно гутарят.
Вот что я нашёл:
http://www.gelato.unsw.edu.au/IA64wiki/AuxiliaryVector
http://manugarg.googlepages.com/aboutelfauxiliaryvectors
http://www.phrack.org/issues.html?issue=58&id=5#article
http://sources.redhat.com/ml/libc-alpha/20...6/msg00108.html
Но причины откуда берется случайная длина, пока не добрился

Кстати, следующая версия

Код:

#include <stdio.h>
#include <elf.h>

main(int argc, char* argv[], char* envp[]){
        Elf32_auxv_t *auxv;
        while(*envp++ != NULL); /*from stack diagram above: *envp = NULL marks end of envp*/

        for (auxv = (Elf32_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++)
        /* auxv->a_type = AT_NULL marks the end of auxv */
        {
                        printf("addr: %x type: %x is: 0x%x\n", (int)auxv, auxv->a_type, auxv->a_un.a_val);
        }
        printf("\n (int)argv[0] - addr = %x - %x = %x\n",(int)argv[], (int)auxv, (int)argv[0] - (int)auxv);
}

korisk · Сообщение **korisk** » 24.06.2009 00:10

Полез, все-таки в код, нашёл какой-то рандомизатор( может и не тот )
Но глубже копать лень.

./linux/fs/binfmt_elf.c:
542 static unsigned long randomize_stack_top(unsigned long stack_top)

Действительно, наверное, эта шутка для защиты предназанчена, от чего, я так и не понял.
Вобщем, спасибо всем за внимание и посты.

aLexx programmer · Сообщение **aLexx programmer** » 24.06.2009 00:18

korisk писал(а): ↑
24.06.2009 00:10
Действительно, наверное, эта шутка для защиты предназанчена, от чего, я так и не понял.

Здравый смысл подсказывает, что от переполнения стека и выполнения после этого произвольного кода.

drBatty · Сообщение **drBatty** » 24.06.2009 00:40

NickLion писал(а): ↑
22.06.2009 10:23
Это в gcc, а вообще, там неразбериха из-за того, что стандартом четко ничего не оговорено.

откуда табличка?
откуда вам знать, что у меня?

NickLion писал(а): ↑
22.06.2009 10:23
Да никто не спорит, но неужели Вы пишете код, который учитывает, что short int не обязательно 16-битный тип? Это все можно, я понимаю, но не излишне ли? На сегодня если аппаратура с регистрами не кратными 2 и есть, то это какая-то встраиваемая техника.

может через 5 лет short станет 32х битным?

Женя Подсыпальников · 24.06.2009 09:44

korisk писал(а): ↑
24.06.2009 00:10
Действительно, наверное, эта шутка для защиты предназанчена, от чего, я так и не понял.

А туты -
студент гутарит за gcc 3.x , защищённый супротив "эксплойтинга", мол, компилятор...

Дак он даже на местный в некоторой функции буфер - по разному даёт, оказывается...

NickLion · Сообщение **NickLion** » 24.06.2009 10:00

drBatty писал(а): ↑
24.06.2009 00:40
откуда табличка?

Да проверить можно

drBatty писал(а): ↑
24.06.2009 00:40
откуда вам знать, что у меня?

А я и не знаю, поэтому уточнил, что это верно для gcc. (И M$ компилера вроде тоже)

drBatty писал(а): ↑
24.06.2009 00:40
может через 5 лет short станет 32х битным?

не станет, в стандарте оговорено:
sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)
А от 16 битного типа не станут отказываться

korisk · Сообщение **korisk** » 24.06.2009 19:10

Женя Подсыпальников писал(а): ↑
24.06.2009 09:44
korisk писал(а): ↑
24.06.2009 00:10
Действительно, наверное, эта шутка для защиты предназанчена, от чего, я так и не понял.

А туты -
студент гутарит за gcc 3.x , защищённый супротив "эксплойтинга", мол, компилятор...

Дак он даже на местный в некоторой функции буфер - по разному даёт, оказывается...

спасибо, конечно, но я по немецки не очень

комплятор всякие stackguard пользует, но они вроде бы фиксированного размера и могут применяться к любой функции, а не только к main.
но суть не в этом

-
ларчик просто открывался:
sysctl -w kernel.randomize_va_space=0
принуждает ядро не добавлять элемент случайной длины в стек нового процесса

Тему можно закрывать.

drBatty · Сообщение **drBatty** » 24.06.2009 20:04

NickLion писал(а): ↑
24.06.2009 10:00
Да проверить можно

всё верно, но я всё-таки не стану на эту табличку полагаться...

NickLion писал(а): ↑
24.06.2009 10:00
А я и не знаю, поэтому уточнил, что это верно для gcc.

ну для сегодняшнего может и верно, и то, для i86, а в общем случае может быть и не всегда...

korisk писал(а): ↑
24.06.2009 19:10
sysctl -w kernel.randomize_va_space=0
принуждает ядро не добавлять элемент случайной длины в стек нового процесса smile.gif

спасибо. об этом и не знал

unixforum.org

(решено)Случайный фактор при формировании стека процесса (просто засада какая-то)

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса

Re: (решено)Случайный фактор при формировании стека процесса