SYSRET 64 bites opererációs rendszer "privilege escalation" sebezhetőség Intel CPU-s hardveren

Titkosítás, biztonság, privát szféra

A US-CERT (United States Computer Emergency Readiness Team) arra figyelmeztet, hogy egyes, Intel CPU-n futó 64 bites operációs rendszerek és virtualizációs szoftverek sebezhetők helyi privilégiumszint-emelés támadással szemben. A sebezhetőség kihasználható helyi privilégiumszint-emelésre, vagy guest-to-host irányú kitörésre virtuális gépen. A hibát Rafal Wojtczuk (Bromium, Inc.) fedezte fel.

A virtualizációs szoftver és operációs rendszer gyártók eddig kiadott hibajegyei, figyelmeztetői, tájékoztatói:

Részletek, további infók: US-CERT Vulnerability Note VU#649219

( elod v | 2012. 06. 13., sze – 08:26 )

Ezek után mondja még valaki az AMDre, hogy bugos. Mind az, nem is lehet másképp, akkora a komplexitás.

( Zahy v | 2012. 06. 13., sze – 08:57 )

Mint az pinyo_villany blogjából is látszik, minimum a Süsü és az Ora érintett, a többi Linux-disztró csomagolónak nem sikerült ennyi idő alatt válaszolnia. (Mondjuk Ora esetén az a nagy kérdés, hogy a R6-koppintásán kívül a "saját" oprendszere érintett-e - itt a PC-s Slowlarisra gondolok.)
Szerk: ja még az érdekel, hogy az Intel és HP meg az IBM esetén milyen *saját* oprendszerre gondoltak ami PC-n fut?

A cikkben szereplő "Részletek, további infók: US-CERT Vulnerability Note VU#649219" link alatt megtalálható ugyanez az infó linkekkel, ráadásul az feltehetően frissülni is fog, mert nem egy kép. Célszerű azt nézegetni a nap(ok) folyamán.

A full táblázat itt.

--
trey @ gépház

( turdus | 2012. 06. 13., sze – 15:11 )

Ez egy baromság szerintem.

Valaki magyarázza már el, hogy lehet az, hogy
"The fault will be handled before the stack switch, which means the exception handler will be run at ring0 with an attacker's chosen RSP causing a privilege escalation."
Tekintettel arra, hogy a SYSENTER/SYSEXIT utasítássokkal ellentétben a SYSCALL/SYSRET nem használ stacket és nem is vált, az exception handler meg x86-on NEM tudja használni a ring3-as stacket.

Azaz:
1. ha nem változik a stack, akkor milyen stack switch-ről beszél...?
2. ha van stack switch az exception handlerben, akkor meg miért is használná a felhasználó által megadott RSP-t?
3. végül ha sikerül is módosítani a stacket, és rávenni az exception handlert hogy azt használja, mit számít az, mikor a SYSCALL/SYSRET egyáltalán _nem_ nem nyúl hozzá (azaz a paraméterek tipikusan regiszterekben adódnak át, nem stacken keresztül), az exception handler paramétereit meg közvetlenül a ISR hívás előtt, a CPU pakolja a stackbe, így ring3-ról semmiképp, de még ring0-ról sem befolyásolható?

(Az egyetlen, amit el bírok képzelni, bár nagyon nyakatekert, ha valami **** kernelben a SYSCALL által szolgáltatott R11 és RCX regisztereket lementi a user stackbe (sicc!) majd SYSRET előtt visszatölti, de aki ilyent csinál az szimplán hülye.)

Details from the reporter, Rafal Wojtczuk

Attack steps (done by ring3 attacker)

  1. Map a frame at virtual address
    (1<<47)-4096
  2. Any method to set the target of
    sysret

    to a non-canonical address can potentially be used. This includes 

    ptrace

    , 

    sys_sigreturn

    , 

    sigaction

    , 

    execve

    , possibly others. The best solution is to add a check for the address being non-canonical close before executing 

    sysret

    . Note if the 

    syscall

    handler ends with 

    iret

    , then even if 

    iret

    throws 

    #GP

    , 

    rsp

    is not controlled by the attacker, and such the situation can be handled safely.

  3. Place a
    syscall

    instruction at address 

    (1<<47)-2
  4. Place SOMETHING_MALICIOUS in general purpose registers
  5. Set
    rsp

    to AROUND_SOME_IMPORTANT_RING0_STRUCTURE

  6. Other scenarios are possible. Whenever the
    #GP

    handler runs with usermode 

    rsp

    , or does not do 

    swapgs

    correctly, code execution may be possible.

  7. Jump to
    syscall

    instruction at 

    (1<<47)-2

At the 

syscall

handler entry, 

rcx

will be set to 

(1<<47)-2+instruction_len(syscall) = 1<<47

, which is non-canonical. Therefore, when the 

syscall

handler terminates with 

sysret

, 

#GP

will be raised. This fault will be handled without a stack switch (assuming 

#GP

entry in 

IDT

does not include a nonzero IST index), as the faulting instruction is in ring0. Only Intel CPUs are affected. On AMD CPUs, 

sysret

completes the switch to ring3 before throwing 

#GP

, so the stack switch occurs. Also, immediately before 

sysret

, the 

syscall

handler must restore 

rsp

to the value set by ring3 (because 

syscall/sysret

do not set 

rsp

). Therefore, the 

#GP

handler will execute with 

rsp

chosen by the attacker, so when 

GPRs

are pushed on the stack in the 

#GP

handler prologue, SOMETHING_MALICIOUS will be placed at AROUND_SOME_IMPORTANT_RING0_STRUCTURE. This write-anything-anywhere primitive could be enough to hijack execution in ring0. Additionally, in many cases, 

gs

base is not swapped in the 

#GP

prologue (as the fault originates in ring0), which may make the exploitation quite reliable and stable - overwrite 

#PF IDT

entry via stack push, trigger 

#PF

by 

gs

access, repair IDT (from IDT table of other cpu) in the shellcode, return to usermode.

(azért másoltam be ide, mert a CERT eltávolította az oldaláról időközben ezt a leírást... ;)

"Any method to set the target of sysret to a non-canonical address can potentially be used"
Könnyű mondani, de ezt nem lehet kivitelezni. A syscall hívásakor nincs rá mód, hogy ring3-ról befolyásold. Plusz, ha meghívódik a GP handler, az minden értelmes kernelben azzal kezd, hogy kivágja a hibát okozó processt a francba. Márpedig hiába szerzel supervisor privilégiumot, ha utána nincs kódod, ami használja... A GPR-ekben tárolható kódmennyiség szánalmasan kevés, és nincs hova ugrani belőle. Plusz, még azt is meg kéne oldanod (amiről a cikk mélyen hallgat), hogy a vezérlés nem adódik csak úgy a lementett GPR-ekre, ennek kivitelezése ráadásul szinte lehetetlen, mivel elég gyorsan törlődni fog a memóriából (megszűnik a process!!!).

De ha mindettől el is tekintünk, ez a leírás akkor is egy rettenetesen hülye kernelt feltételez, nevezetesen enged írható,futtatható frame-t mappelni - fail (pár éve van már RO+NX bit, nem igaz?) Ha egy kernel ezt engedi, akkor nem kell hozzá sysret+GP hókuszpókusz, hogy feltörd.

Végül itt egy írás attól az embertől, aki a sysenter utasítást tervezte: http://semipublic.comp-arch.net/wiki/SYSENTER/SYSEXIT_vs._SYSCALL/SYSRET
Elég világosan fogalmaz annak kapcsán, hogy kell-e address ellenőrzés:
"SYSCALL, by capturing the return address, avoids the need for such validation."

> A syscall hívásakor nincs rá mód, hogy ring3-ról befolyásold.

man ptrace ;)

> Plusz, ha meghívódik a GP handler, az minden értelmes kernelben azzal kezd[...]

nem, minden handler alacsony szintu asm kodban kezd, ami sok mindent csinal mielott C kodba ugrana es lekezelne olyan magasabb absztrakcios szintu dolgokat, mint 'process', 'signal' meg hasonlok.

> A GPR-ekben tárolható kódmennyiség szánalmasan kevés

nem is kodot tarolsz benne, hanem adatot, amivel felul tudsz irni 'erdekes' kernel adatokat. pl. GDT vagy laptablak.

ptrace: és ez hogy kapcsolódik a mi szituációnkhoz? Meglepődnék, ha ring3-as kóddal debuggolható lenne ring0-ás.
"child to be stopped at the next entry to or exit from a system call"
Ez a legközelebbi, amit elérhetsz vele, de maga a syscall handler (és pláne a GP handler) nem trace-elhető vele. Én legalábbis így tudom, de ha tévedek (nem vagyok ptrace guru), javíts ki nyugodtan.

Igen, valóban asm-el kezd, de ez hol érdekel minket? A lényeg, hogy ami lefut, azt nem tudod befolyásolni (hacsak nem a GPF handlerre irányítod az rsp-t, de ez elég rázós, mert nemcsak a módosított GPR-ek mentődnek, hanem sok minden egyéb is, ami nagy valószínűséggel invalid opcode vagy újabb GP miatti double faulthoz vezet még mielőtt a lényeges kódot végrehajtaná). Az biztos, hogy vissza nem kerül már a vezérlés az adott process-re. Értelmes kernelek GP handlerben kiveszik a ready queue-ból az aktuális processt, majd berakják a terminating queueba, és soha többé nem allokálnak CPU-t neki. Szóval ha valamit akarsz kezdeni vele, azt bizony a GP handlerben kell megtenned, még mielőtt egy új process address-space mappelődne be (ami mellesleg elég valószínű, hogy a sysret hívásakor eleve megtörtént, mert a speckó GPR-ek miatt érvénytelen volt a syscall, és a hibakezelő ág futott le).

nem is kódot tárolsz benne: honnan tudod? Elég ködös a "Place SOMETHING_MALICIOUS in general purpose registers" megfogalmazás. És hogy képzeled a megvalósítást, ha nem kód csak adat van benne? Értem, hogy elméletileg lehetséges lenne, de gyakorlatilag melyik az a kernel adat, aminek
1. a pontos címét ring3-ról előre ki tudod deríteni, hogy a megfelelő értéket rakhasd az rspbe
2. átírva benne sok byteot úgy, hogy abból csak egy része az, amit megadhatsz, a többi random módosítás (akár átlógva más kernel adatstruktúrákra) nem okoz crash-t
3. valamint kódfuttatás nélkül tudod hattatni (ugye mind a GDT, mint a lapozótáblák esetében szükség van a shadow regiszterek és a cache frissítésére, hogy érjen is valamit)

Én továbbra is fenntartom azon álláspontomat, hogy az a tény, hogy a GPF előbb keletkezik, mint a sysret environment helyreállítás, elég ciki az intel mérnökeire nézve, de önmagában nem kihasználható, kell hozzá egy koncepcionálisan elrontott kernel is (futtatható kód mappelési lehetőség), ami ráadásul még fittyet hány a CPU által biztosított jópár védelmi mechanizmusra (IST, NX stb) is.

A ködös megfogalmazások helyett jó lenne látni legalább egy proof of concept-et. Uff, én beszéltem.

Te valamit nagyon félreértesz a kernel működésével kapcsolatban. Ezt a futtatható kód mappelést és NX-et már másodszor írod...

Nagy titkot árulok el. Mindegyik kernel enged írható+futtatható mappelést. Talán egyedül csak a grsec/PaX patch esetén lehet kikényszeríteni az mprotect resztrikciókat.

Pontosan azért, mert mappelés során határozza meg a kernel, hogy mit tehet a ring3 kód a memóriával. Ott ahol lehet írható és futtatható mappelést kérni, alapvető biztonságbeli problémák vannak, ezen nincs mit szépíteni. A tény, hogy létezik grsec/PaX azt jelenti, hogy vannak még, akik szintén így gondolják.

