> 1. arra, hogy regiszterértékeket másolj. Hol fogod ezzel kideríteni, hogy milyen értékek kellenek?
mi akadalyoz meg abban, hogy tudjam a GDT/IDT/stb formatumat/tartalmat?
> 2. amikor a GP handler végez, és meghívja az iret-et,
mibol gondolod, hogy 'a GP handler vegez'? az exploit celja pontosan az, hogy minel elobb divergaljon a control flow.
> egy új taskra fog visszakapcsolni, és nem a meghalóra.
ugy altalaban mit szamit, hogy a triggerelo taszk el-e? mi akadalyozza meg az exploitot, hogy tobb taszk alapu legyen?
> Így nagyon kevés adatot tudsz használni,
nem ertem milyen keves adatrol beszelsz. ott a teljes cimterem. meg a kernele is.
> másrészről mire is akarod módosítani a GDT-t vagy az IDT pontosan?
IDT: leirta nergal, olvasd el.
> IDT-vel max a most elhelyezett pár byteba nyomorított kódodra tudsz ugrani (ami persze érvénytelen GDT-IDT-t is jelent egyben), másod ugyanis nincs.
miert feltetelezed, hogy az IDT-ben felulirt byte-okat en kodkent akarom vegrehajtani? mitol lenne ervenytelen az IDT? speciel pont az a celom, hogy sajat interrupt gate-et tegyek bele, amit utana triggerelve szepen a sajat kodom fog vegre futni.
> Az, hogy emelt privilégiumszinttel visszatérsz a syscall utánni utasításra (amit a "privilege escalation" jelent a címben ugye) eleve ki van csukva.
oda 'terek vissza', ahova akarok ;).
> 3. azért, mert a SOMETHING_MALICIOUS bármi lehet, akár kód is. Logikus, hogy valamit akarsz kezdeni az emelt jogaiddal, nemde?
lehetne kod is, ha felul tudnek irni olyan kodot, amit a kernel eleve vegrehajt magatol is. DEBUG_RODATA ezt mar a normal kernelben is megakadalyozza, ujabban mar a moduloknal is, de mindennel sokkal egyszerubb, ha eloszor adatot modositok (amit nergal is irt), es utana ebbol lesz control flow atiranyitas.
> 4. pontosan akkor lenne kontrollálható, ha CPU és a GP handler nem mentene egyéb adatot a verembe a GPR-eken kívül,
nem ment, de ez nem is erdekes.
> valamint ha az ABI nem használna egy GPR-t se.
ez mit szamit? nergal modszerenel pl. pont azt akarjuk elerni, hogy a kernel minel elobb page faultot okozzon.
> Mindennek ellenére persze elképzelhető, hogy pont elfér baj nélkül, csak még tovább csökken az injektálható adatmennyiség,
az injektalt adatmennyiseg nem csokken vagy no, azt pontosan meghatarozza az exploitalt kod maga. adott esetben ezek a lementett userland regiszterek, se tobb, se kevesebb.
> és annak az esélye, hogy nem rontasz el valamit injektálás közben.
mit ront el egy exploit iro? az a dolga, hogy ne rontsa el ;).
> 5. jó, kikényszerítetted. Tovább hogy? Mit módosítasz és mire?
leirta nergal, olvasd el.
> 6. ezt tényleg ennyire nem értitek?
saccra neked vannak eleg kodos elkepzeleseid errol az egesz kernel exploit temarol ;).
> Ha csak úgy tud egy userspace app memóriát kérni a kerneltől, hogy az beállítja a lapozótáblában az NX bitet, akkor nem lesz futtatható az adott lap,
userspace app tud vegrehajthato memoriat is kerni a kerneltol, maskepp eleg nehezen tudna nevezett userspace app maga futni. akkor mi akadalyozza meg az exploitot, hogy tetszoleges cimre linkelje magat?
> ergo a 7. pont ("Jump to syscall instruction at (1<<47)-2") GPF-et fog okozni még mielőtt a syscall kifejthetné hatását,
az NX violation nem okoz GPF-t.
> azaz ez userspace-supervisor váltás, így a CPU a TSS.RSP0 pointerében mutatott vermet fogja használni,
(eltekintve az IST-tol) a nergal altal leirt egyik lehetseges exploit celja pont az, hogy a kernel maga okozzon lapozasi hibat, ilyenkor nincs stack switch, es marad az exploit altal megadott vermen.
> Bőven elég, ha a syscall fix helyre mappelt, futtatható lapon van, lásd linux-gate.so.1.
akkor miert vannak direkt syscall hivasok ld.so-ban meg libc-ben is?
> Fogadjunk, el sem olvastad az általam linkelt oldal "Security considerations" fejezetét.
heh, hu de bator lett valaki ;).
> Az meg, hogy egy userspace alkalmazás csak adatlapot kérhet, szerintem biztonsági okokból nyilvánvaló.
szerintem meg szimplan nem erted ezt az egesz user/kernel/cimter dolgot. mar fentebb celoztam ra, hogy a nyube tud futni *barmilyen* kod, ha userland nem kepes vegrehajthato memoriat kerni es kapni a kerneltol? ;)
> Igazából a dlopen híváson kívül sehol sincs szükség rá, hogy kód mappelést kérjen egy userspace app, ez az egy eset meg könnyen lekezelhető.
igazabol de. szerinted java/JIT forditok/stb hogy mukodnek?
> Egy szó mint száz, értem az elméletet
erted a lofaszt ;).
> de kétlem, hogy a sok limitáció miatt gyakorlatba átültethető lenne,
az a sok limitacio szerintem leginkabb a te fejedben letezik csak.