Aktív témák

• #58 kisfurko senior tag WN31RD #53

  2004-01-09 17:04:51 #58

  Ö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 WN31RD #53 üzenetére

  Már OK, hogy mit magyaráztál, csak nem tudtam mire gondolsz...:)

• #55 rog addikt WN31RD #51

  2004-01-09 16:59:13 #55

  Ö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 WN31RD #51 üzenetére

  ööö ... világos...
  no de hogy veszi át a támadó a ''B'' process felett az irányítást?
  nem úgy ahogy ezt az elöbb vázoltam az elöbb ''A'' és ''B'' processekkel
  

• #52 kisfurko senior tag WN31RD #48

  2004-01-09 16:55:30 #52

  Ö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 WN31RD #48 üzenetére

  Töltsétek le AMD-éktől...:)
  Pár oldal...
  Nem sok egy full processzorleíráshoz képest.

• #50 kisfurko senior tag WN31RD #46

  2004-01-09 16:49:53 #50

  Ö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 WN31RD #46 üzenetére

  Nem értem...

• #49 rog addikt WN31RD #44

  2004-01-09 16:45:24 #49

  Ö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 WN31RD #44 üzenetére

  ja igen majd segyt.
  de mi az amit megakadályoz.
  vagyis mi történik ilyenkor?
  ezt nem értem.
  ''A'' process fut a gépen. elindítja ''B'' processt. adott védelmi szinten, jogokkal.
  ''B'' process megbssza a stackot. ezáltal a vezérlés nem ''A'' processra kerül vissza, hanem ottmarad ''B'' processnál. és hogyan tovább? mit tud csinálni, amit addig nem tudott?

• #43 rog addikt WN31RD #42

  2004-01-09 16:38:15 #43

  Ö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 WN31RD #42 üzenetére

  jogai megvoltak eddig is, hiszen kapta őket a hívó process-től. max tőle tudja átvenni ezzel a módszerrel.

• #41 kisfurko senior tag WN31RD #39

  2004-01-09 16:36:09 #41

  Ö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 WN31RD #39 üzenetére

  ''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.''
  Persze ez nem az architektúra hibája, hanem a szubrutiné. Illetve a rendszeré, ha nem azonos jogú dolgok egy vermet használnak.

• #40 rog addikt WN31RD #39

  2004-01-09 16:30:30 #40

  Ö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 WN31RD #39 üzenetére

  ja azt tudom, hogy a stackon hogy kell túlcsordultatni, de azt nem értem hogy aktiválja az ártó részeket.
  mert ugye ennek az lenne értelme, hogy védelmi szintet lép a program vagy ilyesmi.
  van egy programom aminek egy függvénye úgy van megírva, hogy direkte verem túlcsordulást okoz, és ezáltal a verem mutató körbeér, és a programrész hívása elötti állapotra vonatkozó verem adatokat felülírja. és így a függvény végi return, a vezérlést nem a hívóra adja, hanem oda ahova én szeretném.
  mit érek el ezzel? az op-rendszer az hiszi, hogy már a saját kódja fut, holott nem?
  vagy ezt most így hogy?
  

• #38 klumbik tag WN31RD #12

  2004-01-09 16:24:03 #38

  Ö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

  

  klumbik

  tag

  válasz WN31RD #12 üzenetére

  (sajnos most igazi konkrétumot nem tudok fölhozni, de körbejártam a linux thinkpad-en témát a neten, és mintha láttam volna valahol a linuxos ibm tcpa driver képességei között, hogy elvileg alkalmazható hardveres puffer túlcsordulás védelemre, így jutottam arra, hogy elhamarkodottam fölvessem)
  
  nem tudom milyen új védelmi lehetőségeket kínál még a k8 (pl. most kiderült számomra egy), de így érdekes kérdések merülhetnek föl a hírek szerinti prescottal kapcsolatban is, miszerint, ha azt mondják, hogy ez hardveres dolog és win támogatja, akkor jó eséllyel hardverszintű kompatibilitást kell mutatniuk ez ügyben (kb. valami flag ami azonos amd és intel procin is; közös amd-intel kiterjesztés(?)), ellenben a win kernel legalapvetőbb elemeinek kétféle verzióban, elég különbőzően kellene működniük
  
  a hírrel, sötétben tapogatózunk, nem tudjuk, hogy egy fícsör jellegű, altalános szinten a szoftverek szempontjából transzparens megoldásról van-e szó.
  szó van servicepackról ami jelenthet kernel foltozást (mert sztem, azért ilyen dolgokhoz be kell nyúlni oda), de jelenthet mást is.
  
  ezért nem ejteném még ki a képből tcpa-t mivel egy egységes dolog, bár nem vagyok benne biztos, hogy egy sp-vel már át is lehetne térni rá. viszont, sztem magának fritz chipnek mint hardver, vajmi kevés köze lehet a deszkriptorokhoz és deszkriptor táblákhoz, inkább erősen tőle függő szoftverrel lehet ezt a védelmet kihasználni; azonosításnál ill. engedélyezésnél lehet kihasználni, hogy hardverrel (elsősorban egy csomó sokszázbites titkositást segítő dolog, erre saját memória...) vannak ezek a folyamatok segítve az általa leírt technikák szerint
  
  persze csak találgatok
  
  na közben találtam tcpa-ra vonatkozót:
  [L]http://www.research.ibm.com/gsal/tcpa/[/L]
  [L]http://www.linuxjournal.com/article.php?sid=6633[/L]
  
  
  [Szerkesztve]

• #36 rog addikt WN31RD #35

  2004-01-09 16:18:38 #36

  Ö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 WN31RD #35 üzenetére

  szóval az ip-t nem lehet olyan címre küldeni, ami a stack-en van?
  de mivan ha a gonoszság nem a veremben van? vagy olyan nem lehet?
  hogy működik egészen pontosan ez a túlcsordításos történet?

• #33 kisfurko senior tag WN31RD #31

  2004-01-09 16:05:39 #33

  Ö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 WN31RD #31 üzenetére

  Eleinte nekem sem tetszett (főleg az el.....-t valós módú:)). Biztonságosabbak lehetnének egy nagyságrenddel a programok. Persze ez az execute-only page is OK. Hogy miért nem csinálták meg előbb...
  Egyébként a szegmensek annyival jobbak még, hogy ha a szegmens nem nagyobb, mint 1 MB, akkor byte-ra pontosan megadhatod a méretét.

• #30 kisfurko senior tag WN31RD #28

  2004-01-09 15:42:07 #30

  Ö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 WN31RD #28 üzenetére

  Szerintem nem lenne gáz a sel:offs típusú címzés, feltéve, hogy csak lib-enként lenne külön szegmens (máskülönben minek máshova rakni). A BSS-részüket meg egy nagy közösbe. BSS alatt értem a dinamikusan foglalt, futás alatt módosuló szegmenst.
  Egyszerűen csak azért hagyták ki az op.rendszerekből, mert másik architektúra nem támogatta. Szerintem, persze...

• #29 Darth Vader csendes tag WN31RD #28

  2004-01-09 15:39:28 #29

  Ö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

  

  Darth Vader

  csendes tag

  válasz WN31RD #28 üzenetére

  Adott esetben elkepzelheto, hogy lassitja, de csak akkor, mikor epp szegmenst kell valtani. Amugy egyebkent most is selector:offset a cimzesmod. Altalaban a nagyobb biztonsag ara, a lassabb mukodes. Pl: a Vedett uzemmodba a programok is lassabban futnak, mint valos modban.

• #27 kisfurko senior tag WN31RD #25

  2004-01-09 15:23:51 #27

  Ö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 WN31RD #25 üzenetére

  Szerintem nem bonyolultabb, mint a lapozás. Arra is gondolj, hogy nem csak egy-egy szegmens lehet egy adott fajtából. Ennek csak az LDT mérete szab határt.

• #20 dabadab titán WN31RD #19

  2004-01-09 14:38:09 #20

  Ö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

  

  dabadab

  titán

  válasz WN31RD #19 üzenetére

  Lehet, hogy annak is hivjak, de ez nem tul jo dolog, mivel ez a kifejezes mar ''foglalt'' x86-os kornyezetben.
  Amugy meg ezzek a kiegeszitessel sem ertem, hogy DV mire akart azzal kilyukadni, hogy nincs szegmentalas, mivel nyilvanvaloan van.
  

• #15 Darth Vader csendes tag WN31RD #13

  2004-01-09 14:00:26 #15

  Ö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

  

  Darth Vader

  csendes tag

  válasz WN31RD #13 üzenetére

  Ez most nem ertem. Miert csokkenti a 4GB-os teruletet?
  Egy szegmens merete tetszoleges lehet. Siman lehet minden programnak kulon adat es code es stack szegmense is. A szegmensek ugyan ugy darabolhatjak a memoriat, mint ahogy a lapozas darabolja. Ugy kellene a memoriamanaggert megirni, hogy a lapozast es a szegmentalast egyszerre hasznaljak.

Aktív témák