Wat een onzin weer zeg. En nog +2 inzichtvol ook. Zowel chip makers als operating system ontwikkelaars, als software developers moeten samenwerken om security te verbeteren.
Developers kunnen fouten maken in hun programma (en dan heb ik het dus niet over het operating system zelf). Dit kan altijd voorkomen, maar zodra een software ontwikkelaar een programma heeft ontwikkeld wat in een hogere security draait en die is exploitable, dan is dat een breach naar een hoger security niveau (ofwel wat microsoft priviledge escalation noemt). En de meeste bugs zijn tot nu toe buffer overflows geweest (die dus semi-oplosbaar zijn door X bit). Dan heb ik het overigens niet over de script virussen, maar over de echte bugs.
De operating system ontwikkelaars zijn natuurlijk druk in de weer om ook een secure systeem in elkaar te zetten en willen dus niet dat third party producten voor een privilegde escalation zorgen. Vandaar dat ze dus technieken bedenken om dit tegen te gaan. Deze technieken worden samen met de chip fabrikant bedacht. De execute bit is een voorbeeld, maar wat dacht je van protected memory dat bij de 386 geintroduceerd werd?
Intel kan wel leuk een feature inbouwen, maar als een operating system dit niet ondersteund, dan heeft het ook geen zin. Beter is om samen die features te bedenken. Vandaar ook heel het Palladium / LaGrande concept. Security op hardware EN software niveau.
ps. Waarom vind je Windows een statisch OS
Daar klopt geen snars van.
ps. Waarom vind je Windows een statisch OS Daar klopt geen snars van.
De meeste buffer-overrun exploits profiteren van het feit dat ze exact weten wat er telkens op de stack staat, in welke volgorde, en hoe ze die stack moete manipuleren om zelf code ge-execute te krijgen door return adressen aan te passen zodat er naar hun code gesprongen wordt ipv. dat de controle teruggaat naar de originele code.
En dan kom jij vertellen dat een Windows OS niet 'statisch' is ? In heel veel gevallen is de exacte content van de stack te voorspellen. Iets dat niet echt logisch is bij een multi-tasking omgeving waar je niet van weet welke programma's met welke priority in welke volgorde draaien.
Windows werkt nog voor het grootste deel in hokjes, en dat is zowat de grootste reden van de blijvende stroom exploits. Windows is bijna compleet voorspelbaar omdat het OS langs geen kanten flexibel is...
Ehm... Elk programma heeft een eigen stack?! En het zijn juist de programma stacks die overschreven worden, waarna vanalles gedaan kan worden onder het user account waaronder dat programma draait (wat bij windows meestal administrator is).
Verder is het juist de bedoeling dat de stack een bepaalde opbouw heeft, anders zou het geen stack zijn. Ik zou wel is je design voor een unpredictable stack willen zien
.
Een oplossing voor dit probleem is niet zo moeilijk overigens, als je namelijk elk programma een code stack en een data stack meegeeft. Maar dat betekent ook 2 stack pointers. Dan zou er namelijk nooit met de jump addresses geklooid kunnen worden. Maar dat moeten de chipfabrikanten dan weer in hun chippie bakken, wat eigenlijk alleen maar meer mijn initiele punt benadrukt dat OS makers en chipbakkers met elkaar moeten overleggen.
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
09:25
22:50
Door 
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
