> Egyetlen egyszer beinjektálhatsz kb 100 összefüggő adat byte-ot,
az elobb meg azt irtad, hogy "max 62 byte áll rendelkezésedre" ;)
> ...aminek bizonyos helyein kötött értékek vannak, és ettől persze probléma nélkül eltérül a kód.
ez az, amihez el kell olvasni az adott kernel kodjat, es megnezni hogy a data/control flow hol kezd el fuggeni a verem (exploit altal kontrollalt) tartalmatol. erre termeszetesen nincs altalanos valasz, eseti megoldast igenyel. pl. linux-nal (ami jelenleg nem, de par eve serulekeny volt) az alacsony szintu page fault handler egyik elso dolga a userland kontextus lementese utan a thread_info adatstruktura megkeresese - ez pedig tortenetesen a kernel verem legtetejen van, innentol kezdve game over.
> Mutasd mester, hogyan!
ha azt szeretned, hogy megtanitsalak kernel exploitot irni, akkor sajnos rossz hirem van, nem tudsz hozza eleget, nekem meg nincs annyi idom, hogy az alapoktol kezdve elmagyarazzam egy proceszor meg egy kernel mukodeset. viszont ujfent ajanlom publikus kernel exploitok olvasgatasat, sokat megertenel beloluk (vagy nem ;).
> Mitől? Hogyan? Azzal váltod ki a PF-et, hogy átírod az IDT-t?
ha mar szobahoztad, jobb helyeken az IDT read-only, tehat felulirni eleve nem egeszseges. de amugy nem, a PF-t nem ez valtja ki, hanem mint fentebb irtam, pl. egy exploit altal kontrollalt pointer hasznalata. ha meg remlik amokfutasod eleje, akkor nergal emlitette a swapgs problemat, ebbol talan el tudod kepzelni, mi minden lehetseges PF kivaltasara.
> Azt bizony triggerelni is kéne, és te ugye kódot nem futtatsz, csak egyetlen adatstruktúrát írsz felül
es? mi tortenik, amikor sajat tartalommal felulirok egy fuggveny pointert tartalmazo strukturat? pedig csak adatot irtam felul ;).
> Nem, a cpu shadow registereiből jönnek.
es a shadow regiszterekbe honnan kerulnek a GPF soran a kernel veremre lementett adatok? teleportacio? ;) na? userland kontextus (amit epp visszaallitott a kernel sysreturn elott) vagy nem userland kontextus?
> Egyébként meg tessék, szeretném látni, hogy rsp-n kívül bármelyiket módosítod úgy, hogy az ne okozzon egyből exceptiont!
popf. en nyertem? ;)
> Azért ennyire alap x86-os mechanizmust nem ismerni elég égő egy kernel fejlesztőnek.
a sracok szoltak, hogy ezzel a teljesitmennyel lassan atveszed a hupmeme listan a vezetest :).
> Ha kicsit visszavennél az arcodból, és elovastad volna az attackot rendesen, akkor tudnád, hogy az CSAK EGY BIZONYOS címről működik,
> azaz rcx nagyon is kötött. Csak akkor működik az egész, ha rip+sizeof(syscall)>2^(membusz szélesség).
en nem csak elolvastam, de veled ellentetben meg is ertettem ;). szoval nezzuk: aszondod van egy fasza keplet a rip-re. nem igazan igaz, de tegyuk fel, hogy csak pillanatnyi fogalmi zavar volt nalad (eleg hosszuak nalad ezek a pillanatok mondjuk) es tudod mi a kulonbseg a virtualis es fizikai cimek kozott es csak siman azt akartad mondani, hogy a GPF-t non-canonical rip valtja ki sysreturn-nel. a kerdes az, hogy miert feltetelezed, hogy rcx erteke sysenter utan == rcx erteke a sysreturn pillanataban? pedig a szalban mar tobbszor is volt rola szo, hogy mennyi modszer van ennek megvaltoztatasara. szoval ez a "CSAK EGY BIZONYOS címről működik" ugy baromsag, ahogy van (nem kis vicc, hogy a sajat kepleted se egy cimet ir le, hanem egy egesz intervallumot, raadasul off-by-one van benne es pontosan azt az egy rip erteket hagyod ki vele, amire nergal peldaja epul ;).
> Eddig kb ennyi értelme van a hozzászólásaidnak (mivel kódot, barátom, azt bizony nem mutattál egy bitet se).
> ---------------------------------------
> 1. átírni valahol valami kernel adatot
> 2. ???
> 3. root prompt!
> ---------------------------------------
2. a kernel az exploit altal kontrollalt adatot (tipikusan pointert) nem szandekolt celra hasznalja, pl. exploit altal beadott fuggveny pointeren keresztul szepen meghivja az exploit ring-0 reszet. persze ezt is leirtam mar parszor, de mivel a Dunning–Kruger hatas alatt vagy, valoszinuleg megmaradsz hulyenek ;).