> Ha nem végez, akkor csak megfektetted a gépet, de nem jutottál root privilégiumhoz.
te meg ugye sose lattal kernel exploitot? ;)
> Csak néhány bytenyi adat fér el a GPR-ekben, nem a teljes címtér...
...amikkel ha pointereket irok felul, maris ravettem a kernelt, hogy a teljes cimteret elerje.
> Mégis, milyen saját kódról beszélsz?
arrol a kodrol, amit a kernel el tud erni az adott pillanatban. ez lehet a user taszk teruleten, vagy akar a kernelen is.
> Leírtam már világosan,
leirtal te mar sok mindent, attol meg nem lesz tobb ertelme.
> hogy össz-vissz az a pár byteod van, amit beinjektáltál, ebben kell megoldanod azt is, hogy felülírj egy gate-t,
vagy barmit, ahol fuggveny pointer van, de ne vesszunk el a reszletekben.
> és azt a programot is, amire a gate mutat!
ez viszont ugy baromsag, ahogy van. mi akadalyozza meg a kernelt, hogy vegrehajtson barmilyen kodot, ami az adott pillanatban szamara vegrehajthato? a te szuklatokoruseged nem erv. nem mellesleg az IDT tipikusan nem vegrehajhato memoriaban van.
> Másra nem tudsz ugyanis hivatkozni, mert a többi kódod (azt, amiben a syscall utasítást írtad és futtattad) már bebuktad.
a bug triggerelesenek a pillanataban a userland taszk el es virul (a kernel epp visszaterni keszult hozza, ugyebar), koszoni szepen.
> legalább 5*8 byte garbage
miert? kontrollalhato egy jo resze.
> rax=garbage, nem használhatod
miert? syscall visszateresi erteke, siman lehet jo valamire. pl. 0-val felulirni egy jol fesult fuggveny pointert valahol.
> rbx=kevés egy gatehez
rbp-vel egyutt is? csak mert linux alatt egymas utan vannak (de ezt nyilvan tudtad, es csak benezted, nem igaz? ;).
> rcx=garbage
kontrollalt (max nem idealis IDT entry-nek, de pl. tokeletes tetszoleges ops strukturaban fuggveny pointer felulirasara).
> rdx, rsi=(gate adatai, base address=ahová az rdi kerül a push során)
legyen.
> rdi=isr-ed első bytejai
> r8,r9,r10=isr-ed további bytejai
> r11=garbage, a kódodban át kell ugrani
> r12,r13,r14,r15=isr
meg mindig el vagy veszve es azt hiszed, hogy a userland regiszter kontextust kod injektalasara hasznalja az exploit. nagy tevedes.
> Ezért (attól függően hogy mennyi regisztert hagy békén a syscall handler) max 62 byte áll rendelkezésedre, ahová a "saját kód"-odat rakhatod. Nem valami sok, bármi érdemlegeshez, nem igaz?
egyreszt tok mindegy, hogy mennyi, ha az IDT teruleten eleve nem engedett a kodvegrehajtas, masreszt annyi kodban siman felul lehet irni egy processz uid-jat. esetleg megnezhetnel vegre egy igazi kernel exploitot, kevesebb hulyeseget irnal ide.
> És bizony azt is jelenti, hogy minden, 14-nél nagyobb indexű exceptionnek érvénytelen lesz az IDT entryje. Így már világos?
es az kit erdekel? ideiglenes allapot, jol fesult exploit elso dolga visszaallitani az eredeti tartalmat. mellesleg en speciel siman ops strukturara utaznek, sokkal tisztabb.
> Ez megint egy szemenszedett hazugság. Nagyonis ment, a syscall prologue is, és a CPU is GPF-kor belementi a flageket[...]
te 'egyeb adatrol' beszeltel, nem a userland kontextus regisztereirol. es olyat bizony se a GPF se mas handler nem ment le.
> Nem érdekel, hogy ennyire nem értesz hozzá [...]
ugy latszik erzekeny pontodra tapintottam ;). de sajnos nem en allitottam olyan sultbaromsagot, hogy az NX violation GPF-t general meg hasonlok, az ld.so-s meg runtime codegen-es zoldsegeidrol nem is beszelve. szoval kisbaratom, ha okosnak akarsz mutatkozni, akkor meg nagyon sok olvasnivalod van hatra. nem csak az intel kezikonyveket kell megertened, de nem artana kis linux kodot is olvasni, aztan meg par eles exploitot, hogy legyen nemi lovesed a temahoz legkozelebb :).