Öregem, nincs szoli a környéken? Miért égeted magad ennyire?
"jaj kis baratom, az ilyen 'ezt mondtad, bizonyitsd be' trukkok nalam nem mukodnek am ;)."
Persze, mert még a végén kiderül, hogy nem is értesz hozzá. Ha meg igen, akkor mi tart vissza? Talán jobb, hogy hülyét csinálsz magadból?
"eloszor is citation needed (nem tudsz, tehat hazudtal, hogy ezt irtam)."
Tévedsz, én nem hazudok. Íme, itt írtad:
"> legalább 5*8 byte garbage
miert? kontrollalhato egy jo resze."
Égés pont: +1
Meg itt:
">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?"
Helyes válasz: nem. Szépen is néznénk ki, ha a kernel minden egyes utasításvégrehajtásnál és stackműveletnél konzultálna a TCB-ben lévő értékekkel... És különben is, megnézem, hogy miután átírod a kódszegmens szelektort, hogy ugrasz a syscall utasításra :-D :-D :-D
Égés pont: +1
aztán itt egy másik, amiből látszik, mennyire nem vagy képben:
"> Azt szeretném, hogy bizonyítsd be az állításod, és vedd rá a CPU-t, hogy 5 darab 42-es értéket tegyen a verembe
> a CS+RIP+FLAGS+SS+RSP kombó helyett ISR híváskor.
ez most igy megis mi? miert jo egy exploitnak, ha pont ennyi es ilyen erteku adatot tud iratni a kernel verembe?"
Nem tudom, miért gondoltad, hogy ezeket az exploit teszi/tetteti a verembe, mikor direkt írtam, hogy a CPU.
Égés pont: +1
"eloszor is az rcx egy regiszter"
Ha rcx "csak" egy regiszter ebben a kontextusban, akkor mi akadályoz meg benne, hogy bemutass egy kódrészletet, ami felülírja?
Talán az, hogy ehhez módosítani kéne a syscall handler-t, amit nem fogsz, hiszen épp most akarsz injektálni, ergo a syscall handler még az eredeti.
Égés pont: +1
"amugy meg man ptrace/execve/sigreturn."
Ami mind jóval magasabb szint, mint amiről most szó van, de a tény, hogy ezt nem fogod fel, elég sok pontot megér :-)
Égés pont: +2
"> valamint megoldja, hogy az rax (és a többi, syscall handler által módosított regiszter) értéke helyett a syscall
> hívás előtti userland értékek kerüljenek lementésre
citation needed."
Parancsolj, itt van:
"> rax=garbage, nem használhatod
miert? syscall visszateresi erteke, siman lehet jo valamire. pl. 0-val felulirni"
Ki mondta, hogy rax értéke visszatéréskor 0? Semmi garancia nincs rá, hogy ugyanazzal a paraméterekkel meghívott syscall mindig ugyanolyan értékekkel tér vissza. De ezt Te is tudod, le is írtad:
"az rax tudvalevoleg (itt most nem rolad van szo ;) (sys)call clobbered regiszter, azaz megvaltozik az erteke a hivas soran"
De ha, tegyük fel, legyen mindig nulla, akkor is mit kezdesz vele? Csak úgy tudod kiírni azt a nullát, hogy eléje-mögéje még rengeteg egyéb adatot írsz, aminek mind nem szabad problémát okoznia. Ezért egy fgv pointereket tartalmazó struktúrában használhatatlan, mert elrontod a többi pointert is, ami könnyen crash-t okoz még mielőtt megkapnád a root promptot. Ennek ellenére nem tartom kizártnak, hogy esetleg létezhet ilyen, de szeretném látni, melyik. Nem kell kódolnod, elég ha meghivatkozod a kérdéses kernelstruktúrát a linux sourceban.
"pontosan lehet tudni, milyen erteke lehet sysret-kor (adott syscall visszateresi erteke)"
Jujjjj, azért azt Te is érzed, mekkora kapufát lőttél most. Ez azt jelentené, hogy sose futhatna hibára egyetlen syscall sem.
Égés pont: +1
"a tobbi regiszter allapota pedig kernel fuggo, de tipikusan rendesek es visszaallitjak a userland kontextust, amennyire lehet"
BINGO!!!!!! Ergo nem kontrollálható userlandből a teljes injektálandó adatmennyiség. Örülök, hogy utánnaolvastál.
"ugy altalaban lovesed sincs a ret2libc/ROP exploit technikarol, mi? ;)"
De, van, nem is kevés. Írtam is párat, rablóból lesz a jó pandúr alapon. Neked nincs lövésed az alacsonyszintű kernel rutinokról és az x86 CPU működéséről. (Ne írd, hogy de van, mert úgysem hiszem el, inkább védd meg valamelyik állításod konkrét példával. Nehéz eset vagy, ezért könnyítek: az is bőven elég, ha behivatkozol egy már megírt exploitot vagy bármilyen másik kódot)
"raadasul ennel a kernel bugnal meg csak erre sincs szukseg."
Nemhogy szükség nincs rá, hanem nem lehet kihasználni (mint már többször írtam, és Te is hajlandó voltál elfogadni, a GP handler elején és nem a végén kell eltéríteni, hogy működhessen).
Na jó, akkor lássuk, mennyit is ért ez a hozzászólásod:
Alátámasztott állítások: 0
Hivatkozások: 0
Égéspont: 7