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 , , 80 reacties
Bron: MaxPatrol

Het beveiligingsbedrijf MaxPatrol heeft een manier gevonden om het in SP2 van Windows XP ge´ntroduceerde Data Execution Prevention (DEP) te omzeilen. DEP is een combinatie van de ondersteuning voor hardwarematige features in de processor (NX- of XD-bit, afhankelijk van of je het aan AMD of Intel vraagt) en een serie softwarematige aanpassingen in Windows' geheugenbeheer die beschermen tegen stack- en heapoverflows. Het probleem zit hem in het tweede deel: Het nieuwe algoritme - met zogenaamde 'cookies' om onbedoeld knoeien met de heap op te kunnen merken - bevat een paar zwakke punten waarop niet (goed) gecontroleerd wordt of de opdrachten wel veilig zijn. Hierdoor kan een lekke applicatie zelfs met DEP ingeschakeld nog steeds misbruikt worden om tot 1016 bytes naar een willekeurig geheugenadres te schrijven, willekeurige code uit te voeren en DEP uiteindelijk zelfs volledig te omzeilen.

Het bedrijf heeft de fouten in oktober ontdekt, en Microsoft is op 21 december op de hoogte gesteld. Er is op dit moment echter nog geen officiŰle patch beschikbaar die het potentiŰle probleem verhelpt. MaxPatrol zelf heeft wel een klein programma uitgebracht dat het gat dicht door strengere restricties aan te leggen, maar waarschuwt dat dit negatieve gevolgen kan hebben voor de prestaties.

Data Execution Prevention (DEP) screenshot
Moderatie-faq Wijzig weergave

Reacties (80)

zouden die 1016 bytes voldoende zijn om DEP uit te schakelen ? Indien ja, dan zit microsoft weer even ver als met SP1, want dan krijgt je in sneltreinvaart weer een resem trojans die dit gat misbruiken. Overigens is het aantal mensen dat nu effectief gebruik maak van DEP nog eerder laag te noemen. Het merendeel zit nog met een XP processor of een gewone Intel zonder F-suffix. Dit zal in de toekomst wel veranderen en dan is het maar te hopen dat MS zo snel mogelijk werk maakt van een bugfix.

Toch blijf ik erbij dat zoiets niet openbaar mag worden gemaakt voordat de fabrikant hier een oplossing voor heeft gevonden, of zelfs helemaal niet openbaar mag worden gemaakt.
1016 bytes zou in ieder geval voldoende kunnen zijn om een andere applicatie te starten...
Toch blijf ik erbij dat zoiets niet openbaar mag worden gemaakt voordat de fabrikant hier een oplossing voor heeft gevonden, of zelfs helemaal niet openbaar mag worden gemaakt.
Dan weet je iig zeker dat de producent er niets aan doet. Ze leren 't toch alleen maar de 'hard way'. Zolang het nog geen invloed op de verkoopcijfers heeft is het geen serieus probleem voor ze.
En wat als het nou eens een keertje niet mogelijk is om zo snel een patch te maken?

Omdat het bv te ingrijpend is waardoor de helft van de applicaties niet meer werkt?

Dan moeten de gebruikers het maar "the hard way" leren?

Als blijkt dat een bedrijf er niets aan doet, DAN mag je het van mij openbaar maken. Maar als het betreffende bedrijf wel bezig is met fixen, dan niet.
Doorgaans wordt 2 weken als een mooie tijd aangehouden tussen melding aan de makers en de publieke bekendmaking. Een maand is dus al vrij ruim.
maak je niet druk, dat gat is bij de hackers al lang bekend voordt een fabrikant erachter komt.
Toch blijf ik erbij dat zoiets niet openbaar mag worden gemaakt voordat de fabrikant hier een oplossing voor heeft gevonden, of zelfs helemaal niet openbaar mag worden gemaakt.
fout:als niemand het openbaar maakt doet ms er simpelweg niets aan
Dat is gewoonweg niet waar. Er zijn genoeg fixes die uitkwamen terwijl de bug nog niet publiekelijk bekend gemaakt was
Ik snap dit niet; Windows ligt toch als complete laag over alle programma's heen? Dan zou het toch alles moeten kunnen controleren dacht ik zo... :?
Windows ligt er dan wel omheen, maar het is nog wel de bedoeling dat het ervoor zorgt dat de applicaties gebruikt kunnen worden onder bepaalde voorwaarden. Niet om de boel hermetisch dicht te timmeren. Als gevolg van een fout in een van die voorwaarden valt de bescherming weg.
Niet de bedoeling om het dicht te timmeren? Wat doet microsoft dan nu al met het netwerk gedeelte van windows?
Windows is een ware vesting geworden van slappe oplossingen om een OS te beveiligen voor de buitenwereld.
Dat de helft van de software het na de installatie van SP2 het niet meer doet boeit toch niet?
En dat er alleen een SP2 is voor XP, terwijl andere windows versies (2000) nog steeds worden ondersteund, maar wel vergeten worden voor dit soort updates...
Draaien beiden niet nogsteeds op een (aangepaste) NT4 core?
@psyBSD
So? Wat wil je daarmee zeggen?
@spone

