MS gaat hardwarematige beveiling K8 en Itanium gebruiken

Microsoft zal in Windows XP SP2 gebruik gaan maken van 'execution protection', een feature die de beveiliging van een applicatie kan verbeteren door samen te werken met de hardware. NX - zoals het wordt genoemd - zorgt samen met de processor voor strikte scheiding tussen data en code, waardoor het een heel stuk moeilijker wordt om misbruik te maken van buffer overflows. Op het moment kennen alleen Intel Itanium en AMD64-processors dit trucje, maar Microsoft verwacht dat ook toekomstige 32-bits en 64-bits processors er ondersteuning voor zullen bieden. Er worden niet veel compatibiliteitsproblemen verwacht, maar programma's die dynamisch code genereren zoals just-in-time compilers zullen er wel rekening mee moeten gaan houden. NX staat in principe nog los van NGSCB en hardwarematige DRM-systemen, maar het betrekken van de hardware bij de beveiliging van software is natuurlijk wel duidelijk stap in die richting, aldus The Register. SP2 wordt in de eerste helft van 2004 verwacht:

"Application and driver developers should be aware of execution protection and the requirements of software running on a supporting platform. Applications that perform just-in-time (JIT) code generation or execute memory from the default process stack or heap should pay careful attention to execution protection requirements. The .NET Framework, for example, works with the NX bit set."

Reacties (31)

Vreemd dat het .Net framework hier geen last van heeft. Dat is wel geen JIT ding maar lijkt me dat tijdens design hiervan al rekening mee gehouden moet zijn om narigheid te voorkomen. Wel jammer als er de JVM of al die JIT emulatoren er last van gaan krijgen. (Ik sluit complottheorieen maar ff uit)

En ook al word de NX bit in hardware ingebakken, als je hem uit kan zetten of omzeilen schiet je er uiteindelijk nog weinig mee op. Net zoals met die protected mode voor x86's.

En ook al word de NX bit in hardware ingebakken, als je hem uit kan zetten of omzeilen schiet je er uiteindelijk nog weinig mee op. Net zoals met die protected mode voor x86's.

De beveiliging werkt juist voordat een stuk exploit code wordt uitgevoerd (en dus de kans krijgt deze mode uit te zetten). Immers omdat deze code als (stack-)data binnenkomt zal deze niet uitgevoerd kunnen worden.

Jouw redenering komt neer op "Een deurslot heeft geen nut, want je kan hem van slot zetten waarna inbrekers gewoon binnen kunnen wandelen" :-)

Software die hier problemen mee gaat krijgen is simpelweg gewoon niet goed geprogrammeerd. Op het moment dat je data gaat uitvoeren zonder het te markeren als uitvoerbare code ben je verkeerd bezig, het is niet alleen slordig maar je maakt je programma dus ook zeer gevoelig voor exploits, zoals dus al aangegeven is is dit de rede waarom buffer overflow aanvallen mogenlijk zijn.

Hahah, juist maak dat microsoft graag even duidelijk Volgens mij gaat Windows niet eens lopen op dit gedoe Aangezien hun enorme aantal exploits afgezien van de exploits die nog niet gevonden zijn... Lijkt me goed idee, indien er geen performance verlies optreedt. En dat combineren met DRM is helemaal een zooi, dat trusted gedoe gaat gewoon te ver, nog even en je houdt geen computer meer over, je kan dan alleen nog op Start klikken...

Dat ze het uiteindelijk met DRM willen combineren vind ik inderdaad wel een beetje minder. Wel is het zo dat windows zelf hierdoor natuurlijk een stuk stabieler en veiliger word want je neemt in 1 keer de kans op buffer overflows weg en dus krijg je minder patches.

Wow! De vooruitgang anno 2003

De aloude VAX (1976!!) en de nieuwere Alpha processoren gebruikten naast de "normale" beveiligingen/rechten in het OS (user/executive/kernel/supervisor modes, file/object protecties, gebruikersrechten) al vanaf het begin hardware matige page protection die domweg bepaalt of een bepaalde pagina toegankelijk is:

- V: Valid
- FOE: "Fault on execute", Whenever an attempt to execute instructions in this page occurs, the processor reports an error and passes control to the operating system
- FOW: "Fault on write", As above, but an error on write
- FOR: "Fault on read", As abobe, but an error on read
- KRE: Code running in kernel mode can read this page
- URE: Code running in user mode can read this page
- KWE: Code running in kernel mode can write to this page
- UWE: Code running in user mode can write to this page
- Page frame number

