Aktív témák

• #69 Hory aktív tag rog #11

  2004-01-10 13:10:25 #69

  Ö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

  

  Hory

  aktív tag

  válasz rog #11 üzenetére

  Dehogyis, indítok saját portált. :)

• #66 Gregorius őstag rog #62

  2004-01-09 17:27:28 #66

  Ö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

  

  Gregorius

  őstag

  válasz rog #62 üzenetére

  egy olyan nagy paraméterrel, amitől az túlcsordul
  Itt egy alapvető tévedésedet eloszlatnám: nem a stack csordul túl, hanem a buffer.
  A stack az egy olyan képződmény, ami nagyobb memóriacímtől a kisebb felé nő. Ne kérdezd, miért van ez így, így van és kész, ez ''hagyomány''. A probléma az, hogy a buffereket (tipikusan egy char [] vagy hasonló) a különböző függvények (pl. strcpy) éppen másik irányba (kisebb címtől nagyobb felé) írják, tehát ha a buffernek lefoglalt memóriaterületen túllóg a beírt adat, akkor a stackre utoljára rárakott adatokat, vezérlő információkat fogja felülírni, tehát szó sincs semmiféle átfordulásról, ez nem olyan túlcsordulás. Inkább túlírásnak (overrun) lehetne hívni.
  
  Azért problémás az ügy, mert ugyan lehet, hogy nagy kárt nem tud okozni a hiba bizonyos esetekben, de DoS-szerű támadást mindenképpen (egyszerűen hibával elszáll a program/service, ld. MSBlast), azon túl potenciálisan bármilyen kárt lehet vele okozni (akár egy mass-mailer vagy egy proggi, ami ellopja a bizalmas adataidat nem elég nagy kár?). Sokkal egyszerűbb egy ilyen hibát kijavítani (miután kiderült, hogy ott van), mint azon filózni, hogy ez mennyire lehet veszélyes.
  
  [Szerkesztve]

• #65 kisfurko senior tag rog #63

  2004-01-09 17:21:27 #65

  Ö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

  

  kisfurko

  senior tag

  válasz rog #63 üzenetére

  Jaja. Jómongya!

• #64 kisfurko senior tag rog #62

  2004-01-09 17:19:45 #64

  Ö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

  

  kisfurko

  senior tag

  válasz rog #62 üzenetére

  Ez az idegen kód végrehajtásosdi inkább a system process-ekre veszélyes.
  Normál esetben megfelelően reagál mondjuk egy Apache. Ekkor simán csak a neked való oldalakat tudod lekérdezni. Ha egy lekéréssel be tudod juttatni a saját kódodat, akkor olyan oldalt, Apache rendszerfile-t is megkaphatsz, amit nem tudnál normálisan.
  E?
  

• #62 rog addikt rog #59

  2004-01-09 17:13:39 #62

  Ö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

  

  rog

  addikt

  válasz rog #59 üzenetére

  ok megfejtettem mit írtál. :)
  gyak ugyanaz mnt az első pl a és b processel.
  
  B meghívja A.Y-t. (ismerve a stack méretét, egy olyan nagy paraméterrel, amitől az túlcsordul és a paraméter vége, benne a gonoszságra mutató címmel rákerül a megfelelő helyre).
  ezáltal a A.Y-ról a vezérlés nem a hívóra kerül (ez lehet B.X, A.X, vagy C.X is) hanem a stack-en levő gonoszságra.
  mit ér el vele?
  a G-kód a hívó jogaival fog rendelkezni (A.X esetén A jogaival C.X esetén C jogaival, B.xnél B jogaival, az utolsó mondjuk szívás.)
  
  ha A-ból vagy c-ből hívják meg a hibás Y függvényt akkor hogy kerül a stackre a Goni kód, meg csorduláshoz kellő hosszú paraméter?
  
  
  

• #61 L3zl13 nagyúr rog #59

  2004-01-09 17:10:10 #61

  Ö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

  

  L3zl13

  nagyúr

  válasz rog #59 üzenetére

  A gonosz kód nem része eredetileg a processznek.
  
  Y végrehajtása után normálisan X-hez kerülne a vezérlés, de mivel a stack-et felülírta a puffer túlcsordulás. Ezért a stackre írt gonosz kódhoz kerül a vezérlés.

• #60 kisfurko senior tag rog #55

  2004-01-09 17:09:48 #60

  Ö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

  

  kisfurko

  senior tag

  válasz rog #55 üzenetére

  A program input-járól érkezik a gány kód (nem B processzból, hanem a külvilágból).

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

• #54 faster nagyúr rog #49

  2004-01-09 16:59:04 #54

  Ö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

  

  faster

  nagyúr

  válasz rog #49 üzenetére

  Szerintem 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. A függvény a visszatérési értéket a stacken tárolja, ami felülíródik, és a saját kódra mutat. Csak az nem világos, hogy ez a kód is a stacken van-e (bár gondolom, csak ott, hiszen a puffer túlcsordulás csak a stacken képes írása), és vajon a kód írója honnan tudja, hogy milyen címre kerül az ő programkódja.

• #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]

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

• #37 kisfurko senior tag rog #36

  2004-01-09 16:23:56 #37

  Ö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

  

  kisfurko

  senior tag

  válasz rog #36 üzenetére

  Nem olvastam még el, de én úgy tudom elképzelni, hogy csak az futhat (lap), aminek be van állítva az execute flag-je. A rendszer pedig csak a kód lapjainak állítja be. A kód lapjait meg nem lehet módosítani, mert read-only. Tehát nincs gonosz kód. Vagy valamit kifelejtettem?

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

Aktív témák