dat het niet zo moeilijk moet zijn om de update's van xp in windows 2000 te bouwen.
Euhm, voor Windows 2000 zijn er niet alleen een Service Pack 1 en een Service Pack 2, maar ook nog een Service Pack 3 en een Service Pack 4.

Dus hoezo alleen een SP2 voor WinXP? :)

Natuurlijk er zit niet hetzelfde in SP4 voor Win2k als in SP2 voor WinXP, maar het zijn dan ook gewoon andere producten :)
Het OS laadt de code in het geheugen en vervolgens de cpu die code laat uitvoeren... het OS is niet echt een laag, maar meer iets wat er naast staat... (een soort coach van een voetbal team ;)

Hoewel het technisch natuurlijk wel mogelijk is om een laag te bouwen, is dit complex, zeer slecht voor de performance ... en zo voort... en vervolgens is de kans op fouten in die laag ook weer groot vanwege de complexiteit...

@Gavin_Spearhead:
Een systemcall is meer dat een proces op een zijspoor wordt gezet (kernelspace). Het andere is een vm specifiek iets... niet echt beveiligings laag, en dat was waar het om ging.

@bzerk:
Lees mijn verdere comments, blijkbaar heb ik het niet helemaal duidelijk gemaakt... protected mode is een "beveiliging"... system calls kun je ook doen... maar dan kom je wat betreft privileges in een hogere "laag"...

Maar wat betreft instructies op de CPU uitvoeren... blijft het precies hetzelfde... er zit geen laag tussen instructies die uit een executable worden ingelezen, in het geheugen gezet en door de CPU wordt uitgevoerd.

Dus: er is geen laag die "OS" heet, die tussen het uitvoeren van de instructies uit het geheugen in zit...
system calls zijn anders wel een interface tussen applicaties en hardware. Bovendien vindt er een mapping plaats tussen fysieke en logische geheugenadressen. Dus een (abstractie-) laag zou ik het toch wel willen noemen.
De kernel (het OS) draait wel degelijk in een aparte laag. Namelijk in protected mode. Gewone programma's in de laag boven het OS kunnen maar een zeer beperkt aantal instructies uitvoeren.
Voor de meeste zinnige bewerkingen maken programma's dus gebruik van system calls naar de onderliggende laag (kernel/OS) die meer privileges heeft.
Ahum? Kernel draait in een ring, ring0. 'Gewone' apps in ring3, en als het goed gedaan is belangrijke apps op 1 en 2... zoals bv Xwindows op 1 draait op linux. Alles in protected mode, niet alleen de kernel ofzo. PM is kort door de bocht een mapping tussen physieke ram adressen en virtuele.
Het gaat over een gatenkaas.
Troll of niet, hij heeft wel gelijk...dit zogenaamde veiligheids snufje is nog niet zo lang geleden uit de hand van Microsoft gekomen...al uit de tijd dat ze zogenaamd zo erg op gebied van kwaliteit bezig zijn...en dan nog worden delen vergeten te controleren in de code.
Voor mij blijft het een feit dat Microsoft grotendeels nog steeds bezig is met features bouwen en later wel ziet of het nou echt goed werkt...als het maar zo snel mogelijk in het product zit.
Nog even voor de duidelijkheid : mensen die een opteron of athlon 64 hebben kunnen rustig slapen. Het omzeilt alleen de beveiliging op CPUs _zonder_ NX-bit.
In hoeverre deze mensen rustig kunnen slapen is natuurlijk maar de vraag. Het omzeilt een beveiliging die in deze processoren niet aanwezig is.

Willekeurige data execution is op die processoren dus zowieso al mogelijk.

Als er iemand een sleutel heeft waarmee hij alle sloten op deuren open kan maken, dan is het niet zo dat mensen zonder slot op hun deur niets te vrezen hebben :+

edit: typo..
Je vergelijking klopt volgens mij niet helemaal...
In dit geval lijkt het mij dat mensen met een NX-bit in hun cpu een slot op de deur hebben (hardware) en windows xp sp2 nog een mannetje voor die deur plaatst (software).

Het mannetje is opgeleid om alleen mensen met een geldige pas door de deur te laten, maar kijkt niet helemaal goed of die pas wel geldig is.

Heb jij nu geen slot op je deur (cpu zonder nx-bit), dan komt de kwaadwillende persoon dus gewoon binnen, terwijl anders de deur nog op slot zit (cpu met nx-bit).

Misschien sla ik de plank wel volledig mis, so please correct me if I'm wrong :)
Je hebt in zekere zin wel gelijk. Mijn punt was alleen dat de combinatie SP2<->NX een beveiliging toevoegt, en deze dus lek blijkt te zijn. Zonder die beveiliging kan het natuurlijk ook niet lek zijn, maar was je zowieso al niet beveiligd...

Jij doelt meer op wat windows met de NX bit doet... Als het OS de NX-bit niet implementeerd, heb je er weinig aan, je hebt dus zowieso je 'mannetje' nodig om de deur steeds weer op slot te draaien :P
Ik kan met mijn cpu zonder NX bit ook rustig slapen. Die staat namelijk uit als ik lig te snurken :+.
Volgens mij klopt dit niet helemaal hoor...
21 december... microsoft, jullie maand is voorbij.

alleraardigst hoe microsoft (via de mond van Nick McGrath in dit geval: http://www.vnunet.com/news/1160853 ) andere platformen afzeikt op 't gebied van security maar 't zelf echt compleet nooit waar weet te maken.

NFI, want microsoft maakt over 't algemeen prima software, maar wat betreft security blijken ze keer op keer compleet incapabel.
Mwja... Dat kan je zo zeggen... Wat je ook kan zeggen is dat doordat MS zo wijdverbreid is, er meer interesse is om MS te hacken/ aan te vallen.
Als je een Linux virus schrijft geloof ik niet dat je echt bekend gaat worden, want de verspreiding hiervan is veel moeilijker omdat 90% op windows draait. Natuurlijk maakt MS zich niet altijd even populair, dus is het " leuker" om virussen e.d. voor Windows te schrijven

Maargoed, je kan het uitleggen zoals je wilt of zoals je er prettig bij voelt. Deadline is dat MS tegenwoordig veel sneller en beter probeert over security na te denken... Of het altijd lukt is weer een andere vraag ;)
Dit gaat niet om een virus, dit gaat om een techniek... een techniek die onder Linux al meer dan 4 jaar beschikbaar is... die Open Source is, waardoor andere hackers fouten kunnen ontdekken in deze techniek... (En nee dit is geen populair open source gezeik maar waarheid... zie [1] en [2])

Als je dit had bijgehouden had je ingezien dat je iets heel doms opschrijft...

Voor hackers is het omzeilen van de SP2 beveiliging al lang geen nieuws meer, het is niet "stoer" meer... Voor Microsoft is het mooie promotie en alle "experts" tuimelen er mooi in.

[1] http://www.phrack.org/show.php?p=58&a=4
[2] http://www.phrack.org/show.php?p=59&a=9
Whoo, nog zo een die weet waar ie over praat...
Nou meneer "op z'n microsoft teentjes getrapt" hier gaat ie dan...

Blijkbaar heb jij ook niet echt door dat we het hier over een techniek hebben en niet over een bug...

"standaard zo lek als een mandje" nou nou... wat een uitspraak... Weet je wel wat voor bug het was voordat je de populaire microsoft-media napraat?

(Nee ik ben niet compleet anti-microsoft, maar dit soort mensen dwingen mij ertoe!)

En dus terug naar normale bewoordingen: Bugs in applicaties zullen er altijd zijn... De techniek (DEP/NX) zorgt ervoor dat address space bugs in de applicaties geen direct nare gevolgen meer hebben, of maar een beperkte impact. Als er dus bugs zitten in die techniek heeft het niet veel zin... Maar terwijl jij niet eens het verschil weet tussen address space en configuratie fouten... heeft het misschien helemaal geen zin om hier verder op in te gaan...
@BlouweKip
Lees jij door de week tweakers.net niet?
De afgelopen twee dagen hebben hier twee artikelen gestaan over een MySQL worm? Hoe kan je die nou gemist hebben???
Ik kan alleen wat vinden over verkeerd geconfigureerde mysql servers die standaard ook vanaf buiten te bereiken waren, dat heeft imho weinig met mysql te maken

Pas als je dan in de server was was er via een bug een binary op de host installeren, die bug is natuurlijk vervelend maar een goede admin geeft toch echt niet iedereen en iedere externe locatie toegang tot de mysql server
Sure, een OS kijkt niet real-time de code in, maar een os 'weet' welke code er op dat moment word uitgevoerd, daarom werkt die softwaremachtige beveiliging die nu omzeilt kan worden.
Als die open sources hackers dus zo geweldig goed zijn dat ze bugs vinden, dan moeten zulke configuratie fouten helemaal een eitje voor ze zijn.
dan zal ik je even voorlichten: standaard is het root wachtwoord in MySQL leeg, en kan dus "iedereen" inloggen. maar standaard is 't ook zo, dat je MySQL server via TCP/IP niet te benaderen is, en dit dus absoluut geen gevaar is voor remote attacks (overigens geldt dit in ieder geval voor Linux, onder windows heb ik er geen ervaring mee).

desalniettemin zou 't gewoon beter zijn dat je bij installatie een root-wachtwoord invult, absoluut. maar overdrijf dit mysql verhaal niet eh :)
Vergelijk het met installeren van een alarminstallatie in een auto, maar ondertussen laat je het portier open staan met de sleutel in het contact. Wat boeit het dan nog dat de alarminstallatie de beste ter wereld is?
Je zult het misschien niet zo bedoeld hebben, maar als je hiermee doelt op het gebruiken van MSWindows op een voor het overige goed beveiligde server (in bunker, met 'machinegeweerde' bewaking, druksensors in de vloer, bewegingsdetectors, de hele rataplan, supergecheckte server software packages, etcetc..) _dan_ vind ik hem heel grappig.
:P
@martijnvanegdom

Het OS weet dit zeker niet! De CPU "weet" het...
Die softwarematige beveiliging heeft te maken met heap allocation, wat via een systemcall gaat... dat is dus het zijstraatje wat je code ingaat... (zoals ik dat in m'n eerste post zei)
Het OS weet dus helemaal niets over de code die in een proces wordt uitgevoerd... maar de code roept "het OS" aan, specifiek de vm in kernelspace... dit gaat via een system call.
En daarin zitten wat extra'tjes... (die worden ook uitgelegd in het bovenstaande artikel)

@mjtdevries

Tering, jij bent wel vasthoudend over je mysql... ik verwijs naar de post van abraxas om je post inhoudelijk te ontkrachten, default is mysql dus wel goed...
Dit hele artikel gaat absoluut niet over mysql, en al helemaal niet over configuratie bugs...

Je had ook gewoon de url's kunnen lezen dan had je het misschien gesnapt... alhoewel... misschien ook niet.

Geen idee waarom ik hier weer op in ga... maargoed hier gaan we weer:

Ik heb het dus helemaal niet over de open source helden die alle bugs in alle code oplossen, ik heb het over technieken om op een hoger niveau dit soort fouten of te voorkomen of om de nare gevolgen van die fouten te beperken.

Bugs zijn helemaal niet moeilijk te vinden, het probleem is dat er meer code geproduceerd wordt, dan er ogen zijn en tijd is om de fouten te vinden. Die tools hoeven dus geen bugs te hebben, je mag van mij proberen bugs te vinden in de code van de vorige url's.

Een goed auto alarm-systeem heeft tegenwoordig een unlock code en een sleutel...
Ja, als jij MySQL gaat installeren en geen root password aanmaakt dan ben je zelf natuurlijk gewoon een eikel (personal oppinion, sorry).
@thevoid

Ja dat is wel populair open source gezeik.
Want waar waren al die geweldig open source hackers die fouten kunnen ontdekken dan bij MySQL? (dat standaard zo lek als een mandje blijkt te zijn).
Zelfs Microsoft heeft al een paar jaar in de gaten dat je een installatie niet meer zo kunt doen als MySQL het doet.

Mod het maar rustig als een flame, maar dit moet me toch even van het hart.
Want waar waren al die geweldig open source hackers die fouten kunnen ontdekken dan bij MySQL? (dat standaard zo lek als een mandje blijkt te zijn).
hmm, als ik mysql installeer dan is dat standaard helemaal niet zo lek als een mandje, wat bedoel je dan eigenlijk (kan namelijk ook geen recente grote vulnerabilities vinden voor mysql)
@BlouweKip
Lees jij door de week tweakers.net niet?
De afgelopen twee dagen hebben hier twee artikelen gestaan over een MySQL worm? Hoe kan je die nou gemist hebben???


@thevoid aka: "meneer op z'n linux teentjes getrapt":
Techniek of bug of wat anders is een niet ter zake doent detail. Feit is dat er door een stomme standaard instelling van MySQL een worm actief is. En op dat moment doet het niet meer ter zake waardoor het komt. Het kwaad is al geschied.

Bugs in applicaties zullen er inderdaad altijd zijn. Met name omdat bugs zo moeilijk te vinden zijn. En tools die dat soort bugs moeten voorkomen zullen dus ook altijd zelf weer bugs hebben. Maar configuratie fouten die een installatie programma standaard instelt, hoeven er niet altijd te zijn. Bugs zijn heel moeilijk te vinden, maar dit soort fouten zijn niet moeilijk te vinden.
Als die open sources hackers dus zo geweldig goed zijn dat ze bugs vinden, dan moeten zulke configuratie fouten helemaal een eitje voor ze zijn.
En TOCH zitten die fouten er gewoon in?

Wat heeft het voor zin om diep in code te gaan zoeken naar complexe bugs, als je ondertussen door een configuratie fout je systeem hardstikke open zet?

Vergelijk het met installeren van een alarminstallatie in een auto, maar ondertussen laat je het portier open staan met de sleutel in het contact. Wat boeit het dan nog dat de alarminstallatie de beste ter wereld is?
Als je een speciale feature in de cpu implementeert om te voorkomen dat er bufferoverflows kunnen gebeuren.. (een hardware feature) en het OS verneukt de boel dan sla je wel een flater imho.
Het argument dat meer virussen worden geschreven voor Windows omdat meer mensen Windows gebruiken klopt niet. Apache wordt bijvoorbeeld veel meer gebruikt dan Microsoft IIS, maar voor IIS worden meer en ernstiger veiligheidslekken gevonden.

Zie voor het hele artikel:
http://www.theregister.co.uk/security/security_report_windows_vs_linux /#execsummary
Je vergelijking slaat de plank volkomen mis. Iedereen heeft een besturingssysteem nodig en daarin is windows nu eenmaal de grootste. Het nadeel hierbij is dat 95% van de mensen die een computer hebben en op internet de boodschap krijgen "Your computer might be in danger" vervolgens alle instructies van deze aanbieder opvolgen. Hetzelfde met virusscanners, mensen kopen (krijgen) die bij aanschaf van de computer en verlengen nooit hun inschrijving op updates, waardoor alle virussen na een jaar volledig vrij spel hebben. Ook de update functei van windows is voor deze mensen een volledig onbekend iets, hoe vaak er ook op gewezen wordt.
Om nu weer terug te komen op je vergelijking. Iedereen die een webserver nodig heeft zal de server kiezen die voor hem het makkelijkst te onderhouden is. Aangezien de meeste webservers door mensen die er verstand van hebben worden onderhouden zullen ze ook updates en patches meteen installeren. Ik moet er ook niet aan denken om bijvoorbeeld apache met een php versie onder de 4.2 te hebben draaien wegens alle lekken die er in zitten. Lekken worden nu eenmaal pas gedicht als ze bekend gemaakt zijn.
Windows is hierbij een leuke prooi want de kudde n00bs die overal op klikt is gigantisch, waardoor jou inzet als malwaremaker vele malen meer beloond wordt dan als je een virus voor linux/unix zou maken.
Je zou je kunnen afvragen waarom het zo'n groot probleem is als "n00bs zomaar overal op klikken". Bovendien lijkt het me niet waarschijnlijk dat mensen wel zouden reageren op malafide boodschappen die ze op het Internet tegenkomen, maar niet op de boodschappen die Windows geeft omtrent nieuwe updates.

Je herhaalt in wezen alleen het argument "Windows wordt door meer mensen gebruikt, dus zijn er meer virussen en wat dies meer zij voor Windows". Dit doet niets af aan de vergelijking.
Deadline is dat MS tegenwoordig veel sneller en beter probeert over security na te denken...
Ik gok dat je "bottom line" bedoelde.
Als je vandaag een virus schrijft voor linux, het morgen op internet verspreid, dan is overmorgen met wat geluk de patch al uit. Ook zit je met het probleem dat niet iedere linuxbak op een x86 architectuur draait waardoor je voor ieder hardware platform verschillende varianten van het virus zou moeten maken.

Op linux heb je volgens mij veel minder kans om ge´nfecteerd te raken zelfs als er een virus uit komt. Dit komt door de vele variaties in linux en vele lekken zitten in non-kernel software die ook weer niet iedere linuxbak ge´nstalleerd heeft.

Daarbij komt ook nog dat de meeste services niet onder root/admin rechten draaien maar als gewone gebruiker.

En voor de rest heeft linux en virussen totaal niets te maken met deze nieuwspost maar Data Execution Prevention van windows. Een virus zou er wel gebruik van kunnen maken en dat zal beslist binnenkort dan ook komen. Als er een fout in linux zit met die XD/NX bits dan zou ik dat graag ook hier gepost willen zien. Of linux beter is dan windows hebben we het niet over en is afhankelijk van wat je eisen aan een OS zijn.
* 786562 spone
Het is vandaag de 30e, dus nog 1 dag :)
Nou vraag ik me af, blijft er nu nog iets van de reclame van de AMD64 over, dat het dus virussen tegenhoudt vanwege hun versie van de NX-bit?
Wat ik nog veel kwalijker vind, is dat het probleem in oktober is ontdekt en dik 2 maanden later pas Microsoft op de hoogte is gesteld!
Wat hadden de ontdekkers in die tijd allemaal potentieel kunnen doen?

[reactie op Guru Evi]
Bijvoorbeeld valideren of het echt een probleem is, of het (remote) te exploiteren is en eventueel een specifieke workaround maken voor hun eigen servers en/of klanten.
Dus daar mag je 2 maanden voor uittrekken, maar ondertussen wel klagen als Microsoft het niet in 1 maand kan fixen?
Microsoft hoeft niet zelf te valideren of het een echt probleem is etc?

Meten met twee maten noemen we dat.
In hoeverre de reclame al waar was wordt die er iig niet minder waar op. Het is een falen van Microsoft, niet van AMD... Ok, ik moet wel toegeven dat het wel hun product schaadt, maar het is iig een stuk minder erg dan dat de fout in hun processors zelf zat.
Nou vraag ik me af, blijft er nu nog iets van de reclame van de AMD64 over, dat het dus virussen tegenhoudt vanwege hun versie van de NX-bit?
mss wel, het is bij windows waar de fout zit, de cpu doet zijn werk.
Maar als het OS (grof gezegd) geen moer met de bit doet, dan schiet de bit zn doel toch voorbij?
dus als jij een auto zonder benzine hebt dan is je auto stuk |:(
De bladzijde ernaast staat een plaatje..
Waar duidelijk uit blijkt dat het os een layer tussen hardware en aplicaties is..

voorbeeldje
http://www.vgr.com/cybergfx/pics/WOA98/layers/temp/OS40/store/ms_compa t/OS40.gif

zoiets.. Enne software schrijven en functioneren is praktijk, dat is wat het boek beschrijvft..
Martijn:
Tuurlijk heeft een OS gelaagdheid in de vorm van hardware access, systemcalls, kernelspace... de bijbehorende privileges...

Maar waar het hier om gaat is het volgende:
Code wordt geladen in het geheugen en uitgevoerd, zonder dat het OS in de code zelf kijkt. De CPU doet de vertaalslag van logische naar fysieke addressen. Dus bugs in die code kunnen (op deze manier) niet worden ondervangen door het OS. De beveiligingsvormen die er zijn zoals DEP ondervangen niet de fouten (zoals bufferoverflows), maar mogelijk schadelijke gevolgen van zo'n bufferoverflow.

Het realtime of loadtime controlleren van code is praktisch onmogelijk... (kost simpelweg teveel performance...)
eh, ik loop al een tijdje mee, eh, ik vind MS best wel goed sinds XP, eh, ik vind Gates best wel een aardige vogel, eh, ik vind MS gebruiksvriendelijker dan andere platforms, eh, don't kill me, maar ik vind dat ik dit maar eens moet zeggen, eh, ik word een beetje niet goed van al dat jarenlange afzeiken, eh, ik denk als MS er niet was, het grootste gedeelte van jullie wijsneuzen nooit zover gekomen waren als je nu bent in de IT.

Stelletje structurele zeikerds, koop een telraam (chinees) werkt altijd en niet te hacken.

snoid
De Chinezen gebruiken Linux :P
De kritiek op Microsoft wordt niet uit de duim gezogen, ook al mag jij dat denken. Je hebt blijkbaar geen idee waar 't over gaat. Overigens, kritiek op MS betekent niet dat iedereen MS een snel faillisement toewenst of zo hoor. Sterker nog, een gigabedrijf als Microsoft heeft kritiek nodig om met beide benen in de buurt van de grond te blijven (ik zal niet beweren dat ze er nog op staan).

Maar goed, zolang jouw status op tweakers.net betiteld wordt als "Faalhaas" ( http://www.tweakers.net/gallery/106418 ) zullen we jouw onboeiende commentaar maar negeren, okay? Jij faalhaas dat je d'r zit :P
Microsoft kan ook niks goed doen hoor
Dan hebben ze een toch wel mooie technologie, krijgen ze zelfs de hardwarefabrikanten zo ver om het te implementeren, en als er dan een stukje code bij nodig is verknallen ze het weer!
Dan hebben ze een toch wel mooie technologie, krijgen ze zelfs de hardwarefabrikanten zo ver om het te implementeren, en als er dan een stukje code bij nodig is verknallen ze het weer!
Niet helemaal. Het is niet nieuw, en ook niet van Microsoft.

Hier een leuk stukje over technische achtergrond:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2239

Hier een overzicht van wat er op dat gebied al allemaal bestaat.
http://www.yotor.com/wiki/en/nx/NX%20bit.htm

Dergelijke systemen bestaan dus al jaren, vooral op andere platformen. Windows is zo ongeveer het laatste grote OS wat met support voor de AMD NX bit komt.
Alsof je MS kan verwijten dat het pas sinds SP2 geimplementeerd is:
De hardware methode bestaat al langer op de Itanium en de Sun Sparc CPU, maar daar draait Windows XP gewoon niet op (ok, maar heb jij dat ding in huis? welke mongool gebruikt er winxp op een professionele 8CPU server met slome x86 emulatie)

De i386 heeft al tijden een mogelijkheid om geheugenpagina's als executable te markeren en het OS moet daar dan op checken. Dit is nooit gedaan, omdat het snelheid verliest, ook is het te beperkt om fatsoenlijk gebruikt te worden, dus moet je het sowieso emuleren in software.

Pas bij de AMD64 kwam er een hardware implementatie in zicht die door de gewone consument ook gebruikt wordt. MS heeft in SP2 dit opgepikt en biedt behalve support voor dit NX gebeuren ook een emulatie aan voor CPUs die geen support voor NX hebben.

Voor OS'en als OpenBSD en linux bestaat dit al veel langer: OpenBSD heeft het standaard, linux heeft PaX of grsecurity. Echter wil dat niet garanderen dat je ook veilig bent. Hoe vaak zie je wel niet kernel exploits op linux waar grsecurity met zn geavanceerde ACL systeem helemaal niets tegen doet? Met AMD zn NX gedoe ben je niet veilig, het geeft je alleen meer tijd omdat het moeilijker is te kraken.

Als ik een grsecurity systeem opzet met userspace memory randomization, kan ik gewoon lekke samba versies installeren en exploits erop loslaten. Kans dat je alsnog gehackt wordt is heel klein, maar nog steeds aanwezig. Het geeft je slechts tijd om je samba bij te werken met een versie die niet lek is, iemand die doorzet kraakt de boel toch wel.

Verder vraag ik me af hoe erg dit ding is: met al die virus construction toolkits van tegenwoordig met stomme debiele VB proggeltjes, denk ik niet eens dat dat in 1016 bytes past.
De i386 heeft al tijden een mogelijkheid om geheugenpagina's als executable te markeren en het OS moet daar dan op checken. Dit is nooit gedaan, omdat het snelheid verliest, ook is het te beperkt om fatsoenlijk gebruikt te worden, dus moet je het sowieso emuleren in software.
Waar en niet waar. Het zit als volgt:

De i386 architectuur kan aan pages inderdaad attributen meegeven. Sterker nog, dit is volledig in Windows NT 3.51, 4.0, 2000, XP en 2003 ge´mplementeerd. Onder de NT cores werd dit gedaan met page attributen. Hierdoor hoeft de software welke zich aan de regels houdt niet te worden herschreven en kan probleemloos gebruik maken van deze technologie.

Het probleem zit dan ook niet in het Microsoft gedeelte maar in het Intel gedeelte. Binnen een page zijn er een aantal attributen mogelijk read, write, executable en nog wat. Per definitie moet een intel CPU een exception genereren wanneer een page op read staat zonder executable en er wordt code uitgevoerd vanaf die page. Het probleem is dat Intel het wel heeft gedefinieerd maar niet heeft ge´mplementeerd. De CPU doet dan ook niets met de attributen.
Totdat Microsoft de grote praseodymium vraagt om de code voor hun te maken, dan blijft alle software zonder problemen werken, en is de beveiliging in 1 keer helemaal top :*)

|:(
Als ze miljoenen aan marketing investeren (SP2) mag je toch wel verwachten dat het werkt!
Wat wou jij dan? Dat ze nog een dik jaar zouden wachten met SP2 omdat ze nog niet 110% zeker weten dat er totaal geen foutjes meer inzitten?

Dan begint iedereen te zeuren dat microsoft er niks aan doet.... En is de druk op microsoft om iets uit te brengen gigantisch.
Zo zie je maar weer als je bij Microsoft een (klein of groot) probleem aanbrengt en het niet publiek maakt, dat ze zich er weinig van aantrekken en nog niet eens de moeite doen om binnen de maand!!! een patch uit te brengen. Dat is echt ziekmakend. Ik kan me niet voorstellen dat dit bij open source zou kunnen.
ik snap je redenering niet goed hoor:
ze ontdekken het probleem in oktober en verwittigen MS pas eind december (vlak voor de feestdagen...), is het dan zo raar dat er nog geen patch is?
niet alles is te patchen met een paar regeltjes hoor

ik vind eerder dat ze MS reeds in oktober hadden moeten verwittigen
bij microsoft duurt 't altijd langer dan een maand.. ik kan daar echt geen excuus voor verzinnen (jij wel blijkbaar).

ik wil echt niet flamen, maar ik draai Debian, en als daar veiligheidsproblemen in ontdekt zijn is er _altijd_ de zelfde dag een fix (en het installeren daarvan kost nog minder tijd dan windowsupdate openen, dus qua gebruiksvriendelijkheid zit dat wel snor)

mjtdevries:
dat zie je goed ja, ik heb de hele maand doorgewerkt (ik had een deadline op 1 januari en die heb ik netjes gehaald) en dat mogen ze bij microsoft ook wel doen in dergelijke gevallen.
Dus jij hebt geen vrije dagen gehad in december?
Jij hebt de hele maand gewoon doorgewerkt?
Als reactie op thevoid:

Een Operating System is wel degelijk een laag tussen de Aplicaties en de Computer Hardware.

Ik heb hier een boek voor mijn neus liggen "Operating System Concepts" 1e jaars boek Technische Informtica Software Technologie Tu Deflt

"An operating system is a program that manages the computer hardware. it also provides a basis for aplication programs and acts as an intermediary between a user of a computer and the computer hardware"
Dat boek zegt dus dat het een laag is tussen gebruiker en de computer hardware.
En dat het een basis is voor applicaties. Maar dat is dus niet hetzelfde als een "laag tussen".

Daar komt verder nog bij dat theorie en praktijk nog wel eens wat afwijken van elkaar.

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