1. PTRACE_SETREGS szerinted mire jo? maris eloallt a bug triggerelesenek a feltetele. hasonlo igaz a nergal altal emlitett tobbi modszerre is.

2. asm entry kod ott erdekel minket, hogy a rosszul megirt kernel kod olyan teruletet kezd el hasznalni veremkent, amit a tamado hatarozott meg RSP-n keresztul. a legelso dolog, amit az entry kod csinal az az, hogy lementi a userland regisztereket... a veremre. tehat a tamado kontrollalja azt, hogy mit es hova ir a kernel. ezt security korokben ugy hivjak, hogy arbitrary write bug. nem mellesleg nergal is leirta fentebb.

3. nem ertem miert feltetelezed, hogy a tamado az RSP-t kod teruletre iranyitja. senki nem irt ilyet.

4. erzekeny adatot felulirni meg trivialis: SGDT/SIDT (nergal is leirt egy konkret otletet, elolvastad/megertetted?). az 'eleg sok byte' meg pontosan tudhato, hogy mennyi es hogy hova kerul, tehat pontosan kontrollalhato, hogy mit es mivel irsz felul.

5. felulirt adat hasznalatanak kikenyszeritese: pl. a nergal altal emlitett modszer eseten: page fault triggerelese gs-en keresztul (ha pl. az adott kernel elbenazza annak a switch-eleset is).

6. nyilvan szukseges rosszul megirt kernel kod az adott CPU viselkedes kihasznalasahoz, de annak semmi koze az NX-hez.

1. arra, hogy regiszterértékeket másolj. Hol fogod ezzel kideríteni, hogy milyen értékek kellenek?

2. amikor a GP handler végez, és meghívja az iret-et, egy új taskra fog visszakapcsolni, és nem a meghalóra. Így nagyon kevés adatot tudsz használni, másrészről mire is akarod módosítani a GDT-t vagy az IDT pontosan? 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. 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.

3. azért, mert a SOMETHING_MALICIOUS bármi lehet, akár kód is. Logikus, hogy valamit akarsz kezdeni az emelt jogaiddal, nemde?

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, valamint ha az ABI nem használna egy GPR-t se. 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, és annak az esélye, hogy nem rontasz el valamit injektálás közben.

5. jó, kikényszerítetted. Tovább hogy? Mit módosítasz és mire?

6. ezt tényleg ennyire nem értitek? 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, 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, azaz ez userspace-supervisor váltás, így a CPU a TSS.RSP0 pointerében mutatott vermet fogja használni, és az egész problémakör fel sem merül. Bőven elég, ha a syscall fix helyre mappelt, futtatható lapon van, lásd linux-gate.so.1. Fogadjunk, el sem olvastad az általam linkelt oldal "Security considerations" fejezetét.

Az meg, hogy egy userspace alkalmazás csak adatlapot kérhet, szerintem biztonsági okokból nyilvánvaló. 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ő.

Egy szó mint száz, értem az elméletet, de kétlem, hogy a sok limitáció miatt gyakorlatba átültethető lenne, szóval hol a proof of concept? Addig maximum annyit hiszek el, hogy ez a sérülékenység alkalmas egy jó randa DoS-ra.

"Az meg, hogy egy userspace alkalmazás csak adatlapot kérhet, szerintem biztonsági okokból nyilvánvaló. 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ő."

Mi van pl. a JIT compilerekkel?

ezt tényleg ennyire nem értitek?

:))))))

Ezt PaXTeam-nek beírni - aki az egész "runtime code generation control" témát kitalálta és implementálta - különösen pikáns.

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

És a dlopen hívás szerinted mi és hol fut le? A ld.so vajon mi? ;)

BaT: mikor kell a JIT compilernek módosítani a saját kódját? Ha meg ugyanabban a security contextben van a compiler és a lefordított futó kód, az enyhén szólva is aggályos. Elég érdekes lenne, ha pl egy java bytecode módosítani tudná az őt futtató javavm kódját.

Hunger: lehet, hogy ő implementálta, de ettől függetlenül azt írta, hogy "de annak semmi koze az NX-hez", holott ez egyszerűen nem igaz, tekintettel arra, hogy kerneltől kért memóriában, generált kódot futtat a sérülékenység. Lehet, hogy baromi nagy koponya, de most akkor is figyelmetlen volt, és nem olvasta el az attack 3. és 7. pontját.

A dlopen hívás pedig (implementációtól függetlenül) egy darab, jól körülhatárolható, könnyen ellenőrizhető pont, ahol legálisan kódot mappelhet az alkalmazás az address space-ébe. Ha a shared libraryn kívül bármilyen más kódot be tud illeszteni egy app a memóriába, és le is tudja futtatni azt, akkor ott folyton biztonsági problémák lesznek, nemcsak itt.

Na de most már tényleg unom, mutasson valaki egy konkrét példát, ahol tényleges privilégiumszint emelésre használja ezt, és nemcsak megfekteti vele a gépet. Addig is ez nem más, mint denial of service.

mikor kell a JIT compilernek módosítani a saját kódját?

A JIT compiler nem módosítja a saját kódját, hanem új kódot hoz létre ("runtime code generation"), amihez kell memória írás, majd futtatás. Az exploitnak még csak erre sincs szüksége, elég bemmapelni a kódot futtathatóként a megfelelő címre úgy, mint ahogy a ld.so is teszi a futtatható binárisok kódjával...

azt írta, hogy "de annak semmi koze az NX-hez", holott ez egyszerűen nem igaz, tekintettel arra, hogy kerneltől kért memóriában, generált kódot futtat a sérülékenység.

Nem feltétlenül, lásd feljebb. De ha még generált kódot akarna futtatni, abban sem állítja meg tipikusan semmi.

Lehet, hogy baromi nagy koponya, de most akkor is figyelmetlen volt, és nem olvasta el az attack 3. és 7. pontját.

Nem. Te nem érted a kernel működését és memóriakezelést. :)
Meg úgy általában hatalmas tárgyi tévedéseid vannak a témában...

A dlopen hívás pedig (implementációtól függetlenül) egy darab, jól körülhatárolható, könnyen ellenőrizhető pont

És a kernel, majd ezt a user címtérben futó kódot fogja ellenőrizgetni valami mágikus módon, vagy mégis hogy képzeled? :)

Ha a shared libraryn kívül bármilyen más kódot be tud illeszteni egy app a memóriába

Mi tartja vissza a támadót, hogy az exploit shared library legyen? ;)

> de ettől függetlenül azt írta, hogy "de annak semmi koze az NX-hez", holott ez egyszerűen nem igaz, tekintettel arra, hogy kerneltől kért memóriában, generált kódot futtat a sérülékenység.

azert, mert lehet ugy is futtatni (es esetleg megakadalyozni) az adott syscall utasitast, meg nem jelenti azt, hogy mas, megtilthatatlan mod nem letezik. lentebb irtam is egyet (sajat cimre linkelni magat az exploit executable-t). mindebbol az kovetkezik, hogy az NX-nek semmi koze hozza, *nem* tudod igy megakadalyozni a hiba kihasznalasat. de ha megis, akkor ird le, mert te leszel az elso a vilagon, akinek ez sikerult.

> Lehet, hogy baromi nagy koponya, de most akkor is figyelmetlen volt, és nem olvasta el az attack 3. és 7. pontját.

kevesebb eszt kene osztogatnod es ugy altalaban nem feltetelezni, hogy jobban tudod ezeket a dolgokat, mint en ;).

> A dlopen hívás pedig (implementációtól függetlenül) egy darab, jól körülhatárolható, könnyen ellenőrizhető pont, ahol legálisan kódot mappelhet az alkalmazás az address space-ébe.

miert, mi akadalyozza meg a programot abban, hogy ne dlopen-t hasznalva mappeljen kodot a memoriaba?

> Ha a shared libraryn kívül bármilyen más kódot be tud illeszteni egy app a memóriába, és le is tudja futtatni azt, akkor ott folyton biztonsági problémák lesznek, nemcsak itt.

lattal te mar java/javascript JIT forditot? vagy csak egy libffi-t (cpython hasznalja pl.)?

> 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.

"mibol gondolod, hogy 'a GP handler vegez'?"
Ha nem végez, akkor csak megfektetted a gépet, de nem jutottál root privilégiumhoz.

"nem ertem milyen keves adatrol beszelsz. ott a teljes cimterem. meg a kernele is."
Csak néhány bytenyi adat fér el a GPR-ekben, nem a teljes címtér...

"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."

Mégis, milyen saját kódról beszélsz? Leírtam már világosan, 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, és azt a programot is, amire a gate mutat! 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.

pl:
rsp=IDT+14*16-x (pl page fault gate-je, x-et úgy kell megválasztani, hogy rdx kerüljön az IDT+14*16-ra)
legalább 5*8 byte garbage
rax=garbage, nem használhatod
rbx=kevés egy gatehez
rcx=garbage
rdx, rsi=(gate adatai, base address=ahová az rdi kerül a push során)
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
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?
És bizony azt is jelenti, hogy minden, 14-nél nagyobb indexű exceptionnek érvénytelen lesz az IDT entryje. Így már világos?

"nem ment, de ez nem is erdekes."
Ez megint egy szemenszedett hazugság. Nagyonis ment, a syscall prologue is, és a CPU is GPF-kor belementi a flageket, kód és verem szelektorokat és címeket, valamint opcionálisan még egy hiba kódot is. A GPR-ek max ezek után kerülhetnek bele, ezért nemhogy érdekes, hanem egyenesen nélkülözhetetlen, mert ezeket mind figyelembe kell venned, ha pozicionálni akarod az injektált adatokat.

Nem érdekel, hogy ennyire nem értesz hozzá, vagy csak ennyire hülyének tetteted magad, részemről innentől skip, míg nem mutatsz egy működő kódot. Agyő!

> 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 :).

"a bug triggerelesenek a pillanataban a userland taszk el es virul (a kernel epp visszaterni keszult hozza, ugyebar), koszoni szepen."
Vegyél vissza az arcodból, mert el vagy tévedve. A részletek igenis számítanak, mert ha nem figyel rá az ember, úgy el fog taknyolni, mint most Te.

A bug triggelésekor szó sincs arról, hogy a kernel épp visszatérne hozzá, a userland task MÁR NEM ÉL is virul, tekintettel arra, hogy új exception (pl az általad módosított PF ISR) csak akkor hívódhat, ha a GP handler már végzett, és kivágta a hibás taskot.

1. "A" task syscall
2. "A" task sysret, GPF
3. "A" GPF handler indul (injektálás)
4. "A" GPF visszatér, de nem a meghaló taszkra
5. "B" PF hívódik, ezzel triggerelődik egy nemlétező task memóriájában egy kód... na ez epic fail

Plusz itt egy kis lista arról, amiben tévedsz még:
"> legalább 5*8 byte garbage - miert? kontrollalhato egy jo resze."
Bizonyísd be! 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.

"> rcx=garbage - kontrollalt (max nem idealis IDT entry-nek, de pl. tokeletes tetszoleges ops strukturaban fuggveny pointer felulirasara)."
Ha ezt befolyásolni tudnád, akkor az egész syscall értelmetlen lenne. Milyen jó, hogy Te okosabb vagy, mint az Intel és az AMD mérnökei együtt!

"siman felul lehet irni egy processz uid-jat."
Oké, de melyikét? Azt, amelyiket épp most lőtt ki a GP handler? :-D Muhahahaha

"es az kit erdekel? ideiglenes allapot, jol fesult exploit elso dolga visszaallitani az eredeti tartalmat"
Amit mikor is mentesz le? A syscall handler és GP handler hívás között? Muhahahahahahahahahahaha. Looser.

>> "siman felul lehet irni egy processz uid-jat."
> Oké, de melyikét? Azt, amelyiket épp most lőtt ki a GP handler? :-D Muhahahaha

