и малко по темата ...
до колкото знам aslr-а прави следното
randomizes the base addresses of executables, dll’s, stack and heap in a process’s address space (for the Windows OS)
Yep.
и прочетох в една статия следното в статия за linux aslr:
Additionally no code-page of an executable is randomized in the default case.
This
gives a much larger code-base that will be of interest for attackers.
Still though, these
pages are mapped to the lower address half and thus include many
\0 characters, which
cannot be used in most buffer overflow situations. Not randomizing the executable's
pages is a major
flaw that should be fixed.
Това което не хващам е за кои страници става въпрос - за тези които са в контекста на виртуалната организация на паметта (n страници, които формират сегмента с код (според мен даден сегмент се дели на страници и те се местят между хардиска и рама))?
До колкото съм разбрал базовите адреси на сегмента за стек и хийп се рандумизират, а вътре в самия сегмент няма рандумизиация.
Това е интересно, щях да кажа че не е така, но от друга страна сега като тествам, компилирах няколко пъти една и съща програма, main функцията си е на все един и същи адрес. Очевидно .text сегмента си се зарежда на едно и също място, което е интересно. От друга страна, това са страници памет, за които нямаш права да пишеш вътре, така че забрави да презапишеш това което се изпълнява примерно в main(). Вероятно при дадени обстоятелства, може човек да се възползва от това, но ужасно много зависи как е написана програмата и какво прави. После, има различни build-ове на тази програма, използвайки различни флагове на компилатора, това предполагам генерира крайно различен машинен код и писането на reliable експлойт, който да се възползва от това сигурно е мъка.
Всъшност, нагледно:
debian:~/ocltest# cat /proc/self/maps
00400000-0040d000 r-xp 00000000 fe:00 72102 /bin/cat
0060d000-0060e000 rw-p 0000d000 fe:00 72102 /bin/cat
024bd000-024de000 rw-p 00000000 00:00 0 [heap]
....
debian:~/ocltest# cat /proc/self/maps
00400000-0040d000 r-xp 00000000 fe:00 72102 /bin/cat
0060d000-0060e000 rw-p 0000d000 fe:00 72102 /bin/cat
01e07000-01e28000 rw-p 00000000 00:00 0 [heap]
...
Та значи определено .text нещата не се рандомизират.
стек край -- > ----
Стек начало -- > --- <<< Този адрес се рандъмизира, и спрямо него се ранумизират адресите в стека (относителните адреси (отмествания) в стека спре мен са еднакви)
Основният ми въпрос е за кои страници става въпрос в цитата ...
Рандомизира се предполагам края на стека, тъй като той расте наобратно
Съдържанието на стека, хийпа, .text, .rodata и т.н. очевидно няма как да се рандомизират - това би изисквало някакви неземни умения от страна на ядрото, ако искаш програмите да ти вървят коректно.
Между другото, рандомизацията си има някакви граници, особено при 32-битовите адресни пространства. Зъл payload с много голямa NOP последователност преди нея, може да се bruteforce-не и злия код да се изпълни в крайна сметка след н-тия опит. При 64-битови системи обаче, адресното пространство е доста по-голямо и рандомизацията си ходи в доста по-широки граници. Може да не ти стигнат години да нацелиш каквото трябва така.