Wat nu het verschil is en of er verschil is met het NX bit is me even niet duidelijk, maar het nut kan ik uit jarenlange ervaring met VMS/OpenVMS enkel onderschrijven: het maakt systemen niet alleen robuuster, maar ook ontwikkelaars worden eerder op fouten gewezen die ZONDER deze protecties vaak maar moeizaam te achterhalen waren (foutief verwijzende pointers om maar iets te noemen

En nu inderdaad maar hopen dat AMD/Intel dit ook doorzetten in hun volgende processoren en OS leveranciers dit vervolgens toepassen!

maar programma's die dynamisch code genereren zoals just-in-time compilers

Even voor de kenners: wat bedoelen ze hier mee? Als je bv in Delphi runtime componenten aanmaakt ipv gebruik te maken van de resource DFM (Data)heb je dan opeens ook een probleem? Nee toch?

Het aanroepen van andere code (ook al wordt die runtime geladen) is geen probleem, anders zouden wel heel veel applicaties in de problemen komen. Alleen als je dynamisch code wil genereren en direct wil uitvoeren wordt het lastiger, omdat je dan eerst een stuk geheugen als data moet markeren (om er naar te kunnen schrijven), en het vervolgens als code moet worden aangeduid om het te mogen uitvoeren.

Veel emulators voor bijvoorbeeld N64 en PS, Mac of andere modernere systemen maken gebruik van dynamische hercompilatie om performance op peil te houden.

Ook Java en andere VM's (zoals .NET) zijn in principe emulators van een niet-bestaande hardware, tegenwoordig maken die ook veelvuldig gebruik van dynamische hercompilatie.

JIT compilers zijn compilers die tijdens het draaien opnieuw delen van de code kunnen compileren zodat je met aangepaste code door kan testen zonder opnieuw de test te moeten beginnen.

Als de itanium en de AMD64 cpu`s dit kunnen, kan de digital/compaq/hp ALPHA het dan ook niet ?

Volgens mij zijn daar uberhaupt geen Windows XP versies voor, dus dit doet niet ter zake lijkt mij.

jawel,
http://www.microsoft.com/WindowsXP/64bit/default.asp
maar er zijn inderdaad weinig mensen die dit hebben.. maar ze denken iig vooruit.

Voor de Intel 64 bit cpu is inderdaad al een 64 bit XP versie. Voor de 64 bit cpu van amd is hier enkel nog een beta versie van. Voor de Alpha is alleen een versie van windows NT 4.0

moet natuurlijk wel ondersteunt worden door de CPU, 64bit cpu != NX bit.

Itanium en AMD zijn min of meer afgeleide van alpha technologie.....

De enige relatie tussen AMD en de Alpha-processor is dat de K7 dezelfde bustechnologie gebruikt als de Alpha 21264 en dat een paar ontwikkelaars van de AMD Athlon eerst aan de Alpha hebben gewerkt. De Athlon 64 en Opteron hebben niets gemeen met een Alpha of het moeten enkele designprincipes zijn die je bij alle moderne processors ziet terugkeren.

De VLIW-architectuur van de Itanium heeft weinig gemeen met de RISC-architectuur van de Alpha. De IA-architectuur is ontwikkeld door Intel en HP. Die ontwikkeling begon lang voordat de Alpha-divisie van Compaq door Intel werd overgenomen.

"Op het moment kennen alleen Intel Itanium en AMD64-processors dit trucje"

ONZIN!

Zelfs de MC68010 (>15 jaar geleden) had al een optie om memory pages als execute of data only te markeren.

Zover ik weet kent elke "moderne" CPU met een MMU (Memory Management Unit) dat "truukje"

Het verschil tussen protected mode etc.. en dit truukje is dat alle andere eenvoudig omzeilt kunnen worden. Dit is gewoon een hardware matige beveiliging die het uitvoeren van data tegen houd, of het programma nou hoog of laag springt het word niet uitgevoerd, dat is dus ook de rede waarom een aantal JIT compilers er problemen mee kunnen krijgen daar ze een dergelijke beveiliging vroeger simpelweg konden omzeilen.

Het verschil tussen protected mode etc.. en dit truukje is dat alle andere eenvoudig omzeild kunnen worden.

Nee. Het OS biedt op dit moment misschien wel de mogelijkheid die vlaggetjes anders te zetten op bijv. een IA32 cpu, maar dat kan een applicatie zeker niet op eigen houtje doen zonder medewerking van het OS.

Effetjes snel "beveiling" in titel fixen

Het gaat hard, elke week wel een aankondiging waar wat drm bij zit, stilletjes aan worden we gewoon met open ogen ge-DRMamd

Yep, and look who's leading the parade...

Ik ken dit geval van linux met grsecurity, of met de default security policy van OpenBSD. Wat betreft Java is er wel een mouw aan te passen: je kunt met een tooltje je binary taggen zodat ie door het systeem met rust gelaten wordt.

Verder hoop ik dat MS stack randomisation eens gaat implementeren. Als je nu de exploits ziet, elk MS OS zowat dezelfde offset, zou ietsje kunnen verschillen. Als ze nou die stack gaan randomizen, kunnen er nog steeds buffer overflows plaatsvinden, maar weet de exploit nooit waarnaar ie de instructiepointer moet zetten op het moment dat ie hem wil uitvoeren. Kans van 1 op de 4 miljard dat zo'n exploit dan nog werkt.

Word hoog tijd dat die feature eens in consumenten CPU's gebakken word, dit had Intel al moeten doen toen ze Protected Mode erin bakten.

Vreemd. Ik weet zeker dat protected mode ook al een functie heeft een pagina als strikt 'code' of strikt 'data' te markeren.

De meeste x86 besturingssystemen omzeilen dit echter door het code en data segment te laten overlappen en dezelfde permissies te geven. Maar er zijn patches (in ieder geval voor linux, OpenWall) die deze beveiliging weer gebruiken, alleen geeft dat inderdaad problemen met 'just in time' compilers en stack based execution van zogeheten 'trampolines'.

yup al sinds de 386 of anders pentium worden deze dingen al ondersteund. zitten wat admin bitjes en zo op, maar word gewoon weinig gebruik van gemaakt. NT gebruikt het al wel een beetje, maar niet echt optimaal.

Dus deze post is meer marketing dan wat dan ook.

Ik denk dat over een jaar het grootste deel van de nieuwe pc's voor consumenten deze feature wel zal ondersteunen, er vanuit gaande dat Intel het ondersteunt in Prescott (dit moet volgens mij haast wel een deel van LaGrande zijn) en AMD geen gigantische leveringsproblemen krijgt met zijn Athlon 64-chips.

Ik heb nu al problemen met de registratie van een legale versie van Windows XP. Ik ben bang dat 1% van de gebruikers straks de software niet kan gebruiken, omdat de beveiliging niet werkt. En er is niks vervelender dan legale software die niet werkt omdat het vermoedt dat je een copie hebt.

Wat heeft het legaal of illegaal zijn van jouw Windows XP installatie te maken met execution protection?

Helemaal niets. (beetje beter lezen ok?)

Het gaat hier om beveiliging van code, of eigenlijk het hardwarematig scheiden van uitvoerbare code en data, zodat een (niet gedetecteerde-) buffer overflow niet kan leiden tot een exploit.

ik denk dat je een beetje voorzichtig moet zijn met de term 'beter lezen'. Je doet het zelf blijkbaar ook niet al te best. In de tekst staat toch duidelijk:

NX staat in principe nog los van NGSCB en hardwarematige DRM-systemen, maar het betrekken van de hardware bij de beveiliging van software is natuurlijk wel duidelijk stap in die richting,

Daar doelt douchekop op. Beveiliging is voor de gebruiker meestal alleen maar hinderlijk. De industrie is de degene die het meeste belang bij DRM en NGSCB heeft. Wat boeit het de fabrikant als jij je softwarepakket niet kunt gebruiken? Als je maar wel netjes ervoor betaald hebt.

Zoals ze het nu brengen lijkt heel positief. Maar ik denk dat wij als gebruikers heel kritisch moeten zijn, zodat we ons niet geen dingen opgelegd krijgen die onze vrijheid beperken.

Het scheiden van code heeft wel degelijk invloed: als jij geen goedgekeurde programmas gebruikt kun je de data niet verwerken. Of erger: als jij bv geen WMP met DRM gebruikt kun je geen WMA spelen. Of je betaald voor 1x spelen en daarna kun je het niet meer afspelen.
Het heeft weliswaar geen direct veband, maar het is wel weer een stap in de richting.