vagy inkább a parent (shell, vagy tetszőleges köztes támadási vektor, pl. httpd) processzét, amelyből az exploit indításra került, vagy az exploit eleve forkol egy childot... különösen nevetséges, hogy pont azokon a részleteken rugózól, amelyek a leginkább triviálisak és tízcsilló publikus kernel exploitot is találhatsz mintának, amelyekben ezek a kérdések már meg vannak válaszolva. :)

> Looser

Hát, aki itt giga nagyot égett most az te vagy... ;)

szoltam gyorsan a sracoknak, mert ilyen buli reg volt mar, mint most lesz ;). csapjunk is a kozepebe.

> Vegyél vissza az arcodból, mert el vagy tévedve. A részletek igenis számítanak, mert ha nem figyel rá az ember, úgy el fog taknyolni, mint most Te.

hogy mennyire szamitanak a reszletek, az ki fog derulni, szerintem keszitsd a kotszert, mert kicsit fajni fog ;).

> A bug triggelésekor szó sincs arról, hogy a kernel épp visszatérne hozzá, a userland task MÁR NEM ÉL is virul,
> tekintettel arra, hogy új exception (pl az általad módosított PF ISR) csak akkor hívódhat, ha a GP handler már
> végzett, és kivágta a hibás taskot.

a userland taszk el (van cimtere, stb), mivel kepes vegrehajtani az ominozus syscall-t. meg mindig teljes pompajaban letezik, amikor a kernel a sysreturn-hoz erkezik. ez kivalt egy GPF-t (aminek a vegrehajtasa soran ugye intel procikon nincs stack switch), cserebe a taszk meg mindig letezik. a GPF kezelo futasa *kozben* okoz a jol megkonstrualt exploit payload valamit, aminek hatasara a control flow *elterul*, es a kernel GPF handlere *nem* fut le teljes egeszeben, sot igazabol csak nagyon kis resze, ami asm-ben van, a C szintu kezelo (ahol signal handling, task kill, stb tortenhetne) *nem* hivodik mar meg. a kis moricka abradon bemutatva:

> 3. "A" GPF handler indul (injektálás)

*itt* rovid uton page fault/akarmi tortenik, ami az exploit altal kivant modon elteriti a control flow-t

> 4. "A" GPF visszatér, de nem a meghaló taszkra

^^^^^^^^^-> ilyen allat nincs, mert a GPF kezelo futasa mar korabban megszakitodott (exploit altal szandekoltan), es mas tortenik. igazabol ha az exploit iroja nagyon akarja, akkor a piszkos munka elvegeztevel meg akar ide is visszaterhet, bar tipikusabb egy direkt exit() hivasa ilyenkor (esetleg ha tul nagy volt a memoria korrupcio es tul sok munka lenne visszaallitani valami konzisztens allapotot, akkor szokas meg alvos vegtelen ciklusba vinni ezt a taszkot).

> Bizonyísd be! 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? :) azt vagod, hogy az egesz exploit azert letezhet, mert a kernel a userland altal meghatarozott vermet kezdi el hasznalni?

> Ha ezt [rcx] befolyásolni tudnád, akkor az egész syscall értelmetlen lenne.

ha elolvasod *es* megerted a nevezett mernokok altal irt doksit, akkor megtudod, hogy az rcx erteke egy userland-es memoria cim, nem mellesleg a syscall utani utasitas cime. mivel a syscall cimet te kontrollalod, igy ezen keresztul az rcx-be kerult erteket is. idezet linux kodbol: movq RIP-ARGOFFSET(%rsp),%rcx

> Oké, de melyikét? Azt, amelyiket épp most lőtt ki a GP handler? :-D Muhahahaha

mivel a GPF handler semmit nem lo ki (el sem jut odaig a kernel kod, hogy barmi ilyet tehessen), ezert akar az exploit processz sajat uid-jat is lehet modositani. egyeb korulmenyek miatt ez lehet a kezenfekvo valasztas de akar lehetetlen is (pl. tul sok korrupcio miatt nem lehet visszaengedi az adott taszkot userland-be).

> Amit mikor is mentesz le?

minek mentsem le, amikor ki tudom olvasni bzImage/vmlinux/System.map/stb-bol? vagy rekonstrualni tudom disasm alapjan (bizony, ezek a franya exploit irok kepesek ilyet elkovetni, de te nyilvan olvastal mar ilyen kodot, nem kell bemutatni ;).

> A syscall handler és GP handler hívás között? Muhahahahahahahahahahaha. Looser.

nem, a GPF handler kenyszeritett megszakitasa utan meghivodo exploit kodbol.

konkluzio: nagyobb balfasz vagy, mint eloszor mutattad, de hajra, csinalj meg nagyobb hulyet magadbol ;).

"GPF kezelo futasa *kozben* okoz a jol megkonstrualt exploit payload valamit, aminek hatasara a control flow *elterul*"
Sok a duma. Hogyan? Egyetlen egyszer beinjektálhatsz kb 100 összefüggő adat byte-ot, aminek bizonyos helyein kötött értékek vannak, és ettől persze probléma nélkül eltérül a kód. Mutasd mester, hogyan!

"> 3. "A" GPF handler indul (injektálás)
*itt* rovid uton page fault/akarmi tortenik"
Mitől? Hogyan? Azzal váltod ki a PF-et, hogy átírod az IDT-t? Azt bizony triggerelni is kéne, és te ugye kódot nem futtatsz, csak egyetlen adatstruktúrát írsz felül.

"na es honnan jonnek ez az ertekek? nahat, csak nem az epp felbeszakitott userland taszk regiszter kontextusabol? :)"
Nem, a cpu shadow registereiből jönnek. Várjál, súgok, Intel Manual vol 3. 3.4.3-as és 5.14.2-es fejezet.
Egyébként meg tessék, szeretném látni, hogy rsp-n kívül bármelyiket módosítod úgy, hogy az ne okozzon egyből exceptiont!
Azért ennyire alap x86-os mechanizmust nem ismerni elég égő egy kernel fejlesztőnek.

"mivel a syscall cimet te kontrollalod, igy ezen keresztul az rcx-be kerult erteket is"
Ha kicsit visszavennél az arcodból, és elovastad volna az attackot rendesen, akkor tudnád, hogy az CSAK EGY BIZONYOS címről működik, azaz rcx nagyon is kötött. Csak akkor működik az egész, ha rip+sizeof(syscall)>2^(membusz szélesség).

Megvannak a kötszerek, Julien?

Eddig kb ennyi értelme van a hozzászólásaidnak (mivel kódot, barátom, azt bizony nem mutattál egy bitet se).
---------------------------------------
1. átírni valahol valami kernel adatot
2. ???
3. root prompt!
---------------------------------------

> Egyetlen egyszer beinjektálhatsz kb 100 összefüggő adat byte-ot,

az elobb meg azt irtad, hogy "max 62 byte áll rendelkezésedre" ;)

> ...aminek bizonyos helyein kötött értékek vannak, és ettől persze probléma nélkül eltérül a kód.

ez az, amihez el kell olvasni az adott kernel kodjat, es megnezni hogy a data/control flow hol kezd el fuggeni a verem (exploit altal kontrollalt) tartalmatol. erre termeszetesen nincs altalanos valasz, eseti megoldast igenyel. pl. linux-nal (ami jelenleg nem, de par eve serulekeny volt) az alacsony szintu page fault handler egyik elso dolga a userland kontextus lementese utan a thread_info adatstruktura megkeresese - ez pedig tortenetesen a kernel verem legtetejen van, innentol kezdve game over.

> Mutasd mester, hogyan!

ha azt szeretned, hogy megtanitsalak kernel exploitot irni, akkor sajnos rossz hirem van, nem tudsz hozza eleget, nekem meg nincs annyi idom, hogy az alapoktol kezdve elmagyarazzam egy proceszor meg egy kernel mukodeset. viszont ujfent ajanlom publikus kernel exploitok olvasgatasat, sokat megertenel beloluk (vagy nem ;).

> Mitől? Hogyan? Azzal váltod ki a PF-et, hogy átírod az IDT-t?

ha mar szobahoztad, jobb helyeken az IDT read-only, tehat felulirni eleve nem egeszseges. de amugy nem, a PF-t nem ez valtja ki, hanem mint fentebb irtam, pl. egy exploit altal kontrollalt pointer hasznalata. ha meg remlik amokfutasod eleje, akkor nergal emlitette a swapgs problemat, ebbol talan el tudod kepzelni, mi minden lehetseges PF kivaltasara.

> Azt bizony triggerelni is kéne, és te ugye kódot nem futtatsz, csak egyetlen adatstruktúrát írsz felül

es? mi tortenik, amikor sajat tartalommal felulirok egy fuggveny pointert tartalmazo strukturat? pedig csak adatot irtam felul ;).

> Nem, a cpu shadow registereiből jönnek.

es a shadow regiszterekbe honnan kerulnek a GPF soran a kernel veremre lementett adatok? teleportacio? ;) na? userland kontextus (amit epp visszaallitott a kernel sysreturn elott) vagy nem userland kontextus?

> Egyébként meg tessék, szeretném látni, hogy rsp-n kívül bármelyiket módosítod úgy, hogy az ne okozzon egyből exceptiont!

popf. en nyertem? ;)

> Azért ennyire alap x86-os mechanizmust nem ismerni elég égő egy kernel fejlesztőnek.

a sracok szoltak, hogy ezzel a teljesitmennyel lassan atveszed a hupmeme listan a vezetest :).

> Ha kicsit visszavennél az arcodból, és elovastad volna az attackot rendesen, akkor tudnád, hogy az CSAK EGY BIZONYOS címről működik,
> azaz rcx nagyon is kötött. Csak akkor működik az egész, ha rip+sizeof(syscall)>2^(membusz szélesség).

en nem csak elolvastam, de veled ellentetben meg is ertettem ;). szoval nezzuk: aszondod van egy fasza keplet a rip-re. nem igazan igaz, de tegyuk fel, hogy csak pillanatnyi fogalmi zavar volt nalad (eleg hosszuak nalad ezek a pillanatok mondjuk) es tudod mi a kulonbseg a virtualis es fizikai cimek kozott es csak siman azt akartad mondani, hogy a GPF-t non-canonical rip valtja ki sysreturn-nel. a kerdes az, hogy miert feltetelezed, hogy rcx erteke sysenter utan == rcx erteke a sysreturn pillanataban? pedig a szalban mar tobbszor is volt rola szo, hogy mennyi modszer van ennek megvaltoztatasara. szoval ez a "CSAK EGY BIZONYOS címről működik" ugy baromsag, ahogy van (nem kis vicc, hogy a sajat kepleted se egy cimet ir le, hanem egy egesz intervallumot, raadasul off-by-one van benne es pontosan azt az egy rip erteket hagyod ki vele, amire nergal peldaja epul ;).

> Eddig kb ennyi értelme van a hozzászólásaidnak (mivel kódot, barátom, azt bizony nem mutattál egy bitet se).
> ---------------------------------------
> 1. átírni valahol valami kernel adatot
> 2. ???
> 3. root prompt!
> ---------------------------------------

2. a kernel az exploit altal kontrollalt adatot (tipikusan pointert) nem szandekolt celra hasznalja, pl. exploit altal beadott fuggveny pointeren keresztul szepen meghivja az exploit ring-0 reszet. persze ezt is leirtam mar parszor, de mivel a Dunning–Kruger hatas alatt vagy, valoszinuleg megmaradsz hulyenek ;).

"az elobb meg azt irtad, hogy "max 62 byte áll rendelkezésedre" ;)"
Merthogy a maradék byteokat nem tudod átírni. Mi nem világos ebben?

"ha azt szeretned, hogy megtanitsalak kernel exploitot irni"
Nem. 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.
Semmivel nem támasztottad alá ugyanis a mondandód (azon kívül, hogy személyeskedsz 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)

"de amugy nem, a PF-t nem ez valtja ki, hanem mint fentebb irtam, pl. egy exploit altal kontrollalt pointer hasznalata"
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.

