Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 46 reacties
Bron: ZDNet

Met SP2 voor Windows XP introduceert Microsoft een veiligheidsfunctie, Data Execution Prevention (DEP), waarmee voorkomen wordt dat bepaalde gevaarlijke code uitgevoerd wordt. De DEP-technologie wordt met Service Pack 2 vooralsnog echter alleen in AMD-processors ondersteund en dit bedrijf grijpt deze kans dan ook met beide handen aan om zijn chips aan te prijzen omwille van hun veiligheid. Dankzij de implementatie van de NX-bit (No Execute) zijn de Athlon 64's, Sempron's met de K8-core en Opteron's immers voorzien van deze DEP-technologie. De Itanium is voorlopig Intels enige chip die van een dergelijk veiligheidssysteem voorzien is, hoewel het bedrijf van plan is DEP in het volledige processorgamma te gaan verwerken onder de naam XD (Execute Disable). De belangrijkste functie van DEP is het voorkomen van buffer overflows door onderscheid te maken tussen code en data.

Athlon 64
Moderatie-faq Wijzig weergave

Reacties (46)

Dat is dan het eerste goede wat ik lees over SP2. Ik hoorde ondertussen van insiders dat IBM in Amerika SP2 voorlopig niet installeert en dat ze daar niet de enige in zijn.

Blijkbaar wijzigt SP2 het DCOM model waardoor een groot aantal applicaties, inclusief Microsoft applicaties, niet meer naar behoren werken.

Ik heb ondertussen Windows Update uitgeschakeld zodat het niet automatisch wordt geinstalleerd.
Het is ook nooit goed :z

Honderd keer per dag hoor je hier "Microsoft moet ActiveX security nondeju eens bijwerken, dat kreng is veel te lek!"

Doen ze het een keer, krijg je weer gezeik met dat er feitelijk software kapot door gaat :z

Vloek op de software developers die in ActiveX misbruikt hebben, niet op degenen die het op publiek verzoek dichttimmeren.
Microsoft heeft de securityhole genaamd ActiveX geintroduceerd destijds, dus zij zijn schuldig aan de ellende die de klanten nu overkomt. Een update die vervolgens het security probleem oplost maar bestaande applicaties doet crashen lijkt me overigens geen oplossing om trots op te zijn...
alles wat niet meer werkt gebruikt dat "security gat" dus eignelijk is het maar goed dat alles niet meer werkt, want die security hazards, die moeten we kwijt.
Dus, f je bent blij, want de security is goed nu, f je bent boos omdat je VOLKOMEN KUT geprogrammeerde app niet meer werkt.
Als je app niet meer werkt nadat er EINDELIJK op vele verzoek een keer beveiliging geimplementeerd is die allang overdue was, dan denk ik toch dat je bij jezelf te raden moet en niet MS de schuld geven. ik weet wel dat dat onder veel van de mensen die zichzelf onder de technisch onderlegde gebruikers scharen wel een beetje modieus is, maar nu zit je dus toch een keertje fout.
Van insiders? Dat stond uitgebreid op websites als webwereld hoor ;)

Ik denk persoonlijk dat het allemaal wel mee gaat vallen. Er zullen ongetwijveld wel een klein aantal applicaties zijn die niet meer naar behoren werken, maar ik las ook al dat Microsoft daarvoor al patches klaar heeft. Ik denk niet dat het 'speciaal' is dat een groot bedrijf als IBM met bijna een half miljoen desktop pc's wacht met het installeren van een Service Pack. Je hebt wel een erg slechte applicatie management als je het klakkeloos installeert.

Ik denk verder niet dat zich problemen zullen voordoen vanwege de NX-bit (@twabi2). Deze functie zat al in Windows Server 2003 en ik heb nog nooit gehoord dat bepaalde applicaties op dit OS niet meer werken onder bepaalde AMD processoren. Behalve misschien malafide applicaties die buffer overflows veroorzaken, maar die applicaties wil je in de eerste plaats niet op je pc of server geinstalleerd hebben, lijkt mij ;)
Dan kun je je firewalls ook wel weghalen en voor je hele netwerk een rits public IPs registreren en gaan gebruiken. Dat NAT daar gaan je applicaties ook van over de zeik, probeer jij maar een sop elke Pc op poort 21 een FTP server te hosten dan. dat gaat niet. je kan ook niet zomaar quaken met je vriendin die thuis zit omdat ze je server niet zomaar kan bereiken. Lastig, lastig.
Pff, je bent zwaar aan het overdrijven.
Ja tot op zekere hoogte klopt het wel (naja de compatibiliteit in het algemeen dan heb ik ook gehoord, maar ik zou niet weten of het specifiek het DCOM model is of niet), maar dan heb je het gewoon over een enkel programma dat mogelijk niet zou kunnen werken en als bedrijf wil je dat eerst even zeker weten (en evt oplossen) voor je zoiets als SP2 op je tig computers installeert.

Als consument valt er denk ik weinig te vrezen, misschien een enkel ding dat even niet helemaal wil werken, maar dat heb je ook bij major releases dus zeker braaf-upgradende consument hoor je daar niet van op te kijken.

Ik draai nu al een behoorlijk tijd de RC's van SP2 (sinds april ofzo) en ik ben nog geen enkel programma tegen gekomen dat weigerde te starten o.i.d. en heb ook geen crashes gehad die er daarvoor niet waren (wel af en toe wat gekloot met het OS zelf maar het was ook nog maar een beta).
Ik denk dat IBM weinig keuze heeft. Microsoft heeft in hun contracten met de OEM's opgenomen dat ze het binnen 90 dagen na de release van het SP standaard moeten gaan installeren op hun geleverde pc's met Windows, op straffe van forse boetes als ze dit niet doen.
Waarom moet Intel weer een andere benaming gaan voeren voor iets wat al op de markt is ? XD in plaats van NX ??? het doet allebei hetzelfde dus .... Toch een beetje zielig imho. Kunnen ze straks de nietsvermoedende consument verleiden met het 'Nu met XD(tm) Technologie!' waarbij de consument weer denkt, hee AMD heeft die technologie niet, dus zal wel bagger zijn .... met Intel is mijn PC veeeeel veiliger omdat daar geen Virus Code gedraait kan worden ?!?! .... naja zal wel aan mij liggen.

In iedergeval een goede zaak voor AMD en hopen dat de markt een beetje door gaat krijgen dat AMD erg innovatief is de laatste tijd en dat Intel daar een beetje achteraan hobbelt...
In iedergeval een goede zaak voor AMD en hopen dat de markt een beetje door gaat krijgen dat AMD erg innovatief is de laatste tijd en dat Intel daar een beetje achteraan hobbelt...
Opletten:
De Itanium is voorlopig Intels enige chip die van een dergelijk veiligheidssysteem voorzien is
En de Itanium bestaat al langer dan vandaag ;) Lezen, dan hoef je in het vervolg niet meer zulke AMD-aanhanger posts te posten

En dat ze een andere naam gebruiken is meer dan logisch, denk je nu echt dat als AMD bv met Hyperthreading zou komen dat ze het dan ook zo zouden noemen?!?!
En dat ze een andere naam gebruiken is meer dan logisch, denk je nu echt dat als AMD bv met Hyperthreading zou komen dat ze het dan ook zo zouden noemen?!?!
En waarom niet eigenlijk??
AMD heeft toch ook MMX en SSE enzo over genomen en dat heet bij AMD het zelfde als bij intel, omdat het ook gewoon de zelfde techniek is.
En dat is nu toch ook gewoon het geval maar dan andersom?
Waarom moet Intel er weer een andere naam aangeven, zo schep je toch alleen maar verwarring?
Wat ik bedoelde is dat Intel al lang de Itanium met deze feature heeft en het toen ook al XD (Execute Disable) heette, je kunt je dus afvragen wie er hier nou eigenlijk echt een andere naam geeft aan dezelfde techniek :)
Als je het artikel leest, lees je het volgende
hoewel het bedrijf van plan is DEP in het volledige processorgamma te gaan verwerken onder de naam XD (Execute Disable).
Het zal pas XD gaan heten als het in de gehele range geimplementeerd gaat worden, vooralsnog heeft het geen naam volgens mij, of ik moet de whitepapers eens gaan doorspitten waar ik momenteel niet echt zin in heb.

Tevens ben ik geen die-hard AMD aanhanger, maar heeft deze producent op dit moment wel mijn voorkeur, dus aub niet stigmatiseren. Het valt mij alleen op dat Intel welke een zware PR machine heeft draaien, de consument graag doet geloven dat hun producten betere dingen bezit dan de concurent. (64bits extensies -> andere naam, wel overgenomen van AMD) en nu dat NX gebeuren.
Mobieltjes makers gebruiken toch ook dezelfde termen als hun concurent ... RealTones = Realtones etc ....
Volgens mij heb je zelf perfect aangegeven waarom Intel een andere benaming gebruikt.... 8-)
Dat sommige applicaties niet "draaien" zegt meer over de makers van die applicaties dan over de ontwikkelaars van service pack 2 voor windows XP.
Die hebben gewoon hun huiswerk niet gedaan.

Ik kan alleen maar bevestigen dat alles "draait" als een zonnetje.Bovendien is Microsoft met sp2 een heel stuk tegemoet gekomen aan al diegenen die
serieus meer veiligheid wensten voor de "king of desktops".Wie ook wel eens een kijkje in de keuken van het Open Source gebeuren heeft gedaan,weet mischien wel hoe lastig het ontwikkelen van geheugen beschermings technieken is met het oog op de compatibiliteit en continuiteit.Wel zou het eens tijd worden naar mijn mening als Microsoft een meer duidelijke scheiding
zou plaatsen tussen Home en Professional edition.
In Professional mis ik toch wel de modulaire aanpak
van instaleren zoals in diverse Open Source distributies.Je zou toch meer de keuze moeten hebben wat je wel en niet geinstaleerd wilt hebben.

Is ook een stukje veiligheid, wat niet aanstaat kan
ook niet misbruikt worden.
Is dit ook weer een onderdeel van de TCPA?
Nee, NX is geen onderdeel van TCPA. Het is ook geen beperking voor de gebruikers. Het is puur een onderdeel wat het besturingssysteem kan gebruiken om te controleren of programma's wel in het juiste geheugengebied schrijven. De CPU doet dus nog steeds wat hem opgedragen wordt, het is puur een feature van het besturingssysteem.

Uiteindelijk worden eindgebruikers beschermd voor dingen als buffer overflows die in sommige programma's zitten. Meer niet. Het is dus zaak van de programmeurs om hun programma's goed te schrijven, dan heb je nergens last van. Wel is er al n type programma's dat heel erg zal moeten oppassen, omdat dit juist gebruik maakt van het uitvoeren van code in data-gebieden in het geheugen: namelijk de just-in-time compilers, zoals die van de java virtual machine.

Trouwens, volgens mij is AMD niet de enige die NX ondersteunt, ook Intel doet dat met zijn nieuwe em64t processoren (pentium 4F), maar dan onder de noemer XD (execution disable).
Trouwens, volgens mij is AMD niet de enige die NX ondersteunt, ook Intel doet dat met zijn nieuwe em64t processoren (pentium 4F), maar dan onder de noemer XD (execution disable).
Die technologie zal wel bewust anders zijn om AMD dwars te zitten. En terecht dat die van Intel nog niet werkt. Ik vind het al erg genoeg dat ze Windows 64bit zo erg hebben weten uit te stellen. Ben blij dat ik tenminste nog iets van AMD's vooruitstrevende features terugzie voor ik aan een nieuwe CPU toe ben...
Die technologie zal wel bewust anders zijn om AMD dwars te zitten.
Nou, als de code van AMD wl ondersteund wordt, en die van Intel niet, lijkt het er toch op dat ze zichzelf aardig dwars zitten...
Uiteindelijk worden eindgebruikers beschermd voor dingen als buffer overflows die in sommige programma's zitten.
Was dat maar waar. Alleen bepaalde vormen van remote code execution door buffer overflows worden voorkomen.
De OSen doen dit ook... Waarom denk je dat er ondersteuning nodig is in de vorm van SP2?
Ik hoor het al:
allerlei programme's zullen niet willen installeren / starten zonder door een bepaalde procedure te gaan omdat de processor sommige code verkeerd herkent...
Wr meer werk hier in huis, met alle 6 de computer-analfabeten.
als de cpu ze "herkent" als verkeerd dan is de code niet goed geschreven. en kan er dus gebruik worden gemaakt van de buffer overflow. wat voor heel wat hack en fouten in windows heeft gezorgt.
@twabi2:
Ik snap niet waarom ze jou met inzichtvol modden. Het is bij service pack 2 gewoon mogenlijk om programma's te "excluden" van NX. In service pack 2 word het echter DEP genoemd en is het ook als software emulatie beschikbaar voor systemen die het niet ondersteunen.
Och, ik vind het wel een goede zaak dat consumenten tegen zichzelf beschermd worden.
En ik vind de processor een mooie plek om illegale code te filteren.
OS-en zijn te makkelijk te tweaken door hackers.
Zolang er voor pro's wel de mogelijkheid blijft bestaan DEP uit te schakelen (als ook NX of XD op de processor) ben ik voor.
De processor "herkent" geen evil code. De processor doet infeite niets meer of minder. Het enige wat de software nu wel doet, is de NX bit zetten in het geheugen, No-eXecute. En darvoor heb je hardware support nodig.

Kortweg: deze bit word gezet als het gebruikte gebied voor DATAopslag is, en niet voor gecompileerde bytecode. Dus de processor gaat niet evil code gaan filteren ofzo.
En darvoor heb je hardware support nodig.
Is ook niet helemaal waar, ook zonder hardware support werkt het gedeeltelijk. Dit staat er bijvoorbeeld op mijn pc (Athlon XP 2200+) bij DEP:
Your computer's processor does not support hardware-based DEP. However, Windows can use DEP software to help prevent some types of attacks.
Inderdaad, hardware support ! Deze feature zat al op de eerste 80386 en dan spreken we van 1985.
Oh nee, dat zat 'ie niet - ken je feiten! OpenBSD implementeerde als eerste OS deze functie in emulatie op x86 processoren. De enige processoren die dit in hardware ondersteunen zijn de nieuwe 64-bit chips van AMD en Intel en de exotische processoren die je onder de dure UNIX versies nog wel eens vindt. x86 kent geen verschil tussen data en code execute levels.
Met "hardware support" ging ik te kort door de bocht. OpenBSD's term "emulatie" is weer het andere uiterste. Wel is het: netjes gebruik maken van segmentatie en paging.

Mijn programmer's reference voor de 80386 (Kluwer, 1989) beschrijft in circa 20 pagina's deze aanpak. Ene Karl heeft dit erg aardig samengevat:
http://weblogs.asp.net/oldnewthing/archive/2003/11/04/55560.aspx, zie de reply van Karl

Edit: link gefixt
Jij bedoelt zeker de PROT_EXEC flag.
AMD: NX
INTEL: XD

Waarom kunnen ze niet hetzelfde woordje gebruiken?
*zucht*

Verder kan DEP handig zijn. Alleen hoe wordt bepaald wat 'gevaarlijke code' is?
Geheugengebieden die gereserveerd worden in programma's voor dataopslag, worden gemarkeerd met een non-executable flag.

Bij een buffer overflow is het zo dat attackers uit te voeren code op de stack plaatsen, een bug in een programma exploiten, en vervolgens de execution pointer naar dat stukje code op de stack laten wijzen. Dit geheugengebied is echter gemarkeerd als non-executable, en de processor zal het dus niet uitvoeren.
Even wat makkelijker voor de mensen die minder bekend zijn in het gebried van programmeren:

Bij buffer overflows wordt er gebruik gemaakt van het feit dat je meer data stopt op een plek dan er beschikbaar is.
Denk hierbij aan iets als 4 liter water in een 2 liter fles stoppen.
Doordat dit niet wordt afgevangen door de cpu kan het gebeuren dat de data die niet in het gereserveerde gebied past, op een plek in het geheugen terecht komt waar de code van het programma staat. Hierdoor gebeurt het dat de data gezien wordt als code en uitgevoerd wordt. Wat er dus op neer komt dat je dus met dit feit een programma andere dingen kan laten doen dan wat er origineel geprogrammeerd is.
De DEP (nx en xd) markeert data als niet uitvoerbaar. Dus als de data dan op een plek staat waar code had moeten staan, dan weet de cpu dat de data niet uitvoerbaar is en zal het niet worden uitgevoerd.
@NhImF

Dit is theoretisch inderdaad een mogelijke vorm van buffer overflow, maar niet welke deze dagen nog enige rol speeld. De pagina's waar code opgeslagen wordt zijn reeds readonly in windows. Een code segment op "NX' no execute zetten is een beetje vreemd natuurlijk en een data segment zal niet zomaar uitgevoerd gaan worden.

Het probleem dat met deze feature aangepakt wordt is die van buffer overflow problemen van tijdelijk op de stack opgeslagen data. Dit is dus geen code segment maar je stack segement en deze kan nu op NX (no execute) gezet worden, net zoals de gewone data segementen.

Het probleem met de stack, zoals deze op veel processoren is toegepast is het mixen van tijdelijke variabelen, tijdelijke data, register state informatie en terugspring adressen vanuit procedures en functies. Hierdoor is het mogelijk 'niet data', zoals de opgespagen registers en het terugspring adress van een procedure of functie te overschrijven. Door hier waarden in te zetten met een vaste en bekende uitkomst kan een kwaadwillend persoon de normale werking van je applicatie zo aanpassen dat er data uitgevoerd wordt die hij zelf aanleverd. Op deze manier kan er dus van buiten het programma, zelfs over het internet in bepaalde gevallen controle verkregen worden over je PC.

Dit werkt zo goed omdat de applicaties en het OS zo voorspelbaar zijn. Programma's worden in hun eigen virtuele geheugen gebied geladen en weken dus met vaste vooraf bekende adressen. Voor de meeste DLL's geld hetzelfde omdat ze een voorkeurs adres in het geheugen hebben. Door het bestuderen van programma code kan een hacker dus een waarde meesturen die een voorspelbaar resultaat geeft.

Een additionele oplossingen in windows en de X86 applicaties zou kunnen zijn om relatieve addressering (ook in AMD64) te gebruiken in combinatie met een 'zwevende' start positie van de code in de logische adresruimte van de applicatie. Dat maakt de code dusdanig onvoorspelbaar dat buffer overflows op de stack minder gemakkelijk zorgen voor het uitvoeren van voorspelbare code. Een aanval zorgt dan eerder voor een crash dan een gehackte PC.
nou, als programmeur weet je dat er bepaalde gevaarlijke code bestaat, zoals een situatie van "divide by zero" en de bovengenoemd buffer-overflow (zijn er meerdere, dit zijn maar voorbeelden), daarom heb je vaak controles in je software zitten en exception handling...
Gaat dat bij de eerste Sempron\\\\\\\'s wel werken? Dat schijnen toch re-labelled XP\\\\\\\'s te zijn?
Neen, als je het nieuws goed had gelezen zag je staan dat het voor semprons's met de K8 core gaat, de overige hebben dat dus NIET (die met de K7 core)

K7Core: 2800+ & lager
K8Core: vanaf 3100+ & hoger
Ik dacht dat NX net als het 64 bit gedeelte, uitgeschakeld zou worden in de K8 Sempron
Is dat NX-Bit gedoe niet een gewoon een ordinaire eerste stap van het Palladium concept?
Ik weet niet of we hier zo blij mee moeten zijn dan.
Ik bepaal zelf wel of iets uitgevoerd mag worden of niet. Zou je dat NX-Bit ook kunnen uitzetten?
Het is niet de eerstvolgende stap in het Palladium concept. Palladium werkt meer met signen van software en trusted parties. Het probleem daarmee is dat jij niet kan bepalen of een party vertrouwd kan worden.

De NX-bit is een van enkele functies om stack overflows te voorkomen en het "nuttig" effect van mogelijke exploits voor een cracker te verkleinen.

Informatie over de implementatie in OpenBSD:
http://www.infomatrix.ca/obsd/obsd_sec.shtml

Met deze functie is er weer een goede reden minder om een sparc of alpha te willen hebben voor een (critical) server. Maar tegenwoordig licht de nadruk meer op virussen bij Windows Workstations...
Ooit gehoord van een Chain-of-Trust? Palladium werkt voor wat betreft het signen van code hetzelfde als certificaten doen voor web applicaties: jij geeft aan welke Certificate Authority jij vertrouwt. Het feit dat jij aangeeft dat jij een CA vertrouwt, betekent dat jij ook de entiteiten die door de CA worden vertrouwd vertrouwt. Dus, nee, dit is geen probleem van Palladium.

Ik zie al dat Palladium gezeik sowieso niet zitten. Als Wintel er inderdaad in zou slagen om een computersysteem te bouwen dat voldoet aan alle negatieve Palladium-geruchten, zie ik een gouden toekomst voor Apple. Juist het open karakter van de PC zal ervoor zorgen dat heel die Big Brother hel die mensen in Palladium denken te zien nooit verwezenlijkt zal worden. Er zijn simpelweg teveel partijen die teveel te verliezen hebben... Wat dat betreft is deze NX-bit en DEP een goede indicatie van wat NGSCB zal gaan inhouden: een combinatie van hardware en software waarmee het voor developers makkelijker wordt om applicaties defensief te ontwikkelen, waardoor ze veel minder vatbaar zijn voor allerhande nu veel voorkomende exploits en attacks. Tot zover is zelfs Linus Torvalds nog enthousiast over NGSCB...
H, grapjas: die NX bit moet jij als developer zetten voor geheugendelen waarvan jij niet wilt dat die gebruikt worden als executeerbaar. Ga je me nu vertellen dat jij als gebruiker zelf de mogelijkheid wil hebben om te bepalen of een applicatie gevoelig mag zijn voor bepaalde types attacks? Ga je me straks ook vertellen dat je het "gevaarlijk" vindt dat web developers zelf kunnen zorgen dat een site tegen XSS bestand is? Of dat een DB developer zelf kan bepalen of een applicatie wel of niet vatbaar is voor SQL injection attacks? :Z
Is het niet een beetje laat om die Not Executable flag nu pas te ondersteunen? Alle respect voor het feit dat Windows dit ook gaat ondersteunen, maar mijn Linux bakkie heeft dit al een tijdje...
leuk dat microsoft het ondersteunt. wel jammer dat ze 't voor IA32 niet via emulatie hebben geimplementeerd. onder openbsd hebben ze dat wel gedaan (en dan heet 't weer W^X).

voor een leuk overzicht : http://en.wikipedia.org/wiki/NX_bit

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True