Изпечатай

[jonythewalker]

абе не ти тряя да знаеш

тва дето го разучавам е умряла кауза ... 

[gat3way]

Нищо, кажи все пак - може да се окаже че не е умряла кауза

[jonythewalker]

пиша реферат за remote buffer overflow
и ако има dep + asrl става много много трудно ... (не невъзможно ама е страшно трудно)

[b2l]

пиша реферат за remote buffer overflow
и ако има dep + asrl става много много трудно ... (не невъзможно ама е страшно трудно)

gat3way - аз ти казах - хахор...

[gat3way]

Това, което в уиндоус се нарича DEP, също съществува в линукс, при 64-битовите системи и 32-битовите с PAE (иначе няма хардуерна подръжка). Емулира се с пачове от сорта на PaX на такива системи, на цената на кофти производителност. В линукс има и други security мерки, които да сговнят живота на писачите на buffer overflow експлойти, примерно stack canaries, -DFORTIFY_SOURCE и т.н.

[jonythewalker]

хмм добре linux не поддържа ли nx flag ?
и ще кажеш ли кои са тези security мерки  ...

[gat3way]

Мисля, че в горния пост вече го казах

[jonythewalker]

ужассс ... хардуерния деп (nx флаг е мноо сериозна защита) ... жалко че не се ползва в linux ... 

[gat3way]

Хардуерният DEP се подържа отдавна в линукс, май не четеш

Чак ужасна защита не е, защото ако беше само това, може лесно да се счупи с return-into-libc атаки и подобни изпълнения където кодът се намира в мапнати, executable страници от паметта. В комбинация с ASLR обаче става много по-грозно, защото не можеш да предвидиш къде ще се намира въпросния код. Stack overflow проблемите се затрудняват заради canary values, които се слагат в края на стека и трябва да съвпадат, format string експлойтите са относително невъзможни, когато програмата е компилирана с -DFORTIFY_SOURCE=2, защото определени формат низове не могат да се намират в стека, в последните години в общи линии се експлойтват доста по-сложни за чупене неща.

[jonythewalker]

да ... nx flag се bypass-ва с ROT, самоче като не могат да определят адресите на иснтрукциите в паметта става много сложно ...
бтв системните колове (и апи функциите на уидноус ) нямат ли фиксирани адреси ?

[gat3way]

Не, нямат. Причината е че викането на syscall-а не представлява call-ване на някаква функция или jump-ване на някакъв адрес. Викането на syscall-а представлява вдигане на едно прекъсване (int 80h в линукс), което се обслужва от ядрото и в зависимост от стойностите на определени регистри, се върши каквото трябва. При AMD64 е малко по различно, защото има специална инструкция за това (SYSCALL), но тя върши на практика същото. Предполагам в уиндоус е същата работа. Как точно минава цялата работа и как прекъсването се обслужва от същият контекст, без context switch е малко дълго за обяснение - но на практика част от адресното пространство на процеса е запазено за kernelspace и се ползва от ядрото. Всякакъв опит да четеш/пишеш/изпълняваш код оттам ще завърши доста...мммм...неуспешно.

[jonythewalker]

ти си бил голям мастер бе

не разбрах следното
"но на практика част от адресното пространство на процеса е запазено за kernelspace и се ползва от ядрото. Всякакъв опит да четеш/пишеш/изпълняваш код оттам ще завърши доста...мммм...неуспешно."

може ли да обясниш по-подробно плс

[gat3way]

Добре, ей така изглежда адресното пространство на който и да било процес при 32-битови x86 системи:



Горният 1 гигабайт се ползва само и единствено от ядрото. Паметта е адресируема, но нито можеш да четеш, нито да пишеш, нито да изпълняваш оттам. Тази "забрана" се постига доколкото знам чрез определен бит в page таблиците, но не съм 100% сигурен в последното. Това има недостатъци разбира се (само 3 гигабайта адресируема памет при 32-битови архитектури), както и предимства (прехвърлянето в kernel mode става без context switch-ване, което е скъпа операция - запазват/възтановяват се стойности на регистри и се чисти процесорния кеш).

[jonythewalker]

значи това е карта на паметта само за 1 процес ?
и какво точно има в този kernel space ?
Щом не може да го изпъняваме за какво ни е това кернел прострнство ?
бтв ... до колко си спомням в unix за да се ползва системни фунцции се извършва обръщение към ядрото, а в уиндовс част от кода на функциите се копират в самото приложение (така сам го учил, но не сам сигурен дали е така ) уникс било по бавно, но по сгурно, а при уиндовс било по бързо ама имало достъп до "ядрен" код

хммм ... кажи кво да им пиша в реферата като заключение - експйтват ли се още линукс/виндовс станции или това е много рядко явление

[gat3way]

В това kernel-ско пространство има памет, използвана от ядрото - код и данни. Причината да не можеш да четеш тези данни и да изпълняваш този код директно, мисля е очевидна Ако можеше - целият security модел просто се обезсмисля, програмите ще имат директен достъп до хардуера (или поне този дето използва memory-mapped I/O), съдържанието на дискови блокове ще е достъпно, а те може да съдържат файлове, за които нямаш позволение, ще имаш достъп до мрежов трафик дето не е за тебе и тем подобни много лоши неща. Ако можеше и да пишеш в този регион от паметта, на практика писането на локални експлойти щеше да е доста лесно.

Но това не е правено със секюрити идея така или иначе, такава система би била ужасно нестабилна (представи си бъг в някоя програма да доведе до срив в цялата система, щото хванала и презаписала kernel-ската памет с глупости).