Misschien eerste even zeggen wat er gebeurt: geheugen ranges kijken een bit mee waarin wordt aangegeven of wat er in de geheugen range staat ge-executeerd mag worden of niet.
Hoe weet de processor nu welk geheugen waar bij hoort?
Dat weet hij niet, maar in de meeste executables is wel redelijk goed aangegeven wat data is en wat code is. Als het OS nu een executable laad kan hij dus voor bepaalde stukken geheugen het hardware bit aanzetten dat zegt dat daar geen executie in plaats mag vinden. Aangezien de stack per definitie bij de data hoort kan dus de code die daar neergezet wordt in een buffer overrun attack niet meer uitgevoerd worden.
Of kan je nu een stuk beschermd geheugen malloccen?
Dat zal de default zijn, aangezien het data is. Je zal moeite moeten doen om een stuk geheugen te alloceren dat je wilt gebruiken als plaats waar je code wilt executeren.
En dan komen we gelijk bij het grootste nadeel: dit werkt dus allemaal niet lekker in het geval van JIT (just in time compiling) zoals dat vaak bij Java gebeurt. Daar worden namelijk constant stukken geheugen ge-alloceerd waar code geplaatst wordt...
Kan iemand vertellen waarom dit beter zou zijn als het in hw is ipv in de kernel?
De kernel zou dan bij iedere uit te voeren instructie moeten controleren of deze wel mag of niet. Dat maakt de hele boel nogal traag
Bovendien kunnen er fouten in kernel zitten (lees: mogelijke buffer overruns), waardoor het mogelijk wordt de kernel te omzeilen.
Als je het mij vraagt werkt het sloppy coding in de hand..
Dat is maar gedeeltelijk waar. Ja kan nu altijd nog een denail of service attack doen: met dezelfde buffer overrun. Maar je kan beredeneren dat dit minder erg is
edit:
typos & verduidelijking
En dan komen we gelijk bij het grootste nadeel: dit werkt dus allemaal niet lekker in het geval van JIT [..] constant stukken geheugen ge-alloceerd waar code geplaatst wordt...
Dat is geen nadeel, dat is juist simpel, de JIT compiler moet een aanpassing krijgen op 1 onderdeel, dat dat geheugen markeert als code en klaar ben je.
Maar wat voor beveiling is het dan als het simpel te omzeilen is?
In andere woorden, wat houdt een virus schrijver tegen om dezelfde aanpassingen te maken als de programmeurs van een JIT compiler?
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
Vandaag heeft AMD officieel bekendgemaakt dat met de komst van ServicePack 2 voor Windows XP, alle in 2003 uitgebrachte AMD64-processors een beveiligingsfeature zullen ondersteunen. Deze feature noemt AMD 'Enhanced Virus Protection' en is bedoeld om in combinatie met Microsofts 'Data Execution Protection' in Windows XP SP2 bepaalde virusaanvallen tegen te gaan. De naamgeving suggereert misschien meer, maar de feature richt zich specifiek op het stoppen van zogenaamde 'buffer overrun exploits'. De IT-sector ziet beveiliging als een keten van maatregelen; softwarematig, hardwarematig en beleid (policies). Ook andere bedrijven werken aan hardwarematige beveiligingfeatures op allerhande gebied, zoals bijvoorbeeld Intel met LaGrande Technology, NX (no execute), Trusted Platform Module en smart cards. De release van Windows XP SP2 wordt verwacht in het tweede kwartaal van dit jaar.
11:03
01:47
Door 
