> Merthogy a maradék byteokat nem tudod átírni. Mi nem világos ebben?
azokrol a maradek byte-okrol beszelsz, amikrol megmutattam, hogy allitasoddal ellentetben egy reszuket megis csak kontrollalja a userland? pl. rax-ra azt irtad, hogy "garbage", akkor ez most hogy is van? ;)
> 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? mert ha rohadtul semmire se jo, akkor minek akarsz ilyen hulyeseget csinalni? sikeres exploithoz eleg egy pointernyi adatot beirni amugy, nem kell 5.
> Semmivel nem támasztottad alá ugyanis a mondandód (azon kívül, hogy személyeskedsz [...]
erre azt szoktak mondani, hogy aki szelt vet, vihart arat. es ha hozzaveszem, hogy bolond lyukbol szemmel lathatoan kifogyhatatlan mennyisegu bolond szel fuj, maris megerted, hogy mire fel a nagy kacagas itt rajtad ;).
> [...] akár csak a csicskásaid, akik el vannak ájulva attól, hogy egyszer megpatkoltad a kernelt, ami ráadásul sosem
> került a mainlineba. Vajon miért? Újfent segítek: "Saying to the kernel developers "here, throw this huge blob of
> code into your kernel because otherwise we're taking our ball and going home" is not how it works." Mintha ők is azt
> fájlalnák, hogy csak dumálsz, de az érdemi részek nem készülnek el)
jujujuj, megartott a meleg, mi? ;) nezzuk reszleteiben:
1. pax azert nincs a linus faban, mivel eleve sose kuldtem be a kernel listara, igy meg eleg nehez barminek is bejutnia. persze ez sose akadalyozott meg jotet lelkeket, hogy onerobol kiszedegessenek ezt-azt es bevigyek, de gondolom githez annyira se ertesz, mint a processzorokhoz meg exploit irashoz ;).
2. ha mar angol szoveget idezel, nem artana erteni is, hogy az mit mond. mert olyan resz, hogy 'az érdemi részek nem készülnek el', pechedre, nem szerepel benne ;).
3. nincs mit fajlalniuk, mivel mint fentebb irtam, sose kerultek szembe a pax-szal. de hajra, fizetem a nyari sorfogyasztasod, ha megtalalod lkml-en tolem a pax-ot beolvasztasra felkinalo levelet ;).
> Akkor miért is szakadna félbe a stackírást követően a GP handler futása? Megint önellentmondásba keveredtél, ami nem csoda, ha valaki nincs otthon a témában.
olvasd el ujra a szalat, mar leirtam parszor (hint: page fault lesz az exploit altal kontrollalt pointer elerese miatt, adtam ra linuxos peldat is, bar az eddig demonstralt olvasasi kepessegeid alapjan valszeg ez most megint falrahanyt borso lesz ;).
> Hát, sikerült hülyét csinálni magadból, az nem vitás. Azt mondtad, kódot nem injektálsz, márpedig (de javíts ki
> mester) a popf bizony utasítás. Mellesleg miért és mitől pop-olna ki bármit is a GP handler, mikor patcheletlenül nem teszi?
az volt a kerdesed, hogy tudja a userland processz kontrollalni a sajat kontextusaban az rflags erteket (kivetel generalasa nelkul), erre mondtam, hogy popf userlandben (amit a proci/kernel szepen lement majd visszaallit). kezdelek sajnalni, de komolyan ;/
> Akkor miért írsz ilyen hülyeségeket: "mivel a syscall cimet te kontrollalod, igy ezen keresztul az rcx-be kerult
> erteket is"? Mióta kontroll az, egyetlen egy bizonyos értéket állíthatsz csak be, hogy aktíválódjon a GPF?
te irtad, hogy: rcx=garbage. rcx nem garbage, hanem pontosan tudhato erteke van (kontroll nem azt jelenti, hogy minden letezo bitminta beallithato, hanem hogy az exploit irojanak van valami kontrollja felette). persze az eddig demonstralt angol tudasod alapjan nem csodalkozom, hogy ennyi garbage-t beszelsz itt nekunk ;). masreszt nem csak egy rcx (rip) erteknel lesz GPF, hanem minden non-canonical cimnel. mas kerdes, hogy a tobbi erteket mivel lehet beletukmalni az rcx-be (rip-be), de errol irt nergal is meg en is, csak ugy latszik egy szot sem ertettel meg belole.
> Elovastad, meg is értetted, mi? ROTFL, ROTFL, ROTFL. Szerinted ez mit jelent?
jaj mar megint ez a franya angol, mi? ;)
> "At the syscall handler entry, rcx will be set to (1<<47)-2+instruction_len(syscall) = 1<<47, which is non-canonical."
> Várj, elmagyarázom (úgy látszik szükséges). A RIP-et olyan címre irányítod, hogyha hozzáadod a lefuttatott syscall
> utasítást (gyk. következő utasítás címének meghatározása), akkor a cím túlcsordul. Azt ugye tudod, mi az a túlcsordulás?
eloszor is 'which is non-canonical' != tulcsordulas. esetleg nem kene szakszavakkal dobalozni, ha lovesed sincs roluk. masreszt a te kis kepleted (most eltekintve attol, hogy gozod sincs a fizikai/virtualis cimterekrol) pontosan ezt az egy erteket nem fedi le ;). hogy is mondtad, ROTFL ;)
> Leírtad, de azt nem írtad, hogy mitől is hívódna meg a pointeren tárolt fgv. Merthogy, figyelj, alap matek:
> 1. beírni valamit a memóriába (egy pointert) az egy művelet
> 2. beírni egy pointert a memóriába, és ráugrani a benne tárolt címre, na az két művelet.
> Neked egyetlen egy injektálási lehetőséged van (lefordítom, egy művelet), ami során kódot nem injektálsz, mégis hogy
> akarod a második műveletet kivitelezni? Na erre nem bírsz válaszolni, inkább személyeskedsz, ami arról tanúskodik,
> hogy még csak nem is érted a problémát, nemhogy választ tudnál adni rá.
mibol gondolod, hogy az exploit altal beinjektalt fuggveny pointert az exploit altal be (nem) injektalt kod fogja felhasznalni? ;) elarulom a nagy titkot: a kernel sajat, mar reg a memoriaban levo kodja fogja mit sem sejtve dereferalni (meghivni az exploit kodjat). pontosan ugyanugy, ahogy egy klasszikus buffer overflow-nal felulirsz egy visszateresi cimet (amit egy kod pointernek tekint a megtamadott program ugyebar), es utana a fuggveny visszateresekor az eredeti programban meglevo retn mit sem sejtve felhasznalja azt es a vezerlest atadja a shellkodnak.
> Szerintem abbahagyhatod, mert sikerült eléggé lejáratnod magad.
betelik a hupmeme, ha igy folytatod ;).