Hirdetés
- Luck Dragon: Asszociációs játék. :)
- Parci: Milyen mosógépet vegyek?
- GoodSpeed: Márkaváltás sok-sok év után
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Fűzzük össze a szavakat :)
- MaxxDamage: -TongFang- Medion Erazer Beast 16 X1 - induló teszt így kora délután..."CB R23"
- sziku69: Szólánc.
- hcl: Mér' nem mér?
- GoodSpeed: A RAM-válság és annak lehetséges hatásai
- gban: Ingyen kellene, de tegnapra
Aktív témák
-
WN31RD
addikt
''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.) -
WN31RD
addikt
''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)... -
WN31RD
addikt
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] -
WN31RD
addikt
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...
-
WN31RD
addikt
''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. -
-
WN31RD
addikt
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
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. -
#16
WN31RD
addikt
Darth Vader
#15
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
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 -
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
- LEGO klub
- Luck Dragon: Asszociációs játék. :)
- World of Tanks - MMO
- PlayStation 5
- Autós kamerák
- HiFi műszaki szemmel - sztereó hangrendszerek
- 5.1, 7.1 és gamer fejhallgatók
- Kicsomagoljuk és bemutatjuk a Poco F8 Ultrát
- Parci: Milyen mosógépet vegyek?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- BESZÁMÍTÁS! Dell Latitude 3530 üzleti notebook - i5 1235U 8GB DDR4 512GB SSD Intel Iris Xe WIN11
- Lejárt a gyártói garancia? Mi tovább támogatjuk az IT infrádat!
- GYÖNYÖRŰ iPhone 11 Pro 64GB Space Grey-1 ÉV GARANCIA - Kártyafüggetlen, MS3668, 100% Akkumulátor
- 3db apró szépséghibás DELL WD19S dokkolók (csak kábel résznél) (ELKELT)
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest