szoltam gyorsan a sracoknak, mert ilyen buli reg volt mar, mint most lesz ;). csapjunk is a kozepebe.
> Vegyél vissza az arcodból, mert el vagy tévedve. A részletek igenis számítanak, mert ha nem figyel rá az ember, úgy el fog taknyolni, mint most Te.
hogy mennyire szamitanak a reszletek, az ki fog derulni, szerintem keszitsd a kotszert, mert kicsit fajni fog ;).
> A bug triggelésekor szó sincs arról, hogy a kernel épp visszatérne hozzá, a userland task MÁR NEM ÉL is virul,
> tekintettel arra, hogy új exception (pl az általad módosított PF ISR) csak akkor hívódhat, ha a GP handler már
> végzett, és kivágta a hibás taskot.
a userland taszk el (van cimtere, stb), mivel kepes vegrehajtani az ominozus syscall-t. meg mindig teljes pompajaban letezik, amikor a kernel a sysreturn-hoz erkezik. ez kivalt egy GPF-t (aminek a vegrehajtasa soran ugye intel procikon nincs stack switch), cserebe a taszk meg mindig letezik. a GPF kezelo futasa *kozben* okoz a jol megkonstrualt exploit payload valamit, aminek hatasara a control flow *elterul*, es a kernel GPF handlere *nem* fut le teljes egeszeben, sot igazabol csak nagyon kis resze, ami asm-ben van, a C szintu kezelo (ahol signal handling, task kill, stb tortenhetne) *nem* hivodik mar meg. a kis moricka abradon bemutatva:
> 3. "A" GPF handler indul (injektálás)
*itt* rovid uton page fault/akarmi tortenik, ami az exploit altal kivant modon elteriti a control flow-t
> 4. "A" GPF visszatér, de nem a meghaló taszkra
^^^^^^^^^-> ilyen allat nincs, mert a GPF kezelo futasa mar korabban megszakitodott (exploit altal szandekoltan), es mas tortenik. igazabol ha az exploit iroja nagyon akarja, akkor a piszkos munka elvegeztevel meg akar ide is visszaterhet, bar tipikusabb egy direkt exit() hivasa ilyenkor (esetleg ha tul nagy volt a memoria korrupcio es tul sok munka lenne visszaallitani valami konzisztens allapotot, akkor szokas meg alvos vegtelen ciklusba vinni ezt a taszkot).
> Bizonyísd be! Ezeket az értékeket a CPU helyezi a verembe, és ráadásul ebből 4 olyan regiszter, amit ugyancsak megnézek, hogy módosítasz ring3-ról.
na es honnan jonnek ez az ertekek? nahat, csak nem az epp felbeszakitott userland taszk regiszter kontextusabol? :) azt vagod, hogy az egesz exploit azert letezhet, mert a kernel a userland altal meghatarozott vermet kezdi el hasznalni?
> Ha ezt [rcx] befolyásolni tudnád, akkor az egész syscall értelmetlen lenne.
ha elolvasod *es* megerted a nevezett mernokok altal irt doksit, akkor megtudod, hogy az rcx erteke egy userland-es memoria cim, nem mellesleg a syscall utani utasitas cime. mivel a syscall cimet te kontrollalod, igy ezen keresztul az rcx-be kerult erteket is. idezet linux kodbol: movq RIP-ARGOFFSET(%rsp),%rcx
> Oké, de melyikét? Azt, amelyiket épp most lőtt ki a GP handler? :-D Muhahahaha
mivel a GPF handler semmit nem lo ki (el sem jut odaig a kernel kod, hogy barmi ilyet tehessen), ezert akar az exploit processz sajat uid-jat is lehet modositani. egyeb korulmenyek miatt ez lehet a kezenfekvo valasztas de akar lehetetlen is (pl. tul sok korrupcio miatt nem lehet visszaengedi az adott taszkot userland-be).
> Amit mikor is mentesz le?
minek mentsem le, amikor ki tudom olvasni bzImage/vmlinux/System.map/stb-bol? vagy rekonstrualni tudom disasm alapjan (bizony, ezek a franya exploit irok kepesek ilyet elkovetni, de te nyilvan olvastal mar ilyen kodot, nem kell bemutatni ;).
> A syscall handler és GP handler hívás között? Muhahahahahahahahahahaha. Looser.
nem, a GPF handler kenyszeritett megszakitasa utan meghivodo exploit kodbol.
konkluzio: nagyobb balfasz vagy, mint eloszor mutattad, de hajra, csinalj meg nagyobb hulyet magadbol ;).