"amikrol megmutattam"
Hol? Csak mondtad, de nem mutattad meg.
"ez most igy megis mi? miert jo egy exploitnak, ha pont ennyi es ilyen erteku adatot tud iratni a kernel verembe?"
Jesszus, Te tényleg kernelfejlesztőnek mondod magad? Ez kérlek nem "megis mi", hanem a x86-os architektúra működése ISR híváskor. Ez nem jó vagy rossz az exploitnak, hanem ez a környezet, amiben működnie kell(ene).
"erre azt szoktak mondani, hogy aki szelt vet, vihart arat"
Már bocs, de Te vagy az, akik csak vagdalkozik, én konkrét Intel Manual fejezetreferenciákkal támasztottam alá állításomat.
"mire fel a nagy kacagas itt rajtad ;)."
Akin itt nevetni lehet, az Te vagy. Te vagy az, aki nem olvasta el a sebezhetőséget, nem értette meg, és fingja sincs az x86 működéséről, mégis veri a mellét, mekkora kernel hacker csávó.
Kettőnk között az a különbség, hogy:
Te - nem tudod bizonyítani az állításaid, és vered a melled
Én - tudom bizonyítani az állításom, mégsem verem a mellem
"hint: page fault lesz az exploit altal kontrollalt pointer elerese miatt"
Megint csak a pofázás, de semmi bizonyíték. Hogy kontrollálod az IDT-t, triggerelsz PF-et egyetlen adatinjekcióval egy lépésben? Elárulom, sehogy.
"az volt a kerdesed, hogy tudja a userland processz kontrollalni a sajat kontextusaban az rflags erteket"
Így van, és a popf erre nem alkalmas. Ezzel nem lehet tetszőleges értéket tölteni az rflagsbe. Ha nemcsak pofád lenne nagy, tudnád, hogy pl nemigazán lehet törölni az interrupt-flaget userlandből, és a popf nem használható a vm-flag állítására sem.
"(kontroll nem azt jelenti, hogy minden letezo bitminta beallithato, hanem hogy az exploit irojanak van valami kontrollja felette)"
Ami egyszerűen nem igaz, mert egyetlen egy lineáris cím létezik, ahonnan az exploit kiszanálható. Ez a cím cpu modelltől függően változik, de egy processzoron mindössze egyetlen egy ilyen van. Tudod kéne.
"tulcsordulas. esetleg nem kene szakszavakkal dobalozni, ha lovesed sincs roluk"
Kérlek, világosíts fel, mi a túlcsordulás? Szerinted az nem túlcsordulás, hogy egy összeadást követően az eredmény több helyiértékes, mint a cél tároló érvényes bitkapacitása?
"a kernel sajat, mar reg a memoriaban levo kodja fogja mit sem sejtve dereferalni"
A GP handleren belül? Oszt miért? Az eredeti linux GP handler tudtommal nem dob PF-et a task állapot lementését követően csak úgy. Mert az, hogy majd egyszer lesz valamiért egy PF, nem elég, ugyanis neked ez arra kell, hogy megakadályozd a GP handler lefutását.
"pontosan ugyanugy, ahogy egy klasszikus buffer overflow-nal felulirsz egy visszateresi cimet"
Klasszikus buffer overflow NEM eredményez GPF-et, és nem a GP handlerben injektál. Apró különbség, amivel (mily meglepő) nem vagy tisztában.
"es utana a fuggveny visszateresekor az eredeti programban"
Azt hittem, azt már felfogtad, hogy a GP handler nem futhat le, nem elég, ha a visszatérésekor hívsz egy függvényt!!! Más visszatérés pedig az exploit során NINCS.
"betelik a hupmeme, ha igy folytatod ;)."
Még jobban lejáratod magad, ha így folytatod. Minden hozzászólásoddal egyre több mindent írsz, amiről visít, hogy lövésed sincs az x86-os belső működéséről, mégis vered rá a (jobb esetben) a melled.