"popf. en nyertem? ;)"
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?

"en nem csak elolvastam, de veled ellentetben meg is ertettem ;)"
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?

"aszondod van egy fasza keplet a rip-re. nem igazan igaz, de tegyuk fel"
Elovastad, meg is értetted, mi? ROTFL, ROTFL, ROTFL. Szerinted ez mit jelent?
"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?

"exploit altal beadott fuggveny pointeren keresztul szepen meghivja az exploit ring-0 reszet. persze ezt is leirtam mar parszor"
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á.

Szerintem abbahagyhatod, mert sikerült eléggé lejáratnod magad. (Segítek, azzal, hogy 1. nem tudsz olvasni vagy szövegérteni, 2. dumálsz, de alátámasztani semmit sem tudsz, sem linkkel, sem példakóddal, se semmivel).

Semmivel nem támasztottad alá ugyanis a mondandód (azon kívül, hogy személyeskedsz 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)

Ugyan nem vagyok senkinek csicskasa, de azt azert remelem tudod, h akit most elkuldesz a fenebe nemreg eletmudijat kapott a temaban foglalt ket evtizedes tevekenysegeert es az elkepzeleseit (mint peldaul az ASLR) nem kisebb cegek kezdtek el alkalmazni a gyakorlatban, mint az Apple, a Microsoft, mert a gyakorlatban is bizonyitottak? Valamint a grsec (ami nelkul a kernel csak egy felkaru orias) PaX modulja sem egy elirasnak koszonheti a nevet? Az, h Linus hozzaertese es erzekenysege az IT sechez a beka segge alatt van, nem spender es pax sara.

---
pontscho / fresh!mindworkz

> 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 ;).

"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.

> Hol? Csak mondtad, de nem mutattad meg.

ertelmes embernek ennyi eleg. szoval ezzel csak magadat minosited (ujfent ;).

> 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).

a 'megis mi' arra vonatkozott, hogy honnan jott az az otlet, hogy az exploit barmiert is "5 darab 42-es értéket tegyen a verembe". azert mert turdus@hup ilyet szeretne latni, az meg kb semmit se jelent. szoval all a kerdes, hogy jon ez most ide?

> Már bocs, de Te vagy az, akik csak vagdalkozik, én konkrét Intel Manual fejezetreferenciákkal támasztottam alá állításomat.

egyetlen egyszer hivatkoztal erre: "Intel Manual vol 3. 3.4.3-as és 5.14.2-es fejezet", amikor azt probaltad megmagyarazni, hogy honnan szarmaznak a proci altal kivetel soran lementett regiszter ertekek. en azt allitottam, hogy az adott esetben azok bizony a userland regiszter kontextusbol jonnek (tehat userland kontroll alatt allnak es nem 'garbage' ertekek), amire te hadovaltal olyat, hogy 'shadow regiszterek'. aztan amikor megkerdeztem, hogy ezek a 'shadow regiszterek' honnan nyerik a tartalmukat, arra nem valaszoltal. miert? nem tudod vagy nem akarod beismerni, hogy igazam volt? ;)

> 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

ez kesz, te megnyerted 10 evre elore a balfasz@hup cimet ;). lentebb mindjart atnezzuk, mit sikerult eddig 'bizonyitanod' ;).

> 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.

ez a 'sehogy' most 'pofazas' vagy 'bizonyitek' akart lenni? ;). hahaha, ember, legalabb a sajat tanacsaid kovesd neha. azt pedig leirtam, hogyan lehet PF korabban, de mivel olvasni (se) tudsz, idemasolom megint:

"ez az, amihez el kell olvasni az adott kernel kodjat, es megnezni hogy a data/control flow hol kezd el fuggeni a verem (exploit altal kontrollalt) tartalmatol. erre termeszetesen nincs altalanos valasz, eseti megoldast igenyel. pl. linux-nal (ami jelenleg nem, de par eve serulekeny volt) az alacsony szintu page fault handler egyik elso dolga a userland kontextus lementese utan a thread_info adatstruktura megkeresese - ez pedig tortenetesen a kernel verem legtetejen van, innentol kezdve game over."

> Így van, és a popf erre nem alkalmas. Ezzel nem lehet tetszőleges értéket tölteni az rflagsbe.

senki nem beszelt tetszoleges ertekrol, hanem csak kontrollrol. te sok mindenrol azt allitottad, hogy garbage, ami nem igaz.

> 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.

speciel nem igaz, mert IF-t lehet allitani userlandbol is, csak megfelelo IOPL kell hozza. megint felsultel ;).

>> "(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ó.

egyreszt az idezett mondatom es az 'egyetlen egy lineáris cím létezik, ahonnan az exploit kiszanálható' kozott nincs logikai osszefugges, masreszt nem igaz, hogy egyetlen cim letezik. tudod, nergal is leirta:

•Any method to set the target of sysret to a non-canonical address can potentially be used.

azt erted, hogy mi a kulonbseg a 'the non-canonical address' (amit nem irt) es az 'a non-canonical address' (amit irt) kozott? ja varj, angollal eleg hadilabon allsz, szoval nergal sem allitotta, hogy csak egyetlen cimrol triggerelheto a hiba, hanem ellenkezoleg, barmilyen non-canonical cim jo. o csak adott egy konkret peldat egy lehetseges (relative egyszeru) modon beallithato non-canonical rip-re, de irt mas modszereket is, amivel tetszoleges rip beallithato (This includes ptrace, sys_sigreturn, sigaction, execve, possibly others). nem mellesleg ez mar mind tobbszor elhangzott a szal folyaman, de hat mint tudjuk, szereted az onegetest ;).

> Ez a cím cpu modelltől függően változik, de egy processzoron mindössze egyetlen egy ilyen van. Tudod kéne.

nagy tevedes, nem valtozik, mivel minden letezo amd64 procin 48 bit az effektiv virtualis cimter merete (az mas kerdes, hogy a te kis buksidban erosen kavarodik a fizikai meg virtualis cimterek fogalma ;). es nem, a non-canonical address nem egy cimet takar, hanem egy egesz cimtartomanyt. "Tudod kéne." ;)

> 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?

egyreszt nem igaz (C-ben ILP32 eseten INT_MAX+1 eredmenye 32 bites, tehat elvileg elferne az eredmeny az int tipusban, de megis tulcsordulas van ehelyett, na erre varrjal gombot :), masreszt azt mondd el, hogy (1<<47)-2+2 eseten mi csordul tul pontosan. mert a regiszterek (rip-et is beleertve) nem 47 bitesek. magyaran bebuktad ;).

> > "a kernel sajat, mar reg a memoriaban levo kodja fogja mit sem sejtve dereferalni"
> A GP handleren belül?

ott, ahol az exploit altal felulirt fuggveny pointert a kernel maga felhasznalna. az meg attol fugg, hogy melyik fuggveny pointert irja felul az exploit. ha IDT-ben a PF deszkriptort modositja (ami csak egy lehetseges exploit technika, es egyaltalan nem biztos, hogy kivitelezheto az adott kernelnel, mivel az IDT lehet read-only), akkor az elso triggerelt laphibanal megtortenik ez, ha mast ir felul, akkor meg maskor.

> Oszt miért? Az eredeti linux GP handler tudtommal nem dob PF-et a task állapot lementését követően csak úgy.

dob az, ha ervenytelen memoriacimet akar elerni :), pl. gs-en keresztul percpu adatokat, vagy thread_info-n keresztul barmit.

> 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.

a klasszikus bof pelda volt a "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" kerdesedre, GPF sehol nem szerepelt benne. de mivel valoszinuleg a bof-bol is csak a maganhangzokat erted (ez a rohadt angol, mi? ;), nem csodalom, hogy ez nem jott at ;).

> 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.

en a klasszikus bof-val probaltam szemleltetni (ugy latszik mindhiaba :), hogy mikor/hogyan tortenik az exploit altal kontrollalt fuggveny pointer felhasznalasa. a kernel exploitnal soha senki nem mondta, hogy megvarjuk a GPF handler lefutasat, bar igazabol olyan exploitot is lehet irni (l. valahol fentebb a multi-processz exploit dolgot).

> 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.

aki itt visit, az szerintem a hozzaertok tomkelege, ill. mas okbol ugyan, de nemsokara te is, mert most atnezzuk, hogy mi mindent sikerult eddig itt osszehordanod es 'bizonyitanod', a.k.a. best of turdus@hup ;). azoknak, akik kevesbe ertenek/kovettek a dolgokat, minden egyes felsorolt allitas hamis.

1. Ez egy baromság szerintem.
2. Tekintettel arra, hogy a SYSENTER/SYSEXIT utasítássokkal ellentétben a SYSCALL/SYSRET nem használ stacket és nem is vált, az exception handler meg x86-on NEM tudja használni a ring3-as stacket.
3. az exception handler paramétereit meg közvetlenül a ISR hívás előtt, a CPU pakolja a stackbe, így ring3-ról semmiképp, de még ring0-ról sem befolyásolható?
4. ["Any method to set the target of sysret to a non-canonical address can potentially be used"] Könnyű mondani, de ezt nem lehet kivitelezni.
5. A syscall hívásakor nincs rá mód, hogy ring3-ról befolyásold.
6. ha meghívódik a GP handler, az minden értelmes kernelben azzal kezd, hogy kivágja a hibát okozó processt a francba
7. a vezérlés nem adódik csak úgy a lementett GPR-ekre, ennek kivitelezése ráadásul szinte lehetetlen, mivel elég gyorsan törlődni fog a memóriából (megszűnik a process!!!).
8. ez a leírás akkor is egy rettenetesen hülye kernelt feltételez, nevezetesen enged írható,futtatható frame-t mappelni
9. Ha egy kernel ezt engedi, akkor nem kell hozzá sysret+GP hókuszpókusz, hogy feltörd.
10. A lényeg, hogy ami lefut, azt nem tudod befolyásolni
11. ami nagy valószínűséggel invalid opcode vagy újabb GP miatti double faulthoz vezet még mielőtt a lényeges kódot végrehajtaná
12. Az biztos, hogy vissza nem kerül már a vezérlés az adott process-re.
13. Értelmes kernelek GP handlerben kiveszik a ready queue-ból az aktuális processt, majd berakják a terminating queueba, és soha többé nem allokálnak CPU-t neki
14. Szóval ha valamit akarsz kezdeni vele, azt bizony a GP handlerben kell megtenned, még mielőtt egy új process address-space mappelődne be.
15. ami mellesleg elég valószínű, hogy a sysret hívásakor eleve megtörtént, mert a speckó GPR-ek miatt érvénytelen volt a syscall, és a hibakezelő ág futott le
16. Értem, hogy elméletileg lehetséges lenne
17. kell hozzá egy koncepcionálisan elrontott kernel is (futtatható kód mappelési lehetőség),
18. ami ráadásul még fittyet hány a CPU által biztosított jópár védelmi mechanizmusra (IST, NX stb) is.
19. amikor a GP handler végez, és meghívja az iret-et, egy új taskra fog visszakapcsolni, és nem a meghalóra
20. 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.
21. pontosan akkor lenne kontrollálható, ha CPU és a GP handler nem mentene egyéb adatot a verembe a GPR-eken kívül
22. csak még tovább csökken az injektálható adatmennyiség, és annak az esélye, hogy nem rontasz el valamit injektálás közben.
23. 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, ergo a 7. pont ("Jump to syscall instruction at (1<<47)-2") GPF-et fog okozni
24. azaz ez userspace-supervisor váltás, így a CPU a TSS.RSP0 pointerében mutatott vermet fogja használni
25. Bőven elég, ha a syscall fix helyre mappelt, futtatható lapon van, lásd linux-gate.so.1.
26. Az meg, hogy egy userspace alkalmazás csak adatlapot kérhet, szerintem biztonsági okokból nyilvánvaló.
27. 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ő.
28. Egy szó mint száz, értem az elméletet
29. kerneltől kért memóriában, generált kódot futtat a sérülékenység
30. A dlopen hívás pedig (implementációtól függetlenül) egy darab, jól körülhatárolható, könnyen ellenőrizhető pont, ahol legálisan kódot mappelhet az alkalmazás az address space-ébe.
31. Ha a shared libraryn kívül bármilyen más kódot be tud illeszteni egy app a memóriába, és le is tudja futtatni azt, akkor ott folyton biztonsági problémák lesznek, nemcsak itt.
32. Ha nem végez, akkor csak megfektetted a gépet, de nem jutottál root privilégiumhoz.
33. Leírtam már világosan, 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, és azt a programot is, amire a gate mutat!
34. 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.
35. legalább 5*8 byte garbage
36. rax=garbage, nem használhatod
37. rbx=kevés egy gatehez
38. rcx=garbage
39. r11=garbage, a kódodban át kell ugrani
40. max 62 byte áll rendelkezésedre
41. És bizony azt is jelenti, hogy minden, 14-nél nagyobb indexű exceptionnek érvénytelen lesz az IDT entryje
42. valamint opcionálisan még egy hiba kódot is
43. A bug triggelésekor szó sincs arról, hogy a kernel épp visszatérne hozzá, a userland task MÁR NEM ÉL is virul
44. új exception (pl az általad módosított PF ISR) csak akkor hívódhat, ha a GP handler már végzett, és kivágta a hibás taskot
45. Ha ezt befolyásolni tudnád, akkor az egész syscall értelmetlen lenne
46. Ha kicsit visszavennél az arcodból, és elovastad volna az attackot rendesen, akkor tudnád, hogy az CSAK EGY BIZONYOS címről működik, azaz rcx nagyon is kötött
47. Csak akkor működik az egész, ha rip+sizeof(syscall)>2^(membusz szélesség).
48. Mióta kontroll az, egyetlen egy bizonyos értéket állíthatsz csak be, hogy aktíválódjon a GPF?
49. 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

