Aktív témák

• #57 WN31RD addikt rog #55

  2004-01-09 17:04:48 #57

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #55 üzenetére

  ''hogy veszi át a támadó a ''B'' process felett az irányítást?''
  B processzben:
  X függvény meghívja Y függvényt
  Y függvény hibás, és egy támadó Y függvény hibáját kihasználva beleírja a verembe a gonosz kódot, plusz a gonosz kódra mutató visszatérési értéket
  Y függvény befejezi a működését, és visszatérne X-hez... de nem X-hez tér vissza, hanem a gonosz kódhoz kerül a vezérlés, mert a visszatérési érték át lett írva
  
  (Na, cracker tanfolyam ;] átmenetileg berekesztve... elhúztam.)

• #56 WN31RD addikt faster #54

  2004-01-09 17:00:54 #56

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz faster #54 üzenetére

  ''itt nem processzek közötti oda-vissza ugrálásról van szó, hanem egy processzen belüli függvényhívás-visszatérésről''
  Pontosan.
  ''az nem világos, hogy ez a kód is a stacken van-e''
  Általában igen, de ez részletkérdés.
  ''vajon a kód írója honnan tudja, hogy milyen címre kerül az ő programkódja''
  Ez benne a nehéz (egyebek mellett)...

• #53 WN31RD addikt kisfurko #50

  2004-01-09 16:56:35 #53

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz kisfurko #50 üzenetére

  Nem értem, mit nem értesz... :F
  (Viszont rövid időn belül ellépek a net mellől, tehát egy darabig nem lesz alkalmam válaszolni.)

• #51 WN31RD addikt rog #49

  2004-01-09 16:54:13 #51

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #49 üzenetére

  Na, értem végre, hogy mit nem értesz. :D
  Nincsen szó processzek közötti váltásról.
  Az A processz elindítja B processzt adott jogokkal. Innentől kezdve elfelejthetjük az A processzt.
  B processznek a stackjét elbassza egy támadó, ezáltal átveszi B processz felett az irányítást, és a támadó kód B processz részeként fut, természetesen a B processz jogaival.
  B processz (illetve a benne levő kód) garázdálkodik...
  Természetesen a B processz (illetve a benne levő kód), elindíthat egy C processzt, amibe bemásolhatja a gonosz kódot, de ez csak a garázdálkodás része... azaz részletkérdés.
  Ennyi.
  Világos?
  
  [Szerkesztve]

• #48 WN31RD addikt klumbik #47

  2004-01-09 16:43:42 #48

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz klumbik #47 üzenetére

  ''aki tud valami pár oldalban összefoglalt irományt ne habozzon linkelni!''
  Erre én is bejelentkezek! :D

• #46 WN31RD addikt kisfurko #41

  2004-01-09 16:41:53 #46

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz kisfurko #41 üzenetére

  Tényleg nem az architektúra hibája.
  Természetesen a privilegizált szinteknek külön verme van, viszont itt szó nincs különböző jogú processzekről... :F
  

• #44 WN31RD addikt rog #43

  2004-01-09 16:40:17 #44

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #43 üzenetére

  Pontosan az átvétel a lényeg. Mert hiába szúrom be a gonosz kódot, aminek ugyanazok a jogai, mint annak a processznek, amibe beszúrtam, ha nem tudom elindítani. Éppen az elindítást akadályozza meg az új feature (ha jól spekulálunk).

• #42 WN31RD addikt rog #40

  2004-01-09 16:36:20 #42

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #40 üzenetére

  Védelmi szinteken nem lehet ezzel a módszerrel átmenni, de a program jogait megkapja a gonosz kód is, tehát pl. egy vírus terjedhet a programot futtató felhasználónak a jogaival, ha pedig egy privilegizált (pl. root-ként futó) szerverprocessz az áldozat, akkor ugye nem kell tovább magyarázni...

• #39 WN31RD addikt rog #36

  2004-01-09 16:24:34 #39

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #36 üzenetére

  ''szóval az ip-t nem lehet olyan címre küldeni, ami a stack-en van?''
  Pontosan. (De nem csak a veremről van szó, hanem az adatszegmensről is.)
  
  ''de mivan ha a gonoszság nem a veremben van? vagy olyan nem lehet?''
  Elvileg olyannak nem kellene lenni, hogy kifejezetten gonosz programrész máshol legyen, de előfordulhat az, hogy egy teljesen normális rutin gonosz paraméterekkel meghívva gonosz dolgot csinál. A verem átírásával (a verembe írást semmi nem akadályozza meg) ilyen módon továbbra is támadható marad a gép.
  ''az ellen nem véd'' :D
  
  ''hogy működik egészen pontosan ez a túlcsordításos történet?''
  Pl. így működhet:
  A memóriában (veremben) a következők vannak:
  ... valamilyen puffer ... visszatérési cím ...
  A program beolvas a pufferbe, de hibás a beolvasó kód, és nem ellenőrzi a beolvasandó adat méretét, és ha túl sokat kap, akkor felülírja a puffer utáni területet is, beleértve a visszatérési címet.
  A támadó felülírja a visszatérési címet pl. a puffer bizonyos helyére mutató pointerrel, oda pedig berakja a kódot, és kész.

• #35 WN31RD addikt rog #34

  2004-01-09 16:15:17 #35

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz rog #34 üzenetére

  Azt nem engedi, hogy a program a veremben levő kódot végrehajtsa.
  Tehát hiába kerül be a verembe a gonosz programrész, és a rá mutató visszatérési cím, mert a veremben levő programrész nem fog tudni elindulni (védelmi hibával elkapja az oprendszer).

