Kees Cook, isang dating punong sysadmin sa kernel.org at pinuno ng pangkat ng seguridad ng Ubuntu, nagtatrabaho ngayon sa Google upang protektahan ang Android at ChromeOS, ay naglabas ng isang hanay ng mga patch na nagsasabay sa mga offset ng kernel stack kapag paghawak ng mga tawag sa system. Ang mga patch ay nagpapabuti sa seguridad ng kernel sa pamamagitan ng pagbabago ng lokasyon ng stack, lo na ginagawang mas mahirap at hindi gaanong matagumpay ang mga pag-atake ng stack
Ang orihinal na ideya para sa patch ay kabilang sa proyekto ng PaX RANDKSTACK. Noong 2019, sinubukan ni Elena Reshetova, isang inhenyero sa Intel, na lumikha ng isang pagpapatupad ng ideyang ito, na angkop para isama sa pangunahing komposisyon ng Linux kernel.
Kasunod, ang pagkusa ay kinuha ni Kees Cook na nagpakita ng angkop na pagpapatupad para sa pangunahing bersyon ng kernel at na ang mga patch ay pinlano para sa bersyon 5.13 ng Linux.
Ang mode ay hindi pagaganahin bilang default at upang paganahin ito, inaalok ang parameter ng linya ng utos ng kernel "Randomize_kstack_offset = on / off»At mga setting CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, Bilang karagdagan, ang overhead ng pagpapagana ng mode ay tinatayang sa humigit-kumulang na 1% pagkawala ng pagganap.
Ang kakanyahan ng ipinanukalang proteksyon ay upang pumili ng isang random na offset ng stack sa bawat tawag sa system, na kumplikado sa pagpapasiya ng layout ng stack sa memorya kahit na natanggap ang impormasyon sa address, dahil ang batayang address ng stack ay magbabago sa susunod na tawag.
Hindi tulad ng pagpapatupad ng PaX RANKKSTACK, sa mga patch na iminungkahi para isama sa kernel, ang randomization ay hindi ginagawa sa paunang yugto, ngunit pagkatapos itakda ang istraktura ng pt_regs, na ginagawang imposibleng gumamit ng mga pamamaraan na nakabatay sa ptrace upang matukoy ang isang random na offset sa panahon ng matagal nang pagtawag sa system.
Tulad ng mga proteksyon ng Linux kernel stack ay patuloy na pinabuting (vmap-based stack mapping na may mga pahina ng proteksyon, pag-aalis ng thread_info, STACKLEAK), ang mga umaatake ay kailangang makahanap ng mga bagong paraan upang gumana ang kanilang pagsasamantala.
Mayroon silang, at patuloy na umaasa sa kernel stack determinism, sa mga sitwasyon kung saan VMAP_STACK at THREAD_INFO_IN_TASK_STRUCT hindi sila nauugnay. Halimbawa, ang mga sumusunod na kamakailang pag-atake ay maaaring maging hadlangan kung ang stack offset ay hindi deterministic sa pagitan ng mga tawag sa system
Ang layunin ng pagpapaandar na randomize_kstack_offset ay upang magdagdag ng isang random na offset pagkatapos ng pt_regs ay naitulak papunta sa stack at bago ang natitirang thread stack ay ginagamit sa panahon ng pagpoproseso ng tawag sa system, at palitan ito sa tuwing naglalabas ang isang proseso ng isang tawag sa system. Ang mapagkukunan ng pagiging random ay kasalukuyang tinukoy ng arkitektura (ngunit ang x86 ay gumagamit ng mababang byte ng rdtsc ()).
Posible ang mga pagpapahusay sa hinaharap para sa iba't ibang mga mapagkukunan ng entropy, ngunit sa labas ng saklaw ng patch na ito. Gayundin, upang magdagdag ng higit na hindi mahuhulaan, ang mga bagong offset ay pinili sa pagtatapos ng mga tawag sa system (ang oras na dapat ay mas madaling sukatin mula sa puwang ng gumagamit kaysa sa oras ng pagpasok ng tawag sa system) at nakaimbak sa isang variable bawat CPU, upang ang buhay ng halaga ay hindi mananatiling tahasang nakatali sa isang solong gawain.
Walang mga nakikitang pagbabago para dito sa x86 dahil ang stack saver ay hindi pa kinakailangan na hindi pinagana para sa unit ng pagtitipon, ngunit kinakailangan ang pagbabago sa arm64. Sa kasamaang palad, walang katangian na maaaring magamit upang hindi paganahin ang stack saver para sa mga tukoy na pag-andar. Paghahambing sa pagpapaandar ng PaX RANDKSTACK: Ang pagpapaandar ng RANDKSTACK ay i-randomize ang lokasyon ng pagsisimula ng stack (cpu_current_top_of_stack), iyon ay, kasama nito ang lokasyon ng istraktura ng pt_regs sa stack.
Sa una, ang patch na ito ay sumunod sa parehong diskarte, ngunit sa mga kasalukuyang talakayan napagpasyahan na maging maliit na halaga na para bang ang pag-andar ng ptrace ay magagamit sa isang umaatake, maaari mong gamitin ang PTRACE_PEEKUSR upang basahin / isulat ang iba't ibang mga offset sa istraktura ng pt_regs, obserbahan ang pag-uugali ng cache ng pag-access sa mga pt_regs at alamin ang random stack offset.
Sa wakas nabanggit na Sinusuportahan ng paunang pagpapatupad ang mga processor ng ARM64 at x86 / x86_64.