ez minden bizonnyal vilagrekord!

Igazad van turdus, ez a hiba nem kihasználható. Tévedett Rafal Wojtczuk biztonsági szakértő aki bejelentette a hibát (biztos jól be is fog égni a Blackhat konferencián, ahol előadást tart róla), tévedtek azok a Linux kernel fejlesztők, akik szokás szerint csendben javították a hibát még 2006-ban és ennek köszönhetően 6 éven keresztül aktívan kihasznált 0day volt. Tévedtek a FreeBSD, Xen, RedHat és Microsoftos fejlesztők is.

Szólj nekik, ideje visszahívni a security advisorykat!
"Credits to turdus, WINDOS developer" ;)

argp-nek mondd, ő írta a tweetet...

ennek ellenére a sajtótájékoztató helyett a másik véglet sikerült, persze nem véletlenül:

"Also, I'm hereby requesting that this issue *not* be embargoed. That let's all of us to go about fixing this quietly as our schedules allow.
(Note that I've avoided cc'ing LKML because of the local DoS exposure.)"

ezt a VendorSec-re írta Ernie Petrides, RedHat fejlesztő 2006. március 7-én. Szép csendben javították a hibát, a CVE részletei pedig jóideig nem voltak olvashatók még és utána is csak egy olyan szöveg került bele, hogy ez kizárólag csak a 2.6.16.5 előtti Linux kerneleket érintő hiba, semmi több. Naná, hogy nem foglalkozott vele senki (kivéve a Blackhatek, of course).

Persze ezzel a RedHat még saját magát is lábon lőtte. Annyira sikerült megint trükkösnek lenniük, hogy még a saját Xen kódjukban sem javították a hibát.

Szerinted mi azzal a baj, ha javitanak egy bugot, oda irjak, hogy van security vonzata es egy jo darabig, nem mondjak el a pontos mibenletet, minden Pistikenek ?

Azt mindketten tudjuk, hogy nem trivialis egy bugrol megmondani, hogy DoS-nal van -e komolyabb vonzata.
Altalaban egy honappal kesobb szokott kiderulni, ha barkit is erdekel ennek bizonyitasa, most 6 ev volt. (Altalban egy min. info leakkel kombinaltan, lehet kihasznalni, ha ki lehet)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerinted mi azzal a baj

Nincs jelentősége, hogy szerintem vagy szerinted mi a baj, mert a probléma adja magát... Pistikék a részletes leírás után se fognak tudni vele mit kezdeni (lásd turdus), aki meg ért hozzá, azt nem lehet megvezetni ilyen kamu DoS-ra való hivatkozással, amikor teljesen kontrollálható az egész.

Altalaban egy honappal kesobb szokott kiderulni, ha barkit is erdekel ennek bizonyitasa, most 6 ev volt.

Nem, most 6 évig volt egy aktívan kihasznált 0day egyesek kezében.

Altalban egy min. info leakkel kombinaltan, lehet kihasznalni, ha ki lehet

ROTFL, egy faszt, turdus te vagy az? :))

Ilyesefeleket Disclosure/Patch megnoveli kihasznalsok gyakorisagat.

"Sok kernel exploitot látsz? Vagy mégis miből általánosítasz?"
Nem csak kernel exploitot. Nem latok olyan sokat, de eleg ritkanak erzem manapsag, hogy egyetlen hibat onmagaban sulyosan ki lehet hasznalni.
Nyilvan erdekesebbek kombinalt exploitok, lehet ezert talalhat az ember tobb hivatkozast rajuk.

Ez az eset onalonak tunik. (Es eleg egyszerunek)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ilyesefeleket Disclosure/Patch megnoveli kihasznalsok gyakorisagat.

"Schneier's (and others) theorised model"

Elméleteskedni akarsz, mint turdus, vagy a valóságról beszélni?

Lásd eax által linkelt Immunitys anyagot: Hacking is not theoretical. Az esetek jórészében nem a Disclosure/Patch fázis után használják ki legnagyobb számban a hibákat, hanem még jóval előtte.

Ez a hiba is 0day volt és aktívan kihasználták egy ideje. Az Immunity se véletlenül hívja második verziónak most a szélesebb körben terjesztett CANVAS exploitot...

Nem latok olyan sokat, de eleg ritkanak erzem manapsag, hogy egyetlen hibat onmagaban sulyosan ki lehet hasznalni.

Egyrészről nem tudok mit kezdeni azzal, hogy te mit "érzel", másrészt abban a világban, ahol gond nélkül használnak ki 14 hibát egyetlen szoftverben a tetszőleges kódfuttatás eléréséhez, ott nincs is értelme egyetlen hiba szemszögéből nézni a dolgokat.

Ez az eset onalonak tunik. (Es eleg egyszerunek)

Igen? Vázold fel. :)

( turul16 v | 2012. 06. 19., k – 07:45 )

Linux miota workaroundolta ? RHEL 6 -rol nem latok infot, csak RHEL 5 van linkelve.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( turdus | 2012. 06. 22., p – 08:22 )

Na mi lenne, ha ezt a szánalmas vergődést abbahagynátok, és a publikus cuccaim megosztása (Hehehehe) helyett arra koncentrálnátok, amiről a topic szól? Igazán ráférne PaXTeamre egy kis segítség, mert szarul áll a szénája.

Ezennel megígérem, ha bárki be tudja bizonyítani PaXTeam alábbi három állítása közül legalább egyről, hogy nem baromság, akkor nyilvánosan bocsánatot kérek PaXTeamtől, és elismerem, hogy ez nemcsak szolgáltatásmegtagadásra, hanem privilégiumszint emelésre is jó ez a sebeshetőség.

PaxTeam 1. állítása
Meg lehet oldani, hogy az ISR hívásakor a CPU a szokásos kód és verem állapotok helyett 48 byte tetszőleges adatot tegyen a verembe

PaxTeam 2. állítása
Befolyásolni lehet, hogy milyen érték kerüljön a GP aktiválódásakor rcx regiszterekbe, 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

PaxTeam 3. állítása
Pusztán kerneladat átírásával, kód injektálás nélkül el tudja érni, hogy a GP handler futása a módosítást követően megszakadjon, és egy másik kódra adódjon a vezérlés, még mielőtt bármit is csinálna a GP handler.

Tudom, nehéz lesz, de tegyétek félre a vérpistike stílust, és próbáljatok meg legalább az egyikre érdemben, értelmes ember módjára bizonyítást adni.

Ezt felenk CPU bugnak tuno dolog ami workaroundolhato, vagy az Intelek szerint ez tenyleg jo otlet volt !?

Talan erdekelhet:
http://en.wikipedia.org/wiki/Return-oriented_programming,http://en.wiki… -nem csak libc -re, vonatkozik.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Ezt felenk CPU bugnak tuno dolog ami workaroundolhato, vagy az Intelek szerint ez tenyleg jo otlet volt !?"
Hibásan implementálták az AMD64 utasításkészletét. A sebezhetőség leírásában szerepel, hogy a GP mindjárt a sysret értelmezése elején keletkezik, szemben az AMD-vel, ahol a sysret utasítás legutolsó lépése a RIP ellenőrzés.

Köszönöm a linkeket, ismertem őket, de az a helyzet, hogy a return-to attack itt nem játszik, mivel a GP handler elején kell eltérítened, mert amikor visszatér, addigra a taskod már halott, így nem tudsz hivatkozni kódot.

1. nem implementaltak hibasan (Intel doksiban le van irva a sysret menete, nem olvastad?), max szerencsetlenul, mert eltertek az AMD-tol. amugy meg nem ez az egyetlen elteres a ketfele amd64 implementacio kozott (sot Intel meg sajat magaval sem volt mindig konzisztens, pl. korai P4 Xeon-okban nem volt NX).

2. tovabbra sincs fogalmad a ROP-rol, mi? ;)

jaj kis baratom, az ilyen 'ezt mondtad, bizonyitsd be' trukkok nalam nem mukodnek am ;).

> PaxTeam 1. állítása
> Meg lehet oldani, hogy az ISR hívásakor a CPU a szokásos kód és verem állapotok helyett 48 byte tetszőleges adatot tegyen a verembe

eloszor is citation needed (nem tudsz, tehat hazudtal, hogy ezt irtam). masodszor az exploit altal kivaltott GPF soran lementett regiszterek jo nagy reszerol pontosan tudjuk, hogy mit tartalmaznak, tehat kontrollaltak (cs/rip/ss/rsp/rflags/error code mind mind jol predikalhato vagy akar direkt megvalaszthato biteket tartalmaznak).

> PaxTeam 2. állítása
> Befolyásolni lehet, hogy milyen érték kerüljön a GP aktiválódásakor rcx regiszterekbe,

eloszor is az rcx egy regiszter, nem tobb. amugy meg man ptrace/execve/sigreturn.

> 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. avagy megint nem ertetted meg mit irtam (vagy szandekosan hazudsz). az rax tudvalevoleg (itt most nem rolad van szo ;) (sys)call clobbered regiszter, azaz megvaltozik az erteke a hivas soran, konkretan az amd64-en hasznalt ABI-k visszateresi erteknek hasznaljak. ebbol mindjart kovetkezik, hogy pontosan lehet tudni, milyen erteke lehet sysret-kor (adott syscall visszateresi erteke). a tobbi regiszter allapota pedig kernel fuggo, de tipikusan rendesek es visszaallitjak a userland kontextust, amennyire lehet. nem hit kerdese, olvasd el a relevans kernel kodot (pl. arch/x86/kernel/entry_64.S linuxnal).

> PaxTeam 3. állítása
> Pusztán kerneladat átírásával, kód injektálás nélkül el tudja érni, hogy a GP handler futása a módosítást követően
> megszakadjon, és egy másik kódra adódjon a vezérlés, még mielőtt bármit is csinálna a GP handler.

ugy altalaban lovesed sincs a ret2libc/ROP exploit technikarol, mi? ;) raadasul ennel a kernel bugnal meg csak erre sincs szukseg.

Ö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

Alj le egy picit es gondolkozzal.

Miert irtak volna ket CVE -t a dologrol, ha nincs biztonsagi vonzata ?
Miert hajottak verge valtozasokat a Linux kodjaban, 2006 -ban, a tobbszor belikelt git linkkel befejezve ? (Megnezheted a megelozo commitokat is)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Miert irtak volna ket CVE -t a dologrol, ha nincs biztonsagi vonzata ?"
Sosem vitattam, hogy van-e biztonsági vonzata. Nyilvánvalóan nem jó, ha felhasználói program kernelterületre tud írni. Abban kételkedtem csak, hogy az elméleti privilégiumszintemelés gyakorlatba átültethető, mert szerintem gyakorlatilag csak egy kernel crash előidézésére alkalmas. Ami persze elég rossz, ezért javítani kell.

> Öregem, nincs szoli a környéken? Miért égeted magad ennyire?

gyors korkerdes utan az egyertelmu eredmeny az volt, hogy te vagy az, akibol mar banyat lehetne nyitni ;).

> 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?

leirtam, hogy sikhulye vagy a temahoz (a pofad merete viszont forditott aranyban all a tudasoddal ;), arra meg nincs idom, hogy mindent lepesenkent elmagyarazzak. mellesleg van eleg informacio minden kerdesedre a neten, keresd meg.

> Tévedsz, én nem hazudok. Íme, itt írtad:
"> > legalább 5*8 byte garbage miert? kontrollalhato egy jo resze."

"kontrollalhato egy jo resze" != "48 byte tetszőleges adatot tegyen a verembe".

> Égés pont: +1

hazudtal, neked gyult ;)

> Helyes válasz: nem.

helyes valasz: te egy balfasz vagy. a sysret elotti regiszterallapotrol volt szo (mert ugye az fog a sysret altal kivaltott GPF soran lementodni a veremre), es az bizony a userland regiszter kontextus lesz, mivel a sysret feladata pontosan az, hogy visszaterjen userland-be es ehhez nem art, ha userland visszakapja a regiszterei tartalmat.

> 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...

te mar megint kevered a szezont a fazonnal. szo sem volt minden egyes utasitasrol meg veremmuveletrol. az volt a kerdes, hogy sysret altal kivaltott GPF soran honnan szarmazik a veremre lementett regiszterek tartalma. az pontosan egy utasitas, pontosan egy helyzetben. tovabbra is varom a valaszod, mert eddig csak tereltel jobbra-balra, de erdemben nem valaszoltal. csak nem nehez beismerni, hogy barom voltal? ;)

> É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

miert akarna egy exploit atirni a kodszegmens szelektort? eleg azt tudni, hogy mi az erteke, azzal mar lehet iranyitott felulirast csinalni a megfelelo helyen.

> Égés pont: +1

tovabbra is neked gyulik ;)

> Nem tudom, miért gondoltad, hogy ezeket az exploit teszi/tetteti a verembe, mikor direkt írtam, hogy a CPU.

...es a CPU honnan veszi azokat az ertekeket, amiket a verembe ir? manifesztalja fenybol meg kvarkokbol? vagy a kernel ill. sysret altal betoltott userland kontextusbol? ilyen nehez a felfogasod?

> Égés pont: +1

meg mindig neked gyulik ;)

> Ha rcx "csak" egy regiszter ebben a kontextusban,

az rcx barmilyen kontextusban egy regiszter csak ;)

> akkor mi akadályoz meg benne, hogy bemutass egy kódrészletet, ami felülírja?

minek irjak neked kodot, amikor leirtam (sot, nergal leirta mar) par modszert arra, hogyan lehet. ha ezek alapjan nem erted meg, akkor nem ertened meg a kodot se. masreszt pedig az en idom en osztom be, majd akkor szanok rad erdemi idot, ha ugy latom jonak, egyenlore csak kacagni jarok ide, mint ahogy sokan masok is ;).

> 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.

egyik felsorolt rendszerhivashoz sem kell modositani a syscall handler-t (rendes kernel kodja eleve read-only). esetleg el kene olvasnod a manpage-ket meg a hozzajuk tartozo kernel kodot, hmm?

> Égés pont: +1

ja, hat ezt is te szoptad be ;)

> 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 :-)

jesszusom, mi van? (azt vagod mire van a sigreturn pl?)

azt latom, hogy neked magas, mind majomnak a zongora, de legalabb magadban tartanad... mondom, olvasgass kicsit utana ezeknek a dolgoknak, mert igy csak egyre szanalmasabb a vergodesed ;/.

> Égés pont: +2

ez akkora allatsag volt fentebb, hogy megduplazom neked es kapsz 4-et is ;)

te> rax=garbage, nem használhatod
en> miert? syscall visszateresi erteke, siman lehet jo valamire. pl. 0-val felulirni"

tehat en nem a syscall hivas elotti rax ertek lementeserol irtam (mint ahogy te allitottad), hanem a syscall visszateresi ertekerol. magadat cafoltad meg, dupla pont jar erte ;).

> Ki mondta, hogy rax értéke visszatéréskor 0?

pelda volt egy jol tudhato es kontrollalhato syscall visszateresi ertekre.

> Semmi garancia nincs rá, hogy ugyanazzal a paraméterekkel meghívott syscall mindig ugyanolyan értékekkel tér vissza.

de van, ugy hivjak, hogy kompetens programozo, aki erti a dolgat. termeszetesen nem rolad van szo.

> 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"

ugyes csusztatas, mert sikerult szelektiven beidezni. volt annak a mondatomnak folytatasa is, remlik? azt miert hagytad ki? de ami kesik, az nem mulik:

> > konkretan az amd64-en hasznalt ABI-k visszateresi erteknek hasznaljak. ebbol mindjart kovetkezik, hogy pontosan
> > lehet tudni, milyen erteke lehet sysret-kor (adott syscall visszateresi erteke)

mit nem tud akkor az ember (marmint nem te, hanem a fentebb nevezett kompetens programozo) ezen kontrollalni?

> De ha, tegyük fel, legyen mindig nulla,

a 0 pelda volt csak, kulonbozo syscall-ok kulonbozo hasznos es jol kontrollalhato ertekekkel tudnak visszaterni (pl. llseek, mmap, stb).

> 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.

igy van.

> 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.

ezert kell olyan celt valaszatani, ahol ez nem tortenik meg. ettol (is) lesz majd megbizhato az exploit. ez az, amihez sok kodolvasas meg ugy altalaban alapos kernel ismeret szukseges.

> 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.

ez 0-day tudas, majd nyilvan veled osztom meg, mi? ;) amugy meg nezd meg spender par exploitjat, ott lesz minden, meg forraskod is.

> > "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.

szerinted egy syscall hogyan kozli userland-del, ha az adott muvelet valamiert nem sikerult? EINVAL/stb hogy kerulnek vissza userland-be?

> Égés pont: +1

ja, ez most nagyon beszoptad ;)

> > "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.

de kontrollalhato, mivel a vissza nem allitott regiszterek (pl. sysret-nel az rcx/r11) erteke is pontosan tudhato. esetleg neked kene utanaolvasni par dolognak? ;)

> De, van, nem is kevés. Írtam is párat, rablóból lesz a jó pandúr alapon.

neked alapveto hianyossagaid vannak, tehat a fenti allitasod nyilvanvalo hazugsag.

> Neked nincs lövésed az alacsonyszintű kernel rutinokról és az x86 CPU működéséről.

idaig te voltal az, aki felsult majdnem minden allitasaval, szoval jo lenne, ha vegre *erdemben* valaszolnal a felvetett kerdesekre. kezdheted pl. azzal, hogy milyen 47 bites regiszterek vannak amd64-en ;).

> Nemhogy szükség nincs rá, hanem nem lehet kihasználni

ahahahaha. hunger, te jossz ;)

> (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).

fraszt irtal te ilyet, en voltam az, aki elmagyarazta, hogy milyen lehetoseg vannak az adott hibak kihasznalasara, de te ebbol kb. semmit nem ertettel meg ;).

> 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

szerintem inkabb 10 folott voltal most, na meg ott van az a majdnem 50 best-of-turdus lista is ;)

Javits ki, ha tevednek, de nem kell feltelen ptrace/execve/sigreturn ahhoz, hogy triggerreld.
Ha kovetkezo utasitas cime nem canonikus az eleg, ez elerheto azzal is (ahogy fentebb irtak), mmapolsz a meg canontikus teruletre egy futathato lapot, es vegere teszel egy syscall-t.

Szerintem ezen hivasokat, azert emlitettek, hogy felhivjak figyelmet arra, hogy nem eleg csak letiltani az nmappolast arrol a teruletrol, mert maskep is lehet tamadni.

@PaxTeam: Azert nem minden contexusban igaz hogy rcx it csak egy register a sok kozul, mivel a sysret ill, syscall -rol beszelunk nem csak egy register, mert az elso olvassa, masik irja (rip+2) -vel.

@turdus:
Ahhoz, hogy gyoker legyel,kvazi eleg atirni a processt leiro structuraban , az effective uid-ot.

@turdus:
Nekem ugy tunik, hogy az epilogusban miutan a cucc vissza allitja a user registereket, meg kernel modbani cimrol dobja a #GP -t.
Mivel #GP szerint a hiba kernelbol johetett, nem igyekszik lecserelni az rsp -t kernel rsp -re, igy az user -e marad ott, a tobbi user registerrel egyutt.

(Meglepo modon az utasitas dokumentaltan, igy mukodik)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Ahhoz, hogy gyoker legyel,kvazi eleg atirni a processt leiro structuraban , az effective uid-ot."
Ez így van, itt viszont nem tudsz szofisztikáltan átírni egy uid mezőt, mert egyszerre több, mint 100 byte íródik, aminek a nagy részét ráadásul nem tudod kontrollálni, hogy mit tartalmaz.

"Nekem ugy tunik, hogy az epilogusban miutan a cucc vissza allitja a user registereket, meg kernel modbani cimrol dobja a #GP -t.
Mivel #GP szerint a hiba kernelbol johetett, nem igyekszik lecserelni az rsp -t kernel rsp -re, igy az user -e marad ott, a tobbi user registerrel egyutt."
Jó a meglátásod. Mivel a kernel nem cseréli le a userland rsp-t kernel rsp-re, ezért felhasználható arra, hogy tetszőleges címre íródjanak a user regiszterek. Ekkor azonban nem marad a user stack ott, ahol kéne. Ahhoz az kell, hogy a kernel mindenképp váltson rsp-t (amire egyébként a CPU lehetőséget is ad, csak hát nem használja a Linux, mert inkább a legacy módszernél maradtak).

Hadd köszönjem meg Neked, hogy végre értelmes, témábavágó hozzászólást is olvashatok!

Egy pelda volt, lehet nem az a megfelelo struktura (az elso korben), de konnyen lehet, hogy van olyan aminek tudhatod a cimet is, es nem tortenik azonnal baj, ha egy kis ideig elrontasz par erteket is, vagy tudod az eredetit es azt iratod vissza.

Kepzeld el mondjuk, mi van akkor, ha van valami strutura/tomb ami tele van fuggveny mutatottkkal, es atirod mindet, hogy "jo" helyre mutasson.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Egy pelda volt, lehet nem az a megfelelo struktura (az elso korben), de konnyen lehet, hogy van olyan aminek tudhatod a cimet is"
Egyetértünk, ezért írtam, hogy "nem tartom kizártnak, hogy esetleg létezhet ilyen, de szeretném látni, melyik."

"es nem tortenik azonnal baj, ha egy kis ideig elrontasz par erteket is"
Ez is tökéletesen így van, azonban felveti a GP handler megszakítás problematikáját. Azt sem szabad elfelejteni, hogy az address space (amiben épp garázdálkodsz) egy olyan taskhoz tartozik, ami épp most kapott egy SIGKILL-t.