• #31 WN31RD addikt

  2004-01-09 15:51:25 #31

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  Hát... nekem sosem volt szimpatikus ez a szegmensezés...
  De szerencsére a 64 bites címtér + execute-only flag fölöslegessé teszi a szegmenseket. :D
  
  Vagy tudtok olyan dolgot, amit szegmensekkel meg lehet csinálni, de nagy címtér+e-o. flag-gel nem (vagy nem hatékonyan)?

• #28 WN31RD addikt kisfurko #27

  2004-01-09 15:31:49 #28

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz kisfurko #27 üzenetére

  Az lehet, hogy nem lenne bonyolultabb, mint a lapozás, de akkor is növelné a memóriakezelő rész bonyolultságát (mert lapozásra mindenképpen szükség van, de most még szegmensek kezelésére is szükség lenne). :)
  
  Ha nemcsak egy-egy szegmens van egy adott fajtából, akkor a fordítókat úgy kell írni, hogy szelektor:offszet típusú mutatókat kezeljenek... ez elég komoly változás lenne, bonyolítaná a fordítókat, lassítaná a programokat, stb. :O
  Nem véletlenül hagytak fel ezzel.
  
  [Szerkesztve]

• #25 WN31RD addikt Darth Vader #22

  2004-01-09 14:47:31 #25

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz Darth Vader #22 üzenetére

  Van szegmentálás, csak nem használják ki ennek a lehetőségeit.
  Na de nem kötözködöm: effektíve tényleg nincs szegmentálás a Linuxban, hanem lineáris címteret használ (legalábbis pl. a GRSecurity patch megfelelő opciójának a bekapcsolása nélkül).
  Amit leírtál az teljesen oké, csak az a gond, hogy ha használnák a szegmentálást, akkor vagy előre el kellene dönteni, hogy a 4 GB-os lineáris címtéren hogyan osztoznak a szegmensek (ez történik a GRSecurity-ban, ha ...PAX_SEGMEXEC=y), és ha valamelyik proginak többre van szüksége pl. az adatszegmensben, akkor gond van, vagy pedig menet közben kell tologatni és növelgetni a szegmenseket, ennek megfelelően átírni a laptáblátkat, ráadásul mindezt osztott kódot (libek) tartalmazó rendszerben, stb. Ez viszont már nagyon jelentősen bonyolítaná a memóriakezelést.

• #19 WN31RD addikt dabadab #17

  2004-01-09 14:31:16 #19

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz dabadab #17 üzenetére

  Szegmentálás alatt nyilvánvalóan a szelektor-deszkriptor rendszert értette Darth Vader (mint ahogyan én is)... :)
  Mellesleg ezt szegmentálásnak (is) szokás hívni, legalábbis legjobb tudomásom szerint.

• #16 WN31RD addikt Darth Vader #15

  2004-01-09 14:19:44 #16

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz Darth Vader #15 üzenetére

  (Elég régen foglalkoztam már ilyesmivel, tehát lehet, hogy tévedek, vagy nem veszek figyelembe valami új procikban meglévő lehetőséget... úgyhogy javítsatok ki, ha szükség van rá!)
  Mivel nem lehet szegmensenként elválasztva mappelni a lineáris címteret, szükségszerű, hogy egy processznek a szegmensei ugyanazon lineáris címtartomány eltérő részein legyenek, ha különböző tartalmuk van. Márpedig lineáris címekből 4 GB-nyi van, ezen kell osztozni, tehát nem lehet szegmensenként különböző 4 GB-ot használni.
  (Tekintsünk el a 36 bites PAE-től, és maradunk a ''hagyományos'' 4 GB-nál.)

• #13 WN31RD addikt Darth Vader #10

  2004-01-09 13:54:23 #13

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz Darth Vader #10 üzenetére

  Elsőre nem is jutott ez eszembe:
  A szegmentálásos védelemmel az a gond, hogy az amúgy sem túl nagy (legalábbis manapság már nem) 4 GB-os logikai címteret tovább csökkenti. De egy 64 bites proci esetében ez már nem lesz gond, nyugodtan lehet külön pakolni az adat/kód/stb. szegmenseket.
  Viszont akkor mi értelme van ennek az új feature-nek?
  Ha csak annyit tud, hogy a lapozási mechanizmusba berak egy execute-only flaget, akkor az egyetlen haszna ennek az lehet, hogy a 32 bites alkalmazásoknál is legyen védelem, ahol a kód és az adat címtér nem választható szét (ha szükség van a 4 GB-ra). Viszont ezeknek a régi progiknak a nagy része nem úgy íródott, hogy erre fel legyen készítve, és így is fusson. Ha meg módosítják őket, akkor ilyen erővel fordíthatják már 64 bitesre is.
  Érti valaki, hogy miről van itt szó igazából? :F

• #12 WN31RD addikt klumbik #9

  2004-01-09 13:48:26 #12

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  válasz klumbik #9 üzenetére

  ''szerintem ez a tcpa implementáció egy része (lesz)''
  A cikkben (elolvastam az eredetit is) semmi nem utal erre.
  Meg tudnád indokolni, miért gondolod ezt?

• #4 WN31RD addikt

  2004-01-09 10:39:13 #4

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  WN31RD

  addikt

  Linuxban pl. a GRSecurity patch szoftveresen megcsinálja ugyanezt (ha jól értem a hírt), persze (legalábbis az x86 architektúrán) némi teljesítménycsökkenés árán.
  Csakhogy: sok fontos program (pl. XFree 4, JRE, wine) nem működik ezzel, mert szüksége van arra, hogy a heapre vagy a stackbe rakott kódot végrehajtsa.
  Kíváncsi vagyok, a 64 bites Windowsban hogy oldják ezt meg... az új 64 bites programokat már írhatják erre felkészítve, és akkor azokkal nem lesz gond, de a régi 32 bitesek problémásak lesznek.

Aktív témák