В програмах, переповнення буфера стеку трапляється, коли програма пише за адресами в програмному стеку виклику поза призначеною структурою даних; це зазвичай буфер фіксованої довжини. Баг переповнення буфера стеку трапляється, коли програма пише більше даних в буфер розміщений в стеку, ніж було фактично виділено місця для буфера. Це майже завжди призводить до псування прилеглих даних в стеку, і в разі якщо переповнення було зроблено помилково, часто призводить до краху програми або некоректної роботи. Цей тип переповнення є одним з випадків загальнішого класу багів програмування, знаних як переповнення буфера.
Якщо атакована програма виконується з спеціальними привілеями, або приймає дані з недовірених хостів мережі (напр. вебсерверів), тоді баг є потенційною вразливістю безпеки. Якщо стековий буфер залитий даними, які надійшли від недовіреного користувача, тоді цей користувач може пошкодити стек в такий спосіб, що в стеку опиняється виконуваний код, інжектований ним, відтак він отримує управління процесом. Це один з найстаріших і найнадійніших методів для зловмисників отримати неавторизований доступ до комп'ютера.
Використання переповнень стекових буферів
Канонічний метод експлуатації переповнення стекового буфера є затирання адреси повернення в функцію, яка викликала (caller) поточну функцію (callee) вказівником на контрольовані хакером дані (зазвичай на той же стек). Це ілюструється в прикладі нижче:
- Приклад з strcpy
#include<string.h> void foo(char* bar){ char c[12]; strcpy(c, bar);// перевірки межі масиву немає... } int main(int argc, char** argv){ foo(argv[1]); return 0; }
Цей код бере аргумент з командного рядка і копіює його в локальну стекову змінну c. Все працює добре для аргументів командного рядка, меншими за 12 символів (як ви можете бачити з малюнка Б нижче). Будь-які аргументи більші за 11 символів в довжину спричинять пошкодження стеку. (Максимальне число символів, що будуть безпечними є на один менше ніж розмір буфера, бо рядки в мові C обмежуються нульовим байтом, який теж треба враховувати. Рядок з дванадцяти однобайтних символів насправді вимагатиме тринадцятибайтного вмістилища. Нульовий байт тоді потре один байт ділянки пам'яті поза кінцем буфера.)
- Програмний стек
foo()
з різними введеннями.
Примітка. На малюнку вказівник char* bar
чомусь лежить поверх адреси повернення і навіть збереженого вказівника на стековий кадр попередньої функції (регістр ebp), але як аргумент функції foo(char*)
мав би бути якраз перед адресою повернення.
На малюнку 'В' вище, коли аргумент взятий з командного рядка - більший за 11 байтів, foo()
(точніше, strcpy(), викликана foo()) затирає локальні дані стеку, збережений вказівник на стековий кадр (ebp
), і що найголовніше, - адресу повернення. Коли foo()
повертається (виконання в ній доходить до інструкції ret
), вона знімає зі стеку адресу повернення, і передає на неї управління (команду ret
можна трактувати як pop eip
). Як ви можете бачити на малюнку 'В' вище, атакер потер адресу повернення вказівником на стековий буфер char c[12], який тепер містить вставлені ним дані. У випадку справжнього експлуатування переповнення стекового буфера, рядок багатьох "А" міг би містити шелкод (shellcode) для цієї платформи і потрібної функції. Якщо програма має особливі привілеї (напр. біт SUID виставлений для виконання на правах суперкористувача), тоді хакер може використати вразливість щоб дістати права суперкористувача на атакованій машині.
Хакер також може модифікувати внутрішні змінні для експлуатації деяких багів. Той же приклад:
#include<stdio.h> #include<string.h> void foo(char* bar){ float MyFloat = 10.5f;// Адреса = 0x0023FF4C char c[12];// Адреса = 0x0023FF30 // Друкуватиме 10.500000 printf("My float value = %f\n",MyFloat); /* --------------------------------------- Карта пам'яти: @: пам'ять виділена c #: пам'ять виділена MyFloat -: інша пам'ять *c*MyFloat 0x0023FF300x0023FF4C || @@@@@@@@@@@@----------------#### foo("My string is too long !!!!! XXXX"); memcpy потре послідовністю байтів 0x10 0x10 0xC0 0x42 значення змінної MyFloat. Як плаваючий тип, ця послідовність є числом 96.0313720703125 (байт 0x42 - старший!) ------------------------------------------ */ memcpy(c,bar,strlen(bar)); // не перевіряється межа масиву... // надрукує 96.031372 printf("My Float value = %f\n", MyFloat); } int main(int argc, char** argv){ foo("my string is too long !!!!! \x10\x10\xC0\x42"); return 0; }
Платформозалежні відмінності
Різні платформи мають тонкі відмінності в своїй реалізації стеку виклику, що може завадити експлуатації переповнення стекового буфера. Деякі машинні архітектури зберігають верхньорівневу адресу повернення стеку виклику в регістрі. Це означає, що будь-яка потерта адреса повернення не використовуватиметься до пізнішого розгортання стеку викликів. Інший приклад машинноспецифічної деталі, яка може завадити використати цю техніку - це факт, що більшість RISC архітектур не дозволяють невирівняний (unaligned) доступ до пам'яті. Тобто, адреси інструкцій мають бути завжди числами, кратними до якогось числа (наприклад - 4). В поєднанні з фіксованою довжиною машинної команди, це машинне обмеження може зробити техніку jump esp
майже неможливою для втілення (за винятком, коли програма дійсно містить малоймовірний код для точного переходу на значення стекового регістра).
Стеки, які ростуть вгору
В темі переповнень стекових буферів, є часто обговорювана архітектура яка рідко зустрічається на практиці, в якій стек росте в протилежному напрямку. Тобто, верх стеку рухається в бік старших адрес, коли стек заповнюється, а не навпаки, як в звичайному стеку. Ця зміна архітектури часто пропонується як рішення проблеми переповнення стекового буфера, бо будь-яке переповнення стекового буфера, яке трапиться всередині того самого стекового кадру, не зможе перетерти вказівник повернення. Подальший розгляд цього заявленого захисту, виявляє що це не відповідає дійсності. Будь-яке переповнення, що трапляється в буфері з попереднього стекового кадру все одно тертиме адресу повернення і дозволятиме шкідливу експлуатацію бага. Наприклад, в коді вгорі, вказівник повернення з foo()
не буде потерто, бо переповнення справді станеться в стековому кадрі strcpy()
. Однак, через те, що буфер, який переповнюється під час виклику strcpy()
міститься в попередньому стековому кадрі, вказівник повернення з strcpy()
матиме старшу адресу пам'яті, ніж у буфера. Це означає, що замість затирання адреси повернення foo()
, тертиметься адреса повернення з strcpy()
. Найбільше, що це означатиме, це те, що зростання стеку в протилежному (до звичного) напрямі, змінить деякі деталі того, як експлуатуватиметься переповнення стекового буфера, але це помітно не зменшить кількості експлуатованих багів.
Схеми захисту
За роки було розроблено чимало схем для перешкоджання експлуатації переповнення стекового буфера. Вони зазвичай мають одну з двох форм. Перший метод - це детектувати переповнення буфера і запобігти передаванню керування на шкідливий код. Другий метод намагається запобігти виконанню шкідливого коду зі стека без прямої детекції переповнення стекового буфера.
Стекові канарки
Стекові канарки - названі так через те, що вони діють як канарки в вугільній шахті - використовуються для детекції переповнення стекового буфера перед тим, як виконання шкідливого коду може трапитися. Цей метод полягає в розміщенні невеликого цілого - величини, яка довільно вибирається на старті програми - в пам'яті, прямо перед стековим вказівником повернення. Найбільше буферних переповнень затирають пам'ять від молодших до старших адрес, тож, під час затирання адреси повернення (і отримання відтак контролю в процесі), величина "канарки" також зітреться. Ця величина перевіряється перед тим як підпроцедура використає адресу повернення на стеку, щоб переконатися, що її не змінено. Ця техніка має ускладнити експлуатування переповнення стекового буфера, бо змушує хакера отримувати контроль над вказівником команд якимись нетрадиційнішими способами, такими як псування інших важливих змінних на стеку.
Невиконуваний стек
Інший підхід до запобігання переповнення стекового буфера полягає в забороні виконання даних зі стекової області пам'яті. Це означає, що для виконання шелкоду зі стеку хакер має або знайти шлях скасувати захист від виконання з цієї області пам'яті, або знайти шлях перенести корисне навантаження свого шелкоду в незахищену (від виконання) область пам'яті. Цей метод стає популярніший зараз, через те, що апаратна підтримка флажка "не виконувати" (no-execute) доступна на більшості десктопних процесорів. Хоча цей метод став фактично традиційним в протидії експлуатації переповнення стекового буфера, хоча й має певні недоліки. По-перше нескладно знайти спосіб зберегти шелкод в незахищених областях пам'яті, таких як купа (heap). Навіть якщо це буде не так, є інші шляхи. Найбільш вбивчий - це так званий метод "return to libc" для створення шелкоду. В цій атаці шкідливе навантаження заноситиметься в стек не шелкодом, а правильним стеком викликів, тож виконання буде рознесене по ланцюжку викликів функцій стандартної бібліотеки, зазвичай з ефектом зняття захисту від виконання і дозволом виконання шелкоду як нормального. Це працює того що, в цій атаці, код не заноситься власне в стек. Замість розміщення коду в стеці і затирання адреси повернення в функцію, адресою верха стеку, адреса повернення затирається адресою (точкою входу) якої-небудь потрібної для атаки бібліотечної функції (напр. system()
за допомогою якої можна запустити наприклад bash), яка майже гарантовано вивантажена в простір процесу. Однак, якщо невиконуваний стек використати в поєднанні з техніками, такими як ASLR, коли адреси блоків стеку, купи, та динамічних бібліотек рандомізуються (тобто щоразу в системі вони розміщуються в іншій адресі віртуального адресного простору процесу), це може ускладнити "return to libc" атаки, і тому може сильно підвищити безпеку програми.
Відомі приклади
- Хробак Моріса поширювався, серед іншого, використовуючи переповнення стекового буфера в сервері Unix finger. Доповідь щодо інтернет-хробака.
- Хробак поширювався експлуатуючи переповнення стекового буфера в BlackICE Desktop Agent.
- Хробак поширювався, використовуючи переповнення стекового буфера в SQL сервері Microsoft.[2]
- Хробак поширювався, використовуючи переповнення стекового буфера в службі DCOM Microsoft.
- Експлойт був створений для ігрової консолі Wii. Занадто довге ім'я для коня ("Epona") в The Legend of Zelda: Twilight Princess спричиняло переповнення стекового буфера, дозволяючи виконання довільного коду.
Див. також
Посилання
- Fithen, William L; Seacord, Robert (27 березня 2007). VT-MB. Violation of Memory Bounds. .
- Dowd, Mark; McDonald, John; Schuh, Justin (November 2006). The Art Of Software Security Assessment. Addison Wesley. с. 169–196. ISBN .
- (8 листопада 1996). . Phrack. 1 (49): 14. Архів оригіналу за 27 жовтня 2012. Процитовано 3 лютого 2010.
- Pincus, Jonathan; Baker, Brandon (July-August 2004). Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns ([недоступне посилання з 01.06.2008] — Scholar search). IEEE Security & Privacy. 2 (4): 20—27. doi:10.1109/MSP.2004.36.
- Burebista. Stack Overflows (PDF). з джерела 28 вересня 2007. Процитовано 2010-02-03.
- Bertrand, Louis (2002). . MUSESS '02: McMaster University Software Engineering Symposium. Архів оригіналу за 30 вересня 2007. Процитовано 3 лютого 2010.
- pr1. Exploiting SPARC Buffer Overflow vulnerabilities (HTML). з джерела 5 лютого 2012. Процитовано 2010-02-03.
- Curious (8 січня 2005). Reverse engineering - PowerPC Cracking on Mac OS X with GDB. Phrack. 11 (63): 16.
- Sovarel, Ana Nora. Where’s the FEEB? The Effectiveness of Instruction Set Randomization (HTML).
- Zhodiac (28 грудня 2001). . Phrack. 11 (58): 11. Архів оригіналу за 1 травня 2008. Процитовано 18 липня 2019.
- Ward, Craig E. (13 червня 2005). (PDF). Unix Users Association of Southern California. Orange County, California. Архів оригіналу (PDF) за 26 грудня 2010. Процитовано 3 лютого 2010.
- Foster, James C.; Osipov, Vitaly; Bhalla, Nish; Heinen, Niels (2005). Buffer Overflow Attacks: Detect, Exploit, Prevent (PDF). United States of America: Syngress Publishing,Inc. ISBN .
- Nergal (28 грудня 2001). The advanced return-into-lib(c) exploits: PaX case study. Phrack. 11 (58): 4.
Цю статтю треба для відповідності Вікіпедії. (Березень 2010) |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
U Vikipediyi ye statti pro inshi znachennya cogo termina Perepovnennya steka znachennya V programah perepovnennya bufera steku traplyayetsya koli programa pishe za adresami v programnomu steku vikliku poza priznachenoyu strukturoyu danih ce zazvichaj bufer fiksovanoyi dovzhini Bag perepovnennya bufera steku traplyayetsya koli programa pishe bilshe danih v bufer rozmishenij v steku nizh bulo faktichno vidileno miscya dlya bufera Ce majzhe zavzhdi prizvodit do psuvannya prileglih danih v steku i v razi yaksho perepovnennya bulo zrobleno pomilkovo chasto prizvodit do krahu programi abo nekorektnoyi roboti Cej tip perepovnennya ye odnim z vipadkiv zagalnishogo klasu bagiv programuvannya znanih yak perepovnennya bufera Yaksho atakovana programa vikonuyetsya z specialnimi privileyami abo prijmaye dani z nedovirenih hostiv merezhi napr vebserveriv todi bag ye potencijnoyu vrazlivistyu bezpeki Yaksho stekovij bufer zalitij danimi yaki nadijshli vid nedovirenogo koristuvacha todi cej koristuvach mozhe poshkoditi stek v takij sposib sho v steku opinyayetsya vikonuvanij kod inzhektovanij nim vidtak vin otrimuye upravlinnya procesom Ce odin z najstarishih i najnadijnishih metodiv dlya zlovmisnikiv otrimati neavtorizovanij dostup do komp yutera Vikoristannya perepovnen stekovih buferivKanonichnij metod ekspluataciyi perepovnennya stekovogo bufera ye zatirannya adresi povernennya v funkciyu yaka viklikala caller potochnu funkciyu callee vkazivnikom na kontrolovani hakerom dani zazvichaj na toj zhe stek Ce ilyustruyetsya v prikladi nizhche Priklad z strcpy include lt string h gt void foo char bar char c 12 strcpy c bar perevirki mezhi masivu nemaye int main int argc char argv foo argv 1 return 0 Cej kod bere argument z komandnogo ryadka i kopiyuye jogo v lokalnu stekovu zminnu c Vse pracyuye dobre dlya argumentiv komandnogo ryadka menshimi za 12 simvoliv yak vi mozhete bachiti z malyunka B nizhche Bud yaki argumenti bilshi za 11 simvoliv v dovzhinu sprichinyat poshkodzhennya steku Maksimalne chislo simvoliv sho budut bezpechnimi ye na odin menshe nizh rozmir bufera bo ryadki v movi C obmezhuyutsya nulovim bajtom yakij tezh treba vrahovuvati Ryadok z dvanadcyati odnobajtnih simvoliv naspravdi vimagatime trinadcyatibajtnogo vmistilisha Nulovij bajt todi potre odin bajt dilyanki pam yati poza kincem bufera Programnij stek foo z riznimi vvedennyami A Pered tim yak dani skopijovano B hello ce pershij argument komandnogo ryadka V A A A A A A A A A A A A A A A A A A A A x08 x35 xC0 x80 ce pershij argument komandnogo ryadka Primitka Na malyunku vkazivnik char bar chomus lezhit poverh adresi povernennya i navit zberezhenogo vkazivnika na stekovij kadr poperednoyi funkciyi registr ebp ale yak argument funkciyi foo char mav bi buti yakraz pered adresoyu povernennya Na malyunku V vishe koli argument vzyatij z komandnogo ryadka bilshij za 11 bajtiv foo tochnishe strcpy viklikana foo zatiraye lokalni dani steku zberezhenij vkazivnik na stekovij kadr ebp i sho najgolovnishe adresu povernennya Koli foo povertayetsya vikonannya v nij dohodit do instrukciyi ret vona znimaye zi steku adresu povernennya i peredaye na neyi upravlinnya komandu ret mozhna traktuvati yak pop eip Yak vi mozhete bachiti na malyunku V vishe ataker poter adresu povernennya vkazivnikom na stekovij bufer char c 12 yakij teper mistit vstavleni nim dani U vipadku spravzhnogo ekspluatuvannya perepovnennya stekovogo bufera ryadok bagatoh A mig bi mistiti shelkod shellcode dlya ciyeyi platformi i potribnoyi funkciyi Yaksho programa maye osoblivi privileyi napr bit SUID vistavlenij dlya vikonannya na pravah superkoristuvacha todi haker mozhe vikoristati vrazlivist shob distati prava superkoristuvacha na atakovanij mashini Haker takozh mozhe modifikuvati vnutrishni zminni dlya ekspluataciyi deyakih bagiv Toj zhe priklad include lt stdio h gt include lt string h gt void foo char bar float MyFloat 10 5f Adresa 0x0023FF4C char c 12 Adresa 0x0023FF30 Drukuvatime 10 500000 printf My float value f n MyFloat Karta pam yati pam yat vidilena c pam yat vidilena MyFloat insha pam yat c MyFloat 0x0023FF300x0023FF4C foo My string is too long XXXX memcpy potre poslidovnistyu bajtiv 0x10 0x10 0xC0 0x42 znachennya zminnoyi MyFloat Yak plavayuchij tip cya poslidovnist ye chislom 96 0313720703125 bajt 0x42 starshij memcpy c bar strlen bar ne pereviryayetsya mezha masivu nadrukuye 96 031372 printf My Float value f n MyFloat int main int argc char argv foo my string is too long x10 x10 xC0 x42 return 0 Platformozalezhni vidminnostiRizni platformi mayut tonki vidminnosti v svoyij realizaciyi steku vikliku sho mozhe zavaditi ekspluataciyi perepovnennya stekovogo bufera Deyaki mashinni arhitekturi zberigayut verhnorivnevu adresu povernennya steku vikliku v registri Ce oznachaye sho bud yaka poterta adresa povernennya ne vikoristovuvatimetsya do piznishogo rozgortannya steku viklikiv Inshij priklad mashinnospecifichnoyi detali yaka mozhe zavaditi vikoristati cyu tehniku ce fakt sho bilshist RISC arhitektur ne dozvolyayut nevirivnyanij unaligned dostup do pam yati Tobto adresi instrukcij mayut buti zavzhdi chislami kratnimi do yakogos chisla napriklad 4 V poyednanni z fiksovanoyu dovzhinoyu mashinnoyi komandi ce mashinne obmezhennya mozhe zrobiti tehniku jump esp majzhe nemozhlivoyu dlya vtilennya za vinyatkom koli programa dijsno mistit malojmovirnij kod dlya tochnogo perehodu na znachennya stekovogo registra Steki yaki rostut vgoruV temi perepovnen stekovih buferiv ye chasto obgovoryuvana arhitektura yaka ridko zustrichayetsya na praktici v yakij stek roste v protilezhnomu napryamku Tobto verh steku ruhayetsya v bik starshih adres koli stek zapovnyuyetsya a ne navpaki yak v zvichajnomu steku Cya zmina arhitekturi chasto proponuyetsya yak rishennya problemi perepovnennya stekovogo bufera bo bud yake perepovnennya stekovogo bufera yake trapitsya vseredini togo samogo stekovogo kadru ne zmozhe pereterti vkazivnik povernennya Podalshij rozglyad cogo zayavlenogo zahistu viyavlyaye sho ce ne vidpovidaye dijsnosti Bud yake perepovnennya sho traplyayetsya v buferi z poperednogo stekovogo kadru vse odno tertime adresu povernennya i dozvolyatime shkidlivu ekspluataciyu baga Napriklad v kodi vgori vkazivnik povernennya z foo ne bude poterto bo perepovnennya spravdi stanetsya v stekovomu kadri strcpy Odnak cherez te sho bufer yakij perepovnyuyetsya pid chas vikliku strcpy mistitsya v poperednomu stekovomu kadri vkazivnik povernennya z strcpy matime starshu adresu pam yati nizh u bufera Ce oznachaye sho zamist zatirannya adresi povernennya foo tertimetsya adresa povernennya z strcpy Najbilshe sho ce oznachatime ce te sho zrostannya steku v protilezhnomu do zvichnogo napryami zminit deyaki detali togo yak ekspluatuvatimetsya perepovnennya stekovogo bufera ale ce pomitno ne zmenshit kilkosti ekspluatovanih bagiv Shemi zahistuZa roki bulo rozrobleno chimalo shem dlya pereshkodzhannya ekspluataciyi perepovnennya stekovogo bufera Voni zazvichaj mayut odnu z dvoh form Pershij metod ce detektuvati perepovnennya bufera i zapobigti peredavannyu keruvannya na shkidlivij kod Drugij metod namagayetsya zapobigti vikonannyu shkidlivogo kodu zi steka bez pryamoyi detekciyi perepovnennya stekovogo bufera Stekovi kanarki Stekovi kanarki nazvani tak cherez te sho voni diyut yak kanarki v vugilnij shahti vikoristovuyutsya dlya detekciyi perepovnennya stekovogo bufera pered tim yak vikonannya shkidlivogo kodu mozhe trapitisya Cej metod polyagaye v rozmishenni nevelikogo cilogo velichini yaka dovilno vibirayetsya na starti programi v pam yati pryamo pered stekovim vkazivnikom povernennya Najbilshe bufernih perepovnen zatirayut pam yat vid molodshih do starshih adres tozh pid chas zatirannya adresi povernennya i otrimannya vidtak kontrolyu v procesi velichina kanarki takozh zitretsya Cya velichina pereviryayetsya pered tim yak pidprocedura vikoristaye adresu povernennya na steku shob perekonatisya sho yiyi ne zmineno Cya tehnika maye uskladniti ekspluatuvannya perepovnennya stekovogo bufera bo zmushuye hakera otrimuvati kontrol nad vkazivnikom komand yakimis netradicijnishimi sposobami takimi yak psuvannya inshih vazhlivih zminnih na steku Nevikonuvanij stek Inshij pidhid do zapobigannya perepovnennya stekovogo bufera polyagaye v zaboroni vikonannya danih zi stekovoyi oblasti pam yati Ce oznachaye sho dlya vikonannya shelkodu zi steku haker maye abo znajti shlyah skasuvati zahist vid vikonannya z ciyeyi oblasti pam yati abo znajti shlyah perenesti korisne navantazhennya svogo shelkodu v nezahishenu vid vikonannya oblast pam yati Cej metod staye populyarnishij zaraz cherez te sho aparatna pidtrimka flazhka ne vikonuvati no execute dostupna na bilshosti desktopnih procesoriv Hocha cej metod stav faktichno tradicijnim v protidiyi ekspluataciyi perepovnennya stekovogo bufera hocha j maye pevni nedoliki Po pershe neskladno znajti sposib zberegti shelkod v nezahishenih oblastyah pam yati takih yak kupa heap Navit yaksho ce bude ne tak ye inshi shlyahi Najbilsh vbivchij ce tak zvanij metod return to libc dlya stvorennya shelkodu V cij ataci shkidlive navantazhennya zanositimetsya v stek ne shelkodom a pravilnim stekom viklikiv tozh vikonannya bude roznesene po lancyuzhku viklikiv funkcij standartnoyi biblioteki zazvichaj z efektom znyattya zahistu vid vikonannya i dozvolom vikonannya shelkodu yak normalnogo Ce pracyuye togo sho v cij ataci kod ne zanositsya vlasne v stek Zamist rozmishennya kodu v steci i zatirannya adresi povernennya v funkciyu adresoyu verha steku adresa povernennya zatirayetsya adresoyu tochkoyu vhodu yakoyi nebud potribnoyi dlya ataki bibliotechnoyi funkciyi napr system za dopomogoyu yakoyi mozhna zapustiti napriklad bash yaka majzhe garantovano vivantazhena v prostir procesu Odnak yaksho nevikonuvanij stek vikoristati v poyednanni z tehnikami takimi yak ASLR koli adresi blokiv steku kupi ta dinamichnih bibliotek randomizuyutsya tobto shorazu v sistemi voni rozmishuyutsya v inshij adresi virtualnogo adresnogo prostoru procesu ce mozhe uskladniti return to libc ataki i tomu mozhe silno pidvishiti bezpeku programi Vidomi prikladiHrobak Morisa poshiryuvavsya sered inshogo vikoristovuyuchi perepovnennya stekovogo bufera v serveri Unix finger Dopovid shodo internet hrobaka Hrobak poshiryuvavsya ekspluatuyuchi perepovnennya stekovogo bufera v BlackICE Desktop Agent Hrobak poshiryuvavsya vikoristovuyuchi perepovnennya stekovogo bufera v SQL serveri Microsoft 2 Hrobak poshiryuvavsya vikoristovuyuchi perepovnennya stekovogo bufera v sluzhbi DCOM Microsoft Eksplojt buv stvorenij dlya igrovoyi konsoli Wii Zanadto dovge im ya dlya konya Epona v The Legend of Zelda Twilight Princess sprichinyalo perepovnennya stekovogo bufera dozvolyayuchi vikonannya dovilnogo kodu Div takozhPerepovnennya steku Stek viklikiv Perepovnennya buferaPosilannyaFithen William L Seacord Robert 27 bereznya 2007 VT MB Violation of Memory Bounds Dowd Mark McDonald John Schuh Justin November 2006 The Art Of Software Security Assessment Addison Wesley s 169 196 ISBN 0 321 44442 6 8 listopada 1996 Phrack 1 49 14 Arhiv originalu za 27 zhovtnya 2012 Procitovano 3 lyutogo 2010 Pincus Jonathan Baker Brandon July August 2004 Beyond Stack Smashing Recent Advances in Exploiting Buffer Overruns nedostupne posilannya z 01 06 2008 Scholar search IEEE Security amp Privacy 2 4 20 27 doi 10 1109 MSP 2004 36 Burebista Stack Overflows PDF z dzherela 28 veresnya 2007 Procitovano 2010 02 03 Bertrand Louis 2002 MUSESS 02 McMaster University Software Engineering Symposium Arhiv originalu za 30 veresnya 2007 Procitovano 3 lyutogo 2010 pr1 Exploiting SPARC Buffer Overflow vulnerabilities HTML z dzherela 5 lyutogo 2012 Procitovano 2010 02 03 Curious 8 sichnya 2005 Reverse engineering PowerPC Cracking on Mac OS X with GDB Phrack 11 63 16 Sovarel Ana Nora Where s the FEEB The Effectiveness of Instruction Set Randomization HTML Zhodiac 28 grudnya 2001 Phrack 11 58 11 Arhiv originalu za 1 travnya 2008 Procitovano 18 lipnya 2019 Ward Craig E 13 chervnya 2005 PDF Unix Users Association of Southern California Orange County California Arhiv originalu PDF za 26 grudnya 2010 Procitovano 3 lyutogo 2010 Foster James C Osipov Vitaly Bhalla Nish Heinen Niels 2005 Buffer Overflow Attacks Detect Exploit Prevent PDF United States of America Syngress Publishing Inc ISBN 1 932266 67 4 Nergal 28 grudnya 2001 The advanced return into lib c exploits PaX case study Phrack 11 58 4 Cyu stattyu treba vikifikuvati dlya vidpovidnosti standartam yakosti Vikipediyi Bud laska dopomozhit dodavannyam dorechnih vnutrishnih posilan abo vdoskonalennyam rozmitki statti Berezen 2010