- Norvégia átmenetileg betiltja az áramigényes kriptobányászatot
- 1000 milliárd dolláros AI-központot akar az USA-ban a SoftBank
- Humanoid robotokat visz az AI-szervergyárba az NVIDIA és a Foxconn
- Relatíve kompakt, "platinás" tápszörnyekkel gyarapodott az ASUS kínálata
- Valós időben generálhatja a jövőben a GPU a fákat
Aktív témák
-
#91
tocsa
senior tag
Darth Vader
#89
tocsa
senior tag
válasz
Darth Vader
#89
üzenetére
Megnéztem az Understanding The Linux Kernel idevágó részeit.
Mint kideritettem OReilly könyv, orosz site-ról sikerült letölteni pdf-ben. :)
A Linux kernel beli szegmentálás:
''The 2.2 version of Linux uses segmentation only when required by the Intel 80x86
architecture. In particular, all processes use the same logical addresses, so the total number of segments to be defined is quite limited and it is possible to store all Segment Descriptors in the Global Descriptor Table (GDT).''
...
''For each process, therefore, the GDT contains two different Segment Descriptors: one for the TSS segment and one for the LDT segment.''
Lapozás
''Furthermore, instead of the three types of access rights (Read, Write, Execute) associated with segments, only two types of access rights (Read, Write) are associated with pages. If the Read/Write flag of a Page Directory or Page Table entry is equal to 0, the corresponding Page Table or page can only be read; otherwise it can be read and written.''
''pte_exec( )
Returns the value of the User/Supervisor flag (indicating whether the page is
accessible in User Mode). Notice that pages on the Intel processor cannot be protected against code execution.''
PAE:
''The other main change is related to physical memory addressing. Recent Intel 80x86
microprocessors include a feature called Physical Address Extension (PAE), which adds four extra bits to the standard 32-bit physical address. Linux 2.4 takes advantage of PAE and supports up to 64 GB of RAM. However, a linear address is still composed by 32 bits, so that only 4 GB of RAM can be ''permanently mapped'' and accessed at any time.'' -
#90
tocsa
senior tag
Darth Vader
#89
tocsa
senior tag
válasz
Darth Vader
#89
üzenetére
Én is így értelmezem. Tehát laponként lesz egy-egy bit.
Egyéb magyarázat: a PAE pontosan azt a +4 bitet takarja, amivel a Pentium óta a a címszélesség 36 bit lehet, azaz összesen 64 GB memória állhat rendelkezésre a processzeknek. Azonban mint korábban felhívták rá a figyelmet, továbbra sem növekszik meg az egyben megcímezhető memória mérete (4GB). -
#89
Darth Vader
csendes tag
Erasmus
#88
Darth Vader
csendes tag
En ugy ertettem az idezet alapjan, h csak annyi nagy otlet, h lesz egy plusz bit a PTE-ben, ami arra szolgal, h megjelolje azokat a lapokat, melyek futtathato kodot tartalmazhatnak es melyek nem. Persze ez is csak akkor mukodik, h majd tamogatva lesz az oprendszerek altal.
Ugy fog mukodni szerintem, h ha egy olyan lapon levo kod probalna futni, amely lap nem futtathatokent van megjelolve, akkor altalanos vedelmi kizaras jon letre.
Szerintem. -
Erasmus
őstag
Megjelent a Windows XP SP2 leírása: [L]http://www.microsoft.com/downloads/details.aspx?FamilyID=7bd948d7-b791-40b6-8364-685b84158c78&DisplayLang=en[/L]
Ebben részletesen írnak az execution protectionről (NX). Egy részlet a bevezetésből:
------
Execution protection (also known as NX, or no execute) marks all memory locations in a process as non-executable unless the location explicitly contains executable code. There is a class of attacks that attempt to insert and execute code from non-executable memory locations. Execution protection mitigates this by intercepting these attempts and raising an exception.
Execution protection relies on processor hardware to mark memory with an attribute that indicates that code should not be executed from that memory. Execution protection functions on a per-virtual memory page basis, most often changing a bit in the page table entry (PTE) to mark the memory page.
The actual hardware implementation of execution protection and marking of the virtual memory page varies by processor architecture. However, processors that support execution protection are capable of raising an exception when code is executed from a page marked with the appropriate attribute set.
Both Intel and Advanced Micro Devices (AMD) have defined and shipped Windows-compatible architectures for execution protection. Windows supports execution protection on the AMD64 platform and Intel Itanium Processor Family (IPF) processors.
The 32-bit version of Windows (beginning with Service Pack 2 for Windows XP) utilizes the no-execute page-protection (NX) processor feature as defined by AMD. In order to use the NX processor feature, the processor must be running in Physical Address Extension (PAE) mode. The 64-bit versions of Windows uses the NX processor feature on 64-bit extensions processors and certain values of the access rights page table entry (PTE) field on IPF processors.
It is hoped that future 32-bit and 64-bit processors will provide execution protection. Microsoft is addressing possible compatibility issues with existing applications and drivers while working with processor vendors to encourage the adoption and development of execution protection technologies.
------
Ezek szerint a Prescottban mégsincs NX-támogatás, ahogy azt korábban sejteni lehetett.
Valaki le tudná írni, hogy pontosan hogyan is müx majd a dolog?
kösz, -
#87
tocsa
senior tag
Darth Vader
#84
tocsa
senior tag
válasz
Darth Vader
#84
üzenetére
''Ezert mondtam azt, h sok programozo csak szovegel(itt nem rad gondolok), mikorzben fogalma sincs az adott proci igazi kepessegeirol.''
Pedig van meg mit utananeznem a dolgoknak. Azt hiszem irni fogok ebbol a temabol egy cikket. Nem tudtam, hogy a Linux kernel nem hasznal szegmentalast.
Lehet, hogy majd kerdezek toled infokat. -
#86
kisfurko
senior tag
Darth Vader
#84
kisfurko
senior tag
válasz
Darth Vader
#84
üzenetére
OFF
''Ha feluletesen olvasol el egy ilyen konyvet, akkor pl fel sem tunik, h az adott proci tud szegmentalni es milyen vedelemmel rendelkezik.
Sokan szerintem ugy gondoljak, h a szegmentalas elavult dolog, ezert ezt a reszt, adott esetben ki is hagyjak, at se nezik. Igy mondanak utana butasagokat.''
Arról nem is beszélve, hogy ez a legbonyolultabb része a doksinak...:)
No meg a V86-os mód...:o -
#84
Darth Vader
csendes tag
tocsa
#82
Darth Vader
csendes tag
:)) Nem huztam fel magam. Ha te igy erezted, akkor bocs. Semmi bajom sincs veled :))))
Elolvasa alatt azt ertem, h eloszor en mindig ugy olvasom az ilyen konyvet, mint egy regenyt. Elejetol a vegeig. Majd utana, ha valami erdekel ujra, akkor tudom, h hol kell kinyitni. Igy egyuttal mar teljesen tisztaban is vagyok az adott proci kepessegeivel.
Ha valaki nem olvassal el legalabb egyszer teljesen a konyvet, akkor honnan tudhatja, h mit tud a proci valojaban? :)))
Ezert mondtam azt, h sok programozo csak szovegel(itt nem rad gondolok), mikorzben fogalma sincs az adott proci igazi kepessegeirol.
Ha feluletesen olvasol el egy ilyen konyvet, akkor pl fel sem tunik, h az adott proci tud szegmentalni es milyen vedelemmel rendelkezik.
Sokan szerintem ugy gondoljak, h a szegmentalas elavult dolog, ezert ezt a reszt, adott esetben ki is hagyjak, at se nezik. Igy mondanak utana butasagokat. :(((
uDv,
Pedro -
#83
tocsa
senior tag
Darth Vader
#81
tocsa
senior tag
válasz
Darth Vader
#81
üzenetére
Mindazonaltal Mea Culpa egyebkent.
Egyebkent szerintem nem jo indok az, h a portolhatosag miatt bealdozzak a kernel biztonsagat.
Teljes mertekig egyetertek, maximalisan biztonsag parti vagyok. Inkab csokkenjen a rendszer teljesitmenye 3-5%-al (a korabban emlitett megoldasoknak mind-mind van ilyen hatranyuk), netalan 10%-al is, de legyen biztonsagos. -
#82
tocsa
senior tag
Darth Vader
#79
tocsa
senior tag
válasz
Darth Vader
#79
üzenetére
Nyugi. Ne huzd fel magad.
Megigerem, hogy alaposabban utana fogok nezni a dolgoknak, mert egyre jobban foglalkoztat a dolog.
Belenezek majd az Understanding Linux Kernel konyvbe.
Mit ertesz azalatt, hogy olvasni az i386 konyvet? Mert az nem egy olyan konyv, mint az Odusszeia, hogy kinyitja az ember, aztan szepen vegigolvassa. De volt mar olyan hogy beleneztem. Arra valo.
Lesz meg ugyan buffertulcsordulas az AMD megoldasa utan is, de ha hasznaljak a vedelmet, akkor a tulcsordulas megtortenik, de a beinjektalt kod mar nem tud lefutni. Ergo a tulcsordulasos exploitok mind-mind DoS exploitta degradalodnak le. Es ez valami. A szenzaciohajhasz hirek mindent osszeirtak, de abban igazuk volt, hogy ha ez regebben megtortent volna akkor sok fereg nem terjedt volna. A Slammer SQL exploit vagy a Blaster RPC exploitnak is annyi lenne.
Az AMD valszeg azert dontott e mellett, mert rajottek arra, h sok olyan programozo van, aki _nem_ olvas el egy konyvet rendesen, csak feluletesen. Ennek meg is van a kovetkezmenye.
Ezt nem ertem.
Egyebkent nagyon szivesen elolvasnam az Intel sokszaz oldalas konyvet, de _nincs_idom_ ra. Errol nem tehetek. -
#81
Darth Vader
csendes tag
kisfurko
#80
Darth Vader
csendes tag
Szia,
Most szerintem jol latod a kerdest. Egyebkent volt szegmentalas a linux kernelben, de az mar regen volt es pont a portolhatosag miatt vettek ki belole. A gond szerintem az, h sokan pont az x86-ot szidjak, h milyen szar, h meg erre sincs benne vedelem, pedig van, csak bizonyos okok miatt nem alkalmazzak.
Egyebkent szerintem nem jo indok az, h a portolhatosag miatt bealdozzak a kernel biztonsagat. -
kisfurko
senior tag
Szia!
No, itt van a kutya elásva:
''These patches mostly operate by using the x86 segmentation feature to set the code segment 'limit' value to a certain fixed value that points right below the stack frame. The exec-shield tries to cover as much virtual memory via the code segment limit as possible - not just the stack.''
Azért állítják a kód szegmens határait, mert pont az határozza meg, hogy melyik rész futhat. Ami azon kívül van, az nem. Itt tehát a patch a szegmentálást használja. Mivel nem ismerem a Linux kernelt, ezért csak tippelni tudok, hogy valószínűleg tényleg nem használ szegmenseket, ezért kellett ez a patch.
Szóval a probléma nehézsége nem abból adódott, hogy egyáltalán nehéz megcsinálni, hanem abból, hogy csak lapozással kell megoldani. Nyilván nem kellett volna a patch, ha a kernel írói is akarták volna használni a szegmentálást, mert akkor maguk implementálták volna a patch tartalmát. :)
Nem szabad elfelejteni, hogy a Linux platformfüggetlen szeretne maradni, tudomásom szerint viszont nincs másik processzor, ami ehhez hasonló szegmentálást biztosítana. -
#79
Darth Vader
csendes tag
tocsa
#78
Darth Vader
csendes tag
Kedves Tocsa,
Mar ne is haragudj, de te olvastal mar eredeti Intel 386-os konyvet????
Egyebkent ajanlom figyelmed be az Understanding Linux Kernel cimu muvet. Ott leirtak, h miert nincs segmentalas a kernelben!!!!
Egyebkent pedig igen is van vedelem. A gond az, h a mostani ujitas mar a lapok leirojaba is beleteszi azt, amit eddig csak a szegmensleirokban volt benne.
Olvasd el jobban amit ide masoltal. Ott is pont errol van szo!!!
Epp ezert, eloszor _Te_ gondolkozzal es csak utana irj ilyen stilusu hozzaszolast.
Egyebent az AMD modszere sem csodaszer! Csak akkor segithet, ha tenyleg hasznalni is fogjak. De ettol meg ugyan ugy lesz buffertulcsortdulas.
Az AMD valszeg azert dontott e mellett, mert rajottek arra, h sok olyan programozo van, aki _nem_ olvas el egy konyvet rendesen, csak feluletesen. Ennek meg is van a kovetkezmenye. Egyebkent pedig a 2.0.x-es kernelben meg van szegmentalas, h jol emlekszem.
Az altalad felhozzott projectek pedig azert vannak, mert a linux kernel olyan amien. Mivel Linus nem hajlando valszeg segmentalni, ezert maskepp kell megoldani a problemat. Ami igy olyan lett, amilyen. :((( -
tocsa
senior tag
Nnna.
Szóval akkor már ne haragudj, de ezt maga Ingo Molnár irta, a linuxos exec-shield techonógia bejelentése kapcsán. Ez 2003 Május 3.-ra datálódik. Tehát sajnos nem oldható meg olyan egyszerűen a buffer overflow védelem, mint ahogyan azt ti gondoljátok:
''Background:
-----------
It is commonly known that x86 pagetables do not support the so-called
executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
merged into a single 'read or execute' flag. This means that even if an
application marks a certain memory area non-executable (by not providing
the PROT_EXEC flag upon mapping it) under x86, that area is still
executable, if the area is PROT_READ.
Furthermore, the x86 ELF ABI marks the process stack executable, which
requires that the stack is marked executable even on CPUs that support an
executable bit in the pagetables.
This problem has been addressed in the past by various kernel patches,
such as Solar Designer's excellent ''non-exec stack patch''. These patches
mostly operate by using the x86 segmentation feature to set the code
segment 'limit' value to a certain fixed value that points right below the
stack frame. The exec-shield tries to cover as much virtual memory via the
code segment limit as possible - not just the stack.''
De könyörgöm. Gondolkozzatok el egy picit, mielőtt írtok. Ha a 386-os vagy i586 óta megoldott lenne egy ilyen probléma, akkor miért lenne most olyan nagy durranás az AMD féle Execution Protection? Na jó, mondhatjuk, hogy a marketing miatt. De én meg azt mondom, hogyha hw támogatással 100%-ig blokkolni lehetett volna a buffer ovweflow exploitokat, akkor azt az Open Source közösség tutira implementálta volna. Hát nem? Miért szenvedtek volna akkor, miért szenvedett volna Solar Designer, miért fejlesztette volna ki az IBM a ProPolice-t, Miért léteznének szintén ezek a software-es ''erőlködések''?:
IMMUNIX StackGuard
IBM ProPolice
SecureWave SecureStack
mingo féle Exec Shield
PaX stack védelem
HAP patch gyűjtemény stack védelme
OpenWall patch gyűjtemény stack védelme
GRSecurity patch gyűjtemény stack védelme (PaX-on kivül)
LOMAC patch gyűjtemény stack védelme
Hmmm? -
#77
kisfurko
senior tag
Darth Vader
#76
kisfurko
senior tag
válasz
Darth Vader
#76
üzenetére
Meg lehet oldani, hogy ne lassuljon a címfordítás. A címgeneráló pl. fixen hozzáadja a bázist.
Mellesleg tuti, hogy így van, gondoljatok csak a valós módra, ott is folyton hozzá kell adni a szegmens*16-ot (ami ugye a bázis). -
#76
Darth Vader
csendes tag
Alan
#75
Darth Vader
csendes tag
En eddig egy okot talaltam. Lehet,h mas volt az igazi ok.
Ezt az Understanding Linux Kernel konyvben talaltam.
Ez pedig a portolas nehezsege. Egyebkent pedig szerintem nem jo indok, hogy nagyon lelassulna. Valamit bizotos, h lassulna tole a vegrehajtas, de a nyereseg sokkal nagyobb lenne. A stack felulirasa ezzel a modszerrel kivedheto lenne, mivel van kulon stack tipusu szegmens, mely megegyezik a data szegmenssel, csak ez lefele bovitheto.
Amennyiban a stack-et egy kulon szegmensben teszik, akkor megoldhato a stack teljes elkulonites. Igy meg veletlenul sem lehet bele irni, mert a szegmens hatar atlepesenek elso kiserletekor altalanos vedelmi kizaras keletkezik. Innentol kezdve jon az oprendszer es azt csinal a progival amit akar.
[Szerkesztve] -
Alan
aktív tag
Nagyon jól mondod, a 68020-as, a 68030-as (és utódai is) fantasztikus processzorok voltak.
Szerintem két okból nem használják az operációs rendszerek az i386 szegmentálást: egyrészt jelentősen bonyolítaná a memóriakezelő kódját, ami nem biztos, hogy kívánatos, hiszen így is találnak hibákat sok-sok év után is, másrészt a szegmentálás + lapozás egyszerre történő használatával nagyon lelassulna a címfordítás a +1 szint miatt (virtuális cím -> lineáris cím -> fizikai cím a virtuális cím -> fizikai cím helyett), ami TLB miss esetén jelentős teljesítményvisszaesést okozna. De azért bevallom, annyira én nem értek az x86-hoz, lehet, hogy más oka is van. -
#74
Intelligencs
őstag
klumbik
#38
-
kisfurko
senior tag
Már ne haragudj, de tényleg töltsd le valamelyik x86-os (értelemszerűen 386+) processzor programmers (vagy users) guide-ját, értsd meg, majd meglátod, hogy bizony szegmentálással simán elkerülhető ez! Ha pedig arra gondolsz, hogy nem oda tér vissza a program (mert a visszatérési címet felülírta), azt ez a flag sem fogja megoldani. A nemkívánatos stack-felülírás (a visszatérési címre gondolva) csak valami állítható határregiszterekkel lenne megoldható.
OFF
Egyébként az ''i386 nagyon meghaladta a korat'' kijelentés nagyon sántít. Pl. a 68020 (ami vagy 3!! évvel korábban jelent meg) is címzett 4GB memóriát, és a 386-tal egyidőben megjelent 68030 ráadásul 1.5-szer gyorsabb is volt azonos órajelen. Persze nem volt benne szegmentálás, de cserébe egy flexibilisebb lapozás figyelt ott (az utasításkészletről már nem is beszélve). Meg, ugye, a 256 byte kód és 256 byte adat cache... -
#72
tocsa
senior tag
Darth Vader
#10
tocsa
senior tag
válasz
Darth Vader
#10
üzenetére
Sajnos nem.
Az i386 nagyon meghaladta a korat, pl. a 4GB memoria cimzessel, azonban a buffer overflow-s stack feluliras majd vegrehajtas kerdeskore az x86 architekturanak egy hianyossaga volt.
Valaki itt irta, hogy nezzuk mega flag-eket, meg stb. Nezze meg a falg-eket, es azt hogy azok pontosan mit jelentenek stack szegmens eseten.
Ha ez meg lett volna oldva, akkor nem lett volna a rengetek software-es workaround: openwall fele vedelem, majd GRSecurity fele vedelem, PAX vedelem. Vagy az IBM Propolice, egyeb vedelmek. Mind emiatt szulettek. Persze a hardware nyujtotta lehetosegeket most is kisernie es tamogatnia kell az oprencernek, de mar nem kellenek olyan workaround-ok, sokkal egyszerubb lesz a rendszer. Es a hardware-es vedelem nem iktathato ki olyan konnyen, mint egy szoftware-es. -
tocsa
senior tag
Kosz az URL-t.
Jol forditottad. Az eredeti hir is ilyen. Keveri a virust a buffer overflow exploitokkal, habar nagyon sok fereg es virus ilyen tipusu exploit segitsegevel aktivizalodik.
Es az eredeti cikkben sem rantjak le a leplet arrol, hogy itt tulajdonkeppen a verem szegmens flag-rol van szo. -
#70
tocsa
senior tag
Darth Vader
#10
tocsa
senior tag
válasz
Darth Vader
#10
üzenetére
Ezt nem tamogatjak.
Mas architekturak eseten, mint pl SUN UltraSparc, mar regebb ota jol mukodis Stack Szegmens eseten a privilegium flag-ezes. Eddig sem ertettem, hogy miert nem tudjak a flag-eket rendeb rakni ebben az esetben.
Vegre rajottek. -
Gregorius
őstag
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] -
kisfurko
senior tag
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? -
-
rog
addikt
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? -
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)... -
faster
nagyúr
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.
-
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] -
rog
addikt
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? -
klumbik
tag
akkor tulajdonképpen mi ez az amd féle execution protection? mert x flaget eddig is lehetett állítani. sajna nem nagyon jártam utána, milyen újításokat hoz védett módba a k8.
felváltunk x86-64-be úgy mint 386-oson? hoz új opciókat gdt/ldt-ben?
címzés hogy megy, ugyanúgy csak a táblákban a báziscím ki van bővítve?
aki tud valami pár oldalban összefoglalt irományt ne habozzon linkelni! :) -
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...
-
kisfurko
senior tag
''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. -
rog
addikt
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? -
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. -
klumbik
tag
(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] -
kisfurko
senior tag
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?
-
-
rog
addikt
akkor most, hogy a fenébe fog ez működni?
nem engedi meg hogy írjon egy program a stack-re? vagy hogy?
(ez a túlcsordulás nem úgy mókázik, hogy felülírja a stack-ben lévő visszatérési címet, és amikor a végrehajtást vissza kéne adni a függvényt, programot hívó kódnak akkor a vezérlés a gonosz programrészre kerül nem pedig oda ahova kéne.?)
vagy valaki elmesélhetné, mert zavarodok össze-vissza. :) -
kisfurko
senior tag
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. -
#32
Darth Vader
csendes tag
kisfurko
#30
-
kisfurko
senior tag
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
Darth Vader
csendes tag
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.
-
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] -
kisfurko
senior tag
-
#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. -
#24
dabadab
titán
Darth Vader
#22
dabadab
titán
válasz
Darth Vader
#22
üzenetére
Ugy most ezzel nem azt akarod mondani, hogy mivel minden program megkapja a maga 4GB-os address space-et, ez azt jelenti, hogy mindegyikuk ugyanazt a fizikai memoriat latja?... Merthogy termeszetesen ez nem igy van.
-
#21
Darth Vader
csendes tag
dabadab
#17
Darth Vader
csendes tag
Szeretnem figyelmedbe ajanlani az Intel gyari Pentium doksijat.
Ott egyertelmuen ir szegmentalastrol es lagozasrol vedett uzemmodban!!!
Egy szegmens merete 4GB is lehet. Ajanlom figyelmedbe a Linux kernel head.S nevu file-jat. Toltsd le egy linux kernelt, mondjuk a 2.4.24-et. Majd a linux/arch/i386/kernel konyvtar alatt megtalalod ezt a filet. Nezd meg a legveget es ott megtalalod a GDT-t. Ennek a pontos bit kiosztasat pedig megtalalod az intel doksiban. -
-
Erasmus
őstag
Kiegészítettem az URL-t.
Én nem értek ahhoz, hogy hogyan működik a buffer overflow, ezért sem írtam részleteket (amelyekről egyébként az eredetiben sincs szó) és ezért bőven lehet benne hülyeség. Szívesen is venném, ha azok, akik értenek a dologhoz, leírnák (pl. a hőzöngés helyett), hogy hol baromság a szöveg, mert módosítani bármikor lehet.
üdv, -
#17
dabadab
titán
Darth Vader
#10
dabadab
titán
válasz
Darth Vader
#10
üzenetére
Milyen szegmentalas?... Az x86-ok 32 bites modjaban max. szelektorok vannak, nem szegmensek, a szegmens az a 16 bites mod 64K-s szeleteire fenntartott terminus technicus.
Amugy meg konkretan Linuxhoz van is patch, ami a stackrol leszedi az execution flaget, amit egy elozo hozzaszolasban emlitett is valaki, amint azt is hozzatette, hogy a vilag azert messze nem ilyen egyszeru, hogy chmod a-x /proc/stack, aztan jolvan :)
[Szerkesztve] -
#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.) -
#15
Darth Vader
csendes tag
WN31RD
#13
Darth Vader
csendes tag
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. -
#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 -
#10
Darth Vader
csendes tag
Darth Vader
csendes tag
Tudjatok ezzel csak az a baj, hogy az Intel es AMD processzorok jelenleg is tamogatjak ezt.
Csak ugy hivjak, hogy Szegmentalas. A nagy Linux kernel is hasznalna, akkor nem lennenek ilyen gondok. A kerdes persze az, hogy miert nincs szegmentalas a Linuxban?
Most ugy nez ki, hogy minden szegmenst 0-4G-ig megy. Tudjatok, mar az egyszeru i386-osban is benne volt. Van kulon adat, stack es code szegmens is. Az Adat (Data) segment vagy csak olvashato v. irhato is, a stack szegmens is ilyen, de az lefele bovulo, a code szegmens meg csak futtathato, vagy futtathato es olvashato. Ez egy tokeles vedelem. Igy nem is ertem a cikket, meg ezt az egesz buveszkedest.
Az mondjuk igaz, hogy ha csak lapozast hasznalunk, akkor ott nem lehet a futtatasi flaget leszedni, mert ilyen flag jelenleg nincs. -
Hory
aktív tag
Auuuuuu, ez a cikk is fajt.
Már marha régóta lehetőség van a stack-ről leszedni az execute flaget, linuxban meg is csinálták. A marha rég kb. a 386-ot jelenti...
Nem csoda, hogy hirtelen mindenki támogatja. :)
Amúgy szerintem is teljesen másról szólt a cikk, csak elbaltáztátok a fordítását, mert ez így ahogy van, egy nagy hablatty, nem több. -
shtml
őstag
Nem igazán a témához tartozik, de az írás szerzőjének, Erasmusnak szól a kérdésem:
Miért nem adod meg a forrás pontos URJ-jét? Más PH-s szerzők ezt megteszik és ez igen hasznos, ha valaki ellenőrizni akarja a forrást (ami rendszerint bővebb) vagy a forrás weblapon további információkat szeretne keresni a témához.
Kiegészítés:
Jelen esetben pl. szívesen utánanéznék az eredeti cikknek, mert elég gáz lenne, ha ott is kevernék a vírust és a buffer overflow-s exploitokat. Te biztos rendelkezel a cikk URL-jével, akár meg is adhattad volna, más szerzőkhöz hasonlóan. De így semmi kedvem ahhoz, hogy elkezdjek keresgélni a Cneten.
[Szerkesztve] -
dabadab
titán
[ Azert ezt virusvedelemnek hivni kevesse pontos dolog, konkretan egy virusrol sem tudok, ami buffer overflowt hasznalt volna, max wormok lehettek ilyenek ]
''az elmúlt két év során kiadott javítások közel fele szükségtelenné vált volna, ha a technológia korábban is létezett volna''
Dehogy lett volna folosleges, egy buffer overflow - az exploitokat leszamitva - jobb esetben genproterrort okoz, rosszabb esetben viszont nem, csak csendben elrontja az adatokat, vagyis egy buffer overflowt mindenkeppen ki kell javitani. A korrekt megoldas nyilvanvaloan az lenne, ha olyan fejlesztoeszkozoket hasznalnanak, ami eleve kizarja a buffer overflow lehetoseget, mert checkeli a hatarokat (vagyis alap valtozatban sprintf() helyett snprintf(), de sokkal inkabb C helyett vmi modernebb nyelv). -
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. -
-
Turmoil
senior tag
A gyakorlatban úgy kellene használni, hogy a proci egy kivételt generál, ha ilyen történne, és ennek felhasználásával a feljlesztők kijavítanák a hibás szoftverüket.
Mert ha fordítva történik (''a processzor úgyis megvéd''), akkor az további minőségromlást eredményez a szoftvereknél, ami senkinek nem jó.
Szóval remélem nem a hamis biztonságérzet lesz a végeredmény...
Aktív témák
Hirdetés
- LEGO klub
- Androidos fejegységek
- Építő/felújító topik
- Fejhallgató erősítő és DAC topik
- Milyen RAM-ot vegyek?
- GTA V
- Győr és környéke adok-veszek-beszélgetek
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Brogyi: CTEK akkumulátor töltő és másolatai
- A Samsung bemutatta az Exynos 2500-at
- További aktív témák...
- Intel Core I9 14900KF - 24mag/32szál - Új, 1 év garancia - Eladó!
- Intel Core i7-7700K (8M Cache, up to 4.50 GHz) OEM Processor! 27% számlával!
- AMD Ryzen 7 5700X processzor eladó /Garanciás/
- Ryzen 9 7900X /// Bontatlan // Üzletből, számlával és Garanciával!
- Ryzen 9 7900 /// Bontatlan // Üzletből, számlával és Garanciával!
- Phanteks NV5 MK2 White (PH-NV523TG DMW02)
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Samsung Galaxy A32 4G 128GB, Kártyafüggetlen, 1 Év Garanciával
- Csere-Beszámítás! RGB Számítógép PC játékra! R5 5600X / RTX 3060Ti 8GB / 32GB DDR4 / 500GB SSD
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest