'Enhanced Virus Protection' voor AMD64-processors

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.

Reacties (40)

[SvMp]

Dat zou dus betekenen dat een processor hardware matig in de gaten houdt of er een buffer-overrun optreedt, net zoals dat de processor bijv. in de gaten houdt of er in een code segment wordt proberen te schrijven of alleen-lezen data wordt gewijzigd.

Leuk en aardig, maar de mogelijkheid voor bufferoverruns worden gegeven door slordigheid van programmeurs. Nu pakt de hardware-industrie dit op. Niet vreemd, want er valt geld mee te verdienen, onder zowel consumenten als bedrijven is dit een aansprekende feature. Echter, imho zijn het toch de programmeurs die verantwoordelijk zijn voor het afleveren van goed werk. Het risico bestaat dat de aandacht van programmeurs op dit punt verslapt. Immers: De gevolgen zijn niet zo groot als de hardware dit probleem afvangt.

Als de hardware echter een exception genereert, net zoals dit gebeurt bij andere foute geheugen-activiteiten, zoals de twee in de eerste alinea door mij genoemde voorbeelden, dan kan dit echter een uitkomst zijn: Exceptions stoppen het programma, programmeurs krijgen snel in de gaten dat er wat fout zit en de gevolgen zijn minder fataal. En omdat programma's die gestopt (wat alleen geldt voor buffer-underruns die bij normaal gebruik kunnen optreden, buffer-underruns die door extreem gebruik ontstaan, degenen die meestal worden gebruikt door virusmakers, blijven veel langer onder de oppervlakte) worden irritant zijn voor de gebruiker, worden programmeurs extra geprikkeld om maatregelen in de bouwen die de bufferunderrun voorkomen.

[JeroenB]

Het lijkt me dat het ook zo werkt, aangezien het tegenhouden van een operatie (ook al is het een security-risico) ervoor zorgt dat een applicatie niet meer verder kan. De "state" is in software zo belangrijk, vooral op het niveau van assembler instructies, dat je niet simpelweg kan zeggen: "ok deze instructie niet, we pakken het wel weer op bij de volgende". Dus een exception gooien is waarschijnlijk ook hoe het wordt opgelost.

[Verwijderd]

Leuk en aardig, maar de mogelijkheid voor bufferoverruns worden gegeven door slordigheid van programmeurs.

Je woord 'slordigheid' vervangen door 'menselijkheid' en je weet waarom dit feature een prettig vangnet is voor grote ingewikkelde applicatie's, geschreven door vakkundige ontwikkelaars.

[Verwijderd]

Net zoiets als. Waarom heeft een auto gordels, abs, airbags, kreukelzones en weet ik het allemaal niet?
En dan toch met een slok op achter het stuur?

Als jij op je machine een omzet van tonnen per dag draait dan wil je dat er alles aan gedaan is om elke calamiteit zoveel mogelijk te voorkomen. (en dus geen x86 te kopen naar Unix/Sun)

[it0]

Hoe weet de processor nu welk geheugen waar bij hoort?
Of kan je nu een stuk beschermd geheugen malloccen?

Kan iemand vertellen waarom dit beter zou zijn als het in hw is ipv in de kernel?

Als je het mij vraagt werkt het sloppy coding in de hand..

[Verwijderd]

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

[Verwijderd]

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.

[BurningSheep]

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?

[JeroenB]

Het is niet zozeer beter, het is gewoon extra veiligheid en dat kan nooit kwaad.

Om een voorbeeld te noemen: waar ik zit staat een goeie firewall die ervoor zorgt dat niks vanaf het internet een verbinding kan maken naar mijn PC. Toch zorg ik ervoor dat alle patches op mijn PC zijn toegepast, ook de security-gerelateerde patches. Waarom doe ik dit? Omdat het stom is om al je geld op 1 ding te zetten.

Daarom is het niet verkeerd om te zeggen dat ze alle problemen in software moeten oplossen, maar is het ook niet verkeerd om ondertussen dit ook in hardware aan te pakken.

[egeltje]

Het is niet zozeer beter, het is gewoon extra veiligheid en dat kan nooit kwaad.

Toch moet je voorzichtig zijn met dit soort uitspraken.
Veiligheid voor de een is vaak een beperking van de ander. Het hele DRM verhaal gaat over veiligheid voor de muziek industrie, maar het beperkt jou van bv het afspelen van muziek waar je niet voor betaald hebt. Door het plaatsen van een firewall, kan er niemand naar binnen, maar ook niet veel meer naar buiten. Een iemand (de bedenker van de policy) regelt dan wat wel en niet mag en die ene heeft heel veel macht.

Ik ben absoluut voor dit soort initiatieven (van processorbouwers), maar we moeten niet klakkeloos aannemen dat het alleen maar tegen virusaanvallen helpt en in de gaten houden wat ze er precies mee gaan doen. Net zoals de firewall beheerder in de gaten gehouden wordt / hoort te worden.

[KatirZan]

Een extra veiligheid? Waarom doen ze dit niet voor de 32bit versie? Is dit niet mogelijk of hoe zit dat?

[Verwijderd]

Omdat ze willen dat iedereen een Athlon64 koopt, de XP wordt alleen nog maar verkocht als budget cpu en het is voor hun niet interessant om daar nog verbeteringen (=ontwikkelings kosten) aan te brengen.

[Verwijderd]

@KatirZan

Zoals ik hier beneden al gezegd heb: de Intel x86 architectuur (IA-32) ondersteunt dit niet.

[off-topic]
Kom maar op met die dubbel-post
[/off-topic]

edit:
verduidelijking

[procede]

Extra veiligheid altijd beter? In dit geval zal het wel goed zitten, maar hoeveel systeembeheerders zijn er we niet die het systeem zo hard dicht timmeren dan mensen hun werk niet meer goed kunnen doen, omdat ze denken dat veiligheid op de eerste plaats komt?

Voor de duidelijk: Dat het systeem werkt is één, dat het veilig is is twee. Anders zouden we tenslotte gewoon beter alles uit kunnen zetten...

[JeroenB]

Dat was mijn uitgangspunt natuurlijk ook. Dat ik stel dat extra veiligheid nooit kwaad kan wil niet zeggen dat ik bereid ben om functionaliteit daarvoor op te offeren. Maar dat lijkt me zo voor de hand liggen dat ik het niet eens expliciet noem. Misschien heb je gelijk dat dat wel een issue is.

[Verwijderd]

Gouden regel van de systeembeheerders.

Als de gebruikers niet komen klagen dat de boel te dicht zit dan heb je iets niet goed gedaan.

Trouwens, makkelijk te verhelpen en daar uren op te schrijven. En even te laten weten hoe machtig je bent. (Mwuhahaha)

[Verwijderd]

geallocate pages hebben vlaggen die vertellen of je er mag schrijven, lezen, en uitvoeren (en nog wel meer). virussen hangen zich vaak aan de laatste sectie van een .exe, die meestal niet-uitvoerbaar is. normaal boeit dat de processor niet.

virussen kunnen nu wel die laatse sectie uitvoerbaar maken, maar dat valt nogal op voor de antivirus software.

om bufferoverruns lastiger te maken, is een niet uitvoerbare stack wel een goed idee.

[Mars Warrior]

Ik heb geen idee hoe ze het in dit geval implementeren, maar op andere OSsen (neem OpenVMS op een VAX of Alpha) moet je heel veel privileges hebben en heel veel programmeer en vooral OS/KERNEL structuur kennis om deze geheugenmanagement protectie te omzeilen door de pageprotectie van een stuk geheugen (even/tijdelijk) te veranderen.

Vandaar denk ik dat Windows gewijzigd moet worden, om een API + Security toe te voegen, waar bijv. een JIT compiler (Java / .NET) gebruik van kan maken om runtime gegenereerde code executeerbaar te maken...

Kortom: eerst maar eens afwachten wat nu de exacte implementatie en features/beperkingen zijn voordat we echt kunnen beoordelen wat dit nu betekent qua beveiliging.

En zoals al eerder opgemerkt: programmeurs kunnen heel veel baat hebben bij hardwarematige page protecties om fouten uit hun eigen software te halen. Elke OpenVMS programmeur ondervind dit aan den lijve als die overstapt naar een ander OS

[Verwijderd]

Nu nog voor Windows Server 2003!
Ik heb die chip namelijk speciaal voor mijn webservers gekocht.

[Verwijderd]

Met beetje geluk komt het straks ook in Linux Kernel...
Is linux NOG beter beveiligd :-)

En dan is je webserver (Linux ipv Win2003) helemaal betrouwbaar & beveiligd! (Is nl een van de plekken waar Linux echt stukken beter in is)

[Verwijderd]

Langs de ene kant vind ik het een goede stap, maar langs de andere kant heb ik toch een bedenking.

Als een n00b nu in een advertentie voor een PC leest dat die 'Enhanced Virus Protection' heeft, gaat hij simpelweg denken dat z'n pc immuun is. Kan hij lekker op alle attachments en rommel gaan klikken, met alle gevolgen van dien ... Het zal wel wat dingen tegenhouden, maar zeker niet alles.

[Verwijderd]

Veel mensen snappen precies niet wat het nut is van die feature.

Het is geen beveiliging tegen buffer overruns op zich, het zorgt er alleen wel voor dat bij een geknoei met de stack, er geen ongewenste code kan worden ge-execute.

Het komt er gewoon op neer dat de cpu onderscheid kan maken tussen bytes die data voorstellen en bytes die code zijn, en dat deze cpu door dit onderscheid ervoor kan zorgen dat men via een geforceerde bufferoverrun geen code kan uitvoeren.

Buffer overruns blijven mogelijk, want dat is en blijft simpelweg een bug in de programmatie.

Buffer overflow protectie is een gevolg van de techniek, niet de expliciete bedoeling ervan. Het is een gewoon een algemene extra security feature. Welke ook zeer degelijk zijn nut kan bewijzen bij het debuggen van applicaties.

[emgaron]

Komt dit dus ook eindelijk voor Windows beschikbaar... Andere OS/hardware kombinaties hebben dit al langer (b.v. OpenBSD/Sparc).

[Verwijderd]

Ja, dit is dan ook voornamelijk een tekortkoming van de Intel x86 architectuur (IA-32) en niet zozeer van Windows. Bij een x86 kan je niet aangeven of de data een geheugen range wel of niet ge-executeerd mag worden. OpenBSD heeft dit ook niet op een x86

edit:
verduidelijking

[Verwijderd]

Die bescherming is er wel, alleen op segment niveau en niet op page-niveau, design error van Intel, de meeste operating systemen maken namelijk gebruik van de tweede...

[Verwijderd]

Heet zoiets niet OF een buffer underrun OF een buffer overflow.

[Verwijderd]

Buffer overrun komt ook wel voor. Netzo als stack smacking trouwens.

Tik maar eens "buffer overrun" in in google

[Voyage]

Ik hoop dat ze erin slagen om virussen tegen te houden. Ik snap echt niet waarom er een paar negatieve reacties bij staan hoor. Ze doen er toch wat aan om virussen tegen te houden.

[cleopet]

Tja Dit lijkt me voor Ms wel een handige zet.

Op deze manier kan je een hoop fouten van het OS ondervangen, nog voordat je een patch van een eventuele exploid ter beschikking hoeft te stellen.
(no flame intended)