"vagy tudod az eredetit es azt iratod vissza."
Szintén korrekt, a baj az, hogy nem tudod mind a 100 byteot tetszőlegesen beállítani, hanem elszórtan vannak random vagy constant értékek. Ez drasztikusan lecsökkenti a potenciális kernelstruktúrák számát. Azt szerettem volna tisztázni PaxTeam-el, hogy nullára vagy egyre csökken-e, de sajnos kommunikációs problémák merültek fel valamint önellentmondásba keveredett.

"Kepzeld el mondjuk, mi van akkor, ha van valami strutura/tomb ami tele van fuggveny mutatottkkal, es atirod mindet, hogy "jo" helyre mutasson."
Elméletileg igazad van. Gyakorlatilag senki nem tudott még ilyent találni. Az is probléma, hogy senki nem rukkolt még elő olyan megoldással, ami során egy ilyen struktúra/tömb étírása az effektív GP handler eltérítést meg is valósítaná. Ezért írtam, hogy ez két művelet:
1. funcptr=&func
2. *funcptr()
Nekünk a másodikra (mivel adatot módosítunk, call %rax nem játszik) csak egy külső esemény révén van esélyünk. Viszont senki nem talált még olyan megoldást, ami legalább elméletileg ilyen eseményt előidézhetne (módosítatlan GP handler futása közben).

> Azt sem szabad elfelejteni, hogy az address space (amiben épp garázdálkodsz) egy olyan taskhoz tartozik, ami épp most kapott egy SIGKILL-t.

SIGKILL-t sose kap GPF miatt (ezek szerint azt se tudod, hogy az mi). az is erdektelen igazabol ha kap, mert mire odaig eljut a kernel, addigra mar az exploit payload regen lefutott.

> Szintén korrekt, a baj az, hogy nem tudod mind a 100 byteot tetszőlegesen beállítani, hanem elszórtan vannak random
> vagy constant értékek.

mi a random?

> Ez drasztikusan lecsökkenti a potenciális kernelstruktúrák számát. Azt szerettem volna tisztázni PaxTeam-el, hogy
> nullára vagy egyre csökken-e, de sajnos kommunikációs problémák merültek fel valamint önellentmondásba keveredett.

eddig te bizonyultal ellentmondasosnak, van par nyitott kerdes, amit meg kene valaszolnod ;).

> Gyakorlatilag senki nem tudott még ilyent találni.

szoval te mar allitolag irtal ret2libc/ROP exploitot, de keptelen vagy ilyen strukturat talalni?

> Az is probléma, hogy senki nem rukkolt még elő olyan megoldással, ami során egy ilyen struktúra/tömb étírása az
> effektív GP handler eltérítést meg is valósítaná.

dehogynem, csak el kene olvasnod a mar tobbszor leirt lehetosegeket ;).

> Javits ki, ha tevednek, de nem kell feltelen ptrace/execve/sigreturn ahhoz, hogy triggerreld.
> Ha kovetkezo utasitas cime nem canonikus az eleg, ez elerheto azzal is (ahogy fentebb irtak), mmapolsz a meg
> canontikus teruletre egy futathato lapot, es vegere teszel egy syscall-t.

pontosan (nergal mindezt leirta fentebb).

> Szerintem ezen hivasokat, azert emlitettek, hogy felhivjak figyelmet arra, hogy nem eleg csak letiltani az nmappolast
> arrol a teruletrol, mert maskep is lehet tamadni.

lehetseges, bar szerintem eleve senki sem probalta meg igy orvosolni a hibat ;).

> @PaxTeam: Azert nem minden contexusban igaz hogy rcx it csak egy register a sok kozul, mivel a sysret ill,
> syscall -rol beszelunk nem csak egy register, mert az elso olvassa, masik irja (rip+2) -vel.

felreertettel, tudos turdus baratunk nem volt tisztaban azzal, hogy az rcx egy regiszter es nem regiszterek. tokmindegy milyen kontextusban (de nehogy nekem most valaki a register renaming-gel jojjon ;).

mmap(MAP_FIXED) tamogatasa POSIX eloiras, viszont a userland cimter meretet a kernel donti el, tehat azon a ponton meg lehet akadalyozni ezt a konkret technikat. de ez az egesz tokmindegy, mert a speci cimen vegrehajtott syscall nelkul is siman lehet triggerelni a hibas kernel kodot, sot igazabol ugy kenyelmesebb.

ja hogy ugy altalaban arbitrary write ellen mit lehet tenni. hat eleg nehez ugy ;). randomizalas eleve nehez (max kernel heap-nel jon szoba) es egy arbitrary read ugyis keresztbe tesz neki (amit ki lehet valtani egy korlatozott read es a write hiban keresztul, l. tavalyi HES grsec eloadas). read-only lapok mukodnek, csak mivel nincs rendes hw gyorsitas hozza, eleg sokba kerul, tehat csak korlatozott mertekben lehet hasznalni kernel adatok vedelmere. de majd kiderul, hogy mi mennyi, ha egyszer valamikor lesz KERNSEAL ;).

az IDT mar read-only osidok ota PaX alatt, de talan mar vanilla alatt is (reg neztem ;). viszont semmit nem szamit, mert nem a legegyszerubb celpont szerintem (irtam is fentebb valahol, hogy en tuti nem azt valasztanam felulirasra). azt se felejtsuk el, hogy ezt a hibat tetszoleges szamuszor lehet triggerelni, tehat a felulirhato kernel memoria merete korlatlan (de megbizhato exploithoz valoszinuleg szukseges infoleak, bar ezt is kernele valogatja, freebsd pl. eleg sokfele cimet leakel userland-nek ha jol remlik). a lenyeg, ez az a fajta hiba, ami ellen a legnehezebb vedekezni :).

( turdus | 2012. 06. 22., p – 23:12 )

@turul16: "Alj le egy picit es gondolkozzal."
Megtettem, találtam is megoldást, és mellesleg rájöttem, mi lett félreértve.

A sebezhetőséget végigolvasva hirtelen nem egy, hanem több módszer is eszembe jutott, hogy a cpu hardware-s védelmi mehanizmusával hogy lehet játszi könnyedséggel megakadályozni ezt a támadást. Plusz, ismertem az Intel mérnök pofonegyszerű szoftveres megoldását. Mindennek a tetejébe túl extrém helyen keletkezik a GPF, sokkal egyszerűbb és kényelmesebb exploitok is vannak. Ezért gondoltam, hogy ez baromság.
Első olvasatra pedig valóban nem volt egészen világos, melyik stack kivel is van, ezért kérdeztem.

Az, hogy az olyan kerneleket, amik a rendelkezésre álló védelmi lehetőségek közül egyetlen egyet sem vesznek igénybe, nem ellenőrzik a hívót, illetve stackben tárolják a visszatérési címet (syscall védelmi mechanizmusának egyik fő eleme, hogy ne stacken adódjon át a cím), javítani kell, számomra triviális volt. Éppen ezért még legrosszabb rémálmomban sem gondoltam, hogy van olyan, aki úgy gondolja, hogy én azt gondolom, hogy nem kell javítani.

Az már csak a sors puszta fintora, hogy az Intel mérnök által javasolt pofonegyszerű és megkerülhetetlen szoftveres védelem pont az ASLR miatt nem kerülhet be a kernelbe, pedig minden feltétel adott. *Sigh*

Na szóval, akkor térjünk a lényegre.

Mivel kezdettől fogva biztos voltam benne, hogy adatinjektálással nem sokra megyünk, a kód injektálás témakörét jártam körül.
A kód nem folyamatos, és nem az injektált adat elején kezdődik, így meg kell oldani, hogy a vezérlés valahova a közepébe kerüljön. Elővettem az ABI spec-t, és meg is találtam, amit kerestem a 49. oldal 3.30-as ábráján. Egy switchbe el lehet rejteni az injektált byte-ok elejét, és egy kalap alatt arról is lehet gondoskodni, hogy a kód közepébe ugorjon a vezérlés. A kód pedig egyből a címtábla után következik, azaz egyben írhatók.
A gond ott van, hogy nem minden switch felel meg. Mivel az injektált adatok eleje nem befolyásolható, ezért kellő számú case ágra van szükség (legalább annyira, mint ahány érték a verembe kerül a legelső kontrollált regiszterig). Továbbá, fontos, hogy az injektálás és az első szándékos hívás között az adott switch még véletlenül se hívódjon meg olyan case ágra, amit nem mi felügyelünk, mert az szinte biztos crash (akár a címtáblába barmoltunk bele, akár a mutatott kódba. De akár még gond nélkül le is futhat, ha pont nem bántottuk egyiket se).

Ilyen speckó switch a GP handlerben nincs, ezért mindenképp késleltetett aktiválás jöhet csak szóba, azaz nem számíthatunk a meghaló task text szegmensére. Kizárólag a kernelterületre frissen injektált kódra építhetünk csak. Ez azonban nem lehet nagyobb, mint a kontrollált regiszternyi terület (~50 byte körül lehet, mert a kód nem egybefüggő, és a near jmp-k blokkonként 2 byteot elvesznek). Ebben kell megoldani azt, hogy további text szegmenst töltessünk a kernelmemóriába, ráadásul úgy, hogy saját adatterületünk egyáltalán nincs, csak azt használhatjuk, amit épp a memóriában a környéken találunk.

Tehát megvan az elmélet, de továbbra sem valószínű, hogy egyhamar talál valaki megfelelő switch-et egy kernelben (ha ugyan talál), és továbbra is kérdéses, hogy ilyen kevés darabolt helyre belefér-e az összes szükséges kód (csak a text szegmens célcímének betöltése egy regiszterbe a teljes mennyiség kb. 1/5-e, ráadásul legalább két szomszédos kontrollált regiszternyi terület kell hozzá).

Mindamellett hogy undorito ahogyan az egesz heti amokfutos hoborgesedet probalod kimagyarazni egy ujabb ertelmetlen altudomanyos maszlaggal, en egeszen eddig azt hittem csak szimplan nem vagy kepes leirni a "bocs, en tevedtem" mondatot es abbahagyni. Most viszont mar inkabb valami fogyatekossagra tippelek.

Annyira hozod az atlag linux kernelfejleszto hozzallast, hogy mindenkeppen ki kene probalnod ezen a palyan. Mondjuk mar gyanusan tul jol is hozod. Mingo te vagy az? :)

Azokat nem o allitotta, hanem ezek te a teves elkepzeleseid arrol hogy hogyan kihasznalhato a hiba, igy hat nincs is mit cafolni rajta. Egy teljes okorseg amirol beszelsz es hiaba probaltak tobben is utbaigazitani, meg tobb okorseget szedtel ossze. Egyebkent meg miert vergodsz itt? Lattad te is az immunity videot. Szerinted fake? Esetleg azt varod hogy komplett exploitot fogsz kapni? (nem fogsz)

> A sebezhetőséget végigolvasva hirtelen nem egy, hanem több módszer is eszembe jutott, hogy a cpu hardware-s védelmi
> mehanizmusával hogy lehet játszi könnyedséggel megakadályozni ezt a támadást.

na, oszd meg velunk is ezeket a modszereket ;).

> Plusz, ismertem az Intel mérnök pofonegyszerű szoftveres megoldását.

fraszt ismertel. sot meg most se tudod, mit irtak azon a wiki-n, lasd alabb.

> Mindennek a tetejébe túl extrém helyen keletkezik a GPF, sokkal egyszerűbb és kényelmesebb exploitok is vannak. Ezért gondoltam, hogy ez baromság.

mi az, hogy 'tul extrem hely'? sysret is csak egy utasitas, mint a tobbi. aztan meg mi koze a 'tul extrem hely'-nek az exploitokhoz? te idaig egyetlen exploit technikat se ertettel meg, behazudtal viszont sok mindent. (te meg a ROP exploitok, mi? ;)

> Első olvasatra pedig valóban nem volt egészen világos, melyik stack kivel is van, ezért kérdeztem.

elso olvasatra nergal belinkelt leirasa mar tartalmazott minden informaciot, pl. (jaj, megint angol ;):

>> Only Intel CPUs are affected. On AMD CPUs, sysret completes the switch to ring3 before throwing #GP, so the stack switch occurs.

ebbol elemi logikaval kovetkezik, hogy ha az amd prociknal megtortenik a ring switch a GPF elott, akkor intelen meg nyilvan nem, amibol a processzor altalanos kivetelkezelo logikajat ismerve viszont kovetkezik, hogy amd-n a GPF maga ring switchet es igy stack switchet fog eredmenyezni, intelen meg IST fuggo, de a gyakorlatban minden erintett OS-nel
nem lesz stack switch.

tovabba ezt is irta:

>> Also, immediately before sysret, the syscall handler must restore rsp to the value set by ring3 (because
>> syscall/sysret do not set rsp). Therefore, the #GP handler will execute with rsp chosen by the attacker[...]

ennel vilagosabban nem lehet leirni.

> Az, hogy az olyan kerneleket, amik a rendelkezésre álló védelmi lehetőségek közül egyetlen egyet sem vesznek igénybe,
> nem ellenőrzik a hívót,

latszik, hogy soha nem fogtad fel a hiba lenyeget. *syscall* utasitas vegrehajtasa *nem* szukseges a hiba kivaltasahoz (tehat hivorol beszelni badarsag). a hiba a *sysret* kezelese miatt van, az ott hasznalt rcx-be kerulo erteknek pedig szamos forrasa lehet (l. nergal sokszor hivatkozott leirasa, de mivel mar sokszor beideztem, gondolom most sem fogod megerteni).

> illetve stackben tárolják a visszatérési címet (syscall védelmi mechanizmusának egyik fő eleme, hogy ne stacken
> adódjon át a cím),

tok mindegy, hol tarolodik a sysret altal felhasznalt visszateresi cim, a hiba nem ott van, hanem abban, hogy magat a cimet (miutan *akarhonnan* betoltotte a kernel az rcx-be), nem validaljak rendesen az erintett kernelek (mivel amd viselkedest felteteleztek, ahol erre a validalasra a 'ring-switch-before-gpf' viselkedes miatt nincs szukseg, modulo amd proci bugok, de most ne legyunk tul szofisztikaltak, mert mar eddig is nehez volt kovetned ;).

> javítani kell, számomra triviális volt.

ami trivialis volt, az az, hogy semmit sem ertesz. meg a hibat magat sem, amint fentebb lathato ;).

> Éppen ezért még legrosszabb rémálmomban sem gondoltam, hogy van olyan, aki úgy gondolja, hogy én azt gondolom, hogy nem kell javítani.

szerinted hany embert erdekelt itt az, hogy te mit gondolsz? ide mokazni jarnak az emberek, nem toled okulni ;)

> Az már csak a sors puszta fintora, hogy az Intel mérnök által javasolt pofonegyszerű és megkerülhetetlen szoftveres
> védelem pont az ASLR miatt nem kerülhet be a kernelbe, pedig minden feltétel adott. *Sigh*

mi koze az ASLR-nek az egeszhez? semmi.

> Mivel kezdettől fogva biztos voltam benne, hogy adatinjektálással nem sokra megyünk, a kód injektálás témakörét jártam körül.

amint lentebb kiderul, eleg homalyos neked ez a kod vs. adat dolog.

> A kód nem folyamatos, és nem az injektált adat elején kezdődik, így meg kell oldani, hogy a vezérlés valahova a közepébe kerüljön.

eloszor azt kene elmagyaraznod, hogy *hova* injektalsz kodot (vagy adatot, kevered a dolgokat rendesen ;).

> Elővettem az ABI spec-t, és meg is találtam, amit kerestem a 49. oldal 3.30-as ábráján.

olyan, hogy 'az ABI spec' nem letezik, van belole viszont sok verzio, melyikre gondoltal? sebaj, dedukaltam. az lenne a kerdesem, hogy kernelben hol talalsz te GOT-ot meg GOT relativ relokaciokat? ;)

> Egy switchbe el lehet rejteni az injektált byte-ok elejét, és egy kalap alatt arról is lehet gondoskodni,
> hogy a kód közepébe ugorjon a vezérlés. A kód pedig egyből a címtábla után következik, azaz egyben írhatók.

a switch konstrukcio melyik reszebe gondoltad elrejteni az injektalt byte-ok elejet? kodba vagy adatba? mert ha kodba, akkor minek a switch, barmilyen kod megfelel (felteve, hogy egyaltalan irhato a kod), ha meg az adatba, akkor peched van, mert az read-only es nem vegrehajthato (.section .lrodata, "alM", nincs benne se "w", se "x").

> A gond ott van, hogy nem minden switch felel meg. Mivel az injektált adatok eleje nem befolyásolható, ezért kellő
> számú case ágra van szükség (legalább annyira, mint ahány érték a verembe kerül a legelső kontrollált regiszterig).

ebbol ugy tunik, hogy te a switch konstrukciohoz tartozo adatot akarnad felulirni. pechedre az se nem irhato, se nem vegrehajthato, de lehet ujra probalkozni ;).

> Továbbá, fontos, hogy az injektálás és az első szándékos hívás között ...

hogy hivod meg szandekosan a switch-et? (beugratos kerdes, mert pont ezen rugoztal meg par napja ;)

> ... az adott switch még véletlenül se hívódjon meg olyan case ágra, amit nem mi felügyelünk, mert az szinte biztos crash

miert szinte biztos crash? vegeztel ra szamitasokat? szimulaciot? levezetted az eredmenyt valahogy?

> (akár a címtáblába barmoltunk bele, akár a mutatott kódba.

akkor most kodot vagy adatot irsz felul?

> De akár még gond nélkül le is futhat, ha pont nem bántottuk egyiket se).

akar meg akkor is, ha bantottad.

> Ilyen speckó switch a GP handlerben nincs,

elarulom, hogy mashol se. az altalad megtalalt konstrukcio userland-re van, kernelben nincs GOT meg hasonlo dolgok.

> ezért mindenképp késleltetett aktiválás jöhet csak szóba, azaz nem számíthatunk a meghaló task text szegmensére.

mi lenne ez a kesleltetett aktivalas? miert nem lehet szamitani a meghalo taszkra? miert halna meg eleve? (mindez szobakerult mar ;)

> Kizárólag a kernelterületre frissen injektált kódra építhetünk csak.

nem igaz. ez kulonosen azert vicces, mert tegnap azzal fenyezted magad, hogy te mar irtal ROP exploitot. te kis hazug, megint lebuktal ;). nem beszelve arrol, hogy mar megint nem tudod eldonteni, hogy most kodot vagy adatot irsz felul. az altalad hivatkozott switch konstrukcional ugyanis csak az egyiket tudnad felulirni az adott esetben (kulon szekcioban es igy kulon virtualis cimteruleten van a switch kodja ill. az adata, a jump tabla).

> Ez azonban nem lehet nagyobb, mint a kontrollált regiszternyi terület (~50 byte körül lehet, mert a kód nem
> egybefüggő, és a near jmp-k blokkonként 2 byteot elvesznek).

a beinjektalt kod merete vajmi keveset szamit (felteve, hogy kodot tudsz egyaltalan beinjektalni, ehhez ugye irhato kodlap kell valahol a kernel cimtereben, ilyet se mutattal meg, a jump table terulete ugye kilove, mert az nem irhato es nem vegrehajthato).

> Ebben kell megoldani azt, hogy további text szegmenst töltessünk a kernelmemóriába,

szegmentacio effektive nem letezik amd64 alatt, mit akarsz betolteni pontosan? azontul minek barmit is betolteni a kernelbe, amikor ott van a userland, vagy lehet ROP-ot csinalni, aminek te szakertoje vagy ugyebar ;).

> ráadásul úgy, hogy saját adatterületünk egyáltalán nincs, csak azt használhatjuk, amit épp a memóriában a környéken találunk.

miert nincs sajat adatterulet? ott a userland processz memoriaja, ott a processz kernel verme, stb, stb.

> Tehát megvan az elmélet

nem, csak egy rettentoen zavaros es onellentmondo egyveleg van idaig, aminek se fule, se farka.

> de továbbra sem valószínű, hogy egyhamar talál valaki megfelelő switch-et egy kernelben (ha ugyan talál)

mivel userland konstrukciora hivatkoztal, azt bizony valoban senki nem fog talalni a kernelben (az egyeb, fentebb mar vazolt korulmenyektol eltekintve is).

> és továbbra is kérdéses, hogy ilyen kevés darabolt helyre belefér-e az összes szükséges kód

semmi szukseg olyan keves helyre barmit bezsufolni, eleve nem mukodik a modszered.

> (csak a text szegmens célcímének

ez milyen allat akar lenni?

> betöltése egy regiszterbe a teljes mennyiség kb. 1/5-e, ráadásul legalább két szomszédos kontrollált regiszternyi terület kell hozzá).

fentebb mintha a jump table-t akartad volna felulrni, abban meg sima 8 byte-os pointerek vannak, minek oda ket regiszternyi terulet?

>> Elővettem az ABI spec-t, és meg is találtam, amit kerestem a 49. oldal 3.30-as ábráján [..] továbbra sem valószínű, hogy egyhamar talál valaki megfelelő switch-et egy kernelben (ha ugyan talál)

csak remélni tudom, hogy az ábra felirata nem "Figure 3.30: Position-Independent Switch Code" volt

Izé, full laikusként csak azt szeretném jelezni, hogy szó volt róla nem sokára lesz egy Blackhat konferencia ahol mintha khmm pont erről lenne egy előadás. (Igaz ez 2000$ tudás, mivel ennyi oda belépő.)

Valahogy nem tűnik számomra életszerűnek, hogy valaki nagy nyilvánosság előtt szeretne szakmai öngyilkosságot elkövetni.

Bár márcsak egyet kell aludni és minden kiderül.

No rainbow, no sugar

Azt nem mondtam, hogy már elismerte. Annyit mondtam: írta, hogy vállalja, hogy elismeri, ha téved. Ha megteszi, értékelem. Ha nem, akkor persze még rosszabbul jön ki.

De arra rácuppanni, és élvezkedni azon, hogy fú, most ő nyilvánosan megalázkodik... hát, nekem nem esetem.

Mindegy, ne menjünk bele.

( axt v | 2012. 06. 26., k – 01:28 )

subscribe

@PaXTeam: Maximális respect azért, hogy annak ellenére, hogy már az elején látszik, hogy reménytelen, megpróbálod elmagyarázni a hibát. Szeretem az ilyen topicokat (emlékeim szerint nem ez az első), mert tanulságosak.

( szniki | 2012. 06. 27., sze – 08:46 )

En arra lennek kivancsi, hogy a security szakerto uraink szerint (szia Hunger o/ :-) kb. hany szazaleka az OS hibaknak koszonheto a C semmit-nem-ellenorzunk elvenek amit ki lehetne kerulni pl. managed nyelvvel. Nyilvan nem pontos szamra vagyok kivancsi, hanem egy educated guessre :)

Sok hiba vezethető vissza C betegségekhez (pl. NULL pointer dereference is tipikusan ilyen, meg egyes integer singedness problémák, amelyek "történelmi hagyományokból" maradtak meg és betonozódtak be... lásd. fgets() int-et vár el size-ként, nem unsigned size_t-t és hasonlók), viszont a menedzselt nyelvek sem nyújtanak megoldást a biztonságos programozáshoz, csak a komplexitás egy részét elviszik az applikációból magasabb szintekre, de ettől még az "eredő" nem igazán lesz kisebb. Cserébe viszont akár még egy Hello World progi is ki lesz téve a VM bugjainak...

"Mindegy hova söpröd a szart (bugos kódot), attól még ugyanolyan büdös (exploitable) marad" ;)