"De organisatie waarschuwt wel dat het inschakelen van ASLR op systeemniveau voor problemen kan zorgen bij oude videokaartdrivers van AMD/ATI. Deze problemen zijn echter sinds juni 2012 in de drivers van de fabrikant verholpen."
En die organisatie heeft alle bestaande hardware tot pak hem beet 15 jaar oud met alle combinaties geprobeerd of is het genoemd geval er toevallig eentje die ze waargenomen hebben. Ik denk het laatste.

Ik vrees dat je ook met andere software dan oude AMD/ATI videodrivers problemen kunt krijgen als je ASLR aanzet.

De reden hiervoor is dat, als softwareontwikkelaars en testers ASLR niet aan hebben staan, programmeerfouten of onverstandige aannames (die te maken hebben met in welke geheugenadresreeks data of uitvoerbare code te vinden zijn) onopgemerkt kunnen blijven.

Voor de niet-programmeurs: ASLR is net zoiets als dat de inboedels van alle woningen in jouw straat af en toe op willekeurige wijze verwisseld worden, en zowel de bewoners als de postbode een "vertaaltabel" krijgen (de oorsponkelijke bewoners van Dorpsstraat 1 wonen vandaag op huisnummer 25, 2 op 11, 3 op 31 etcetera). Het voordeel hiervan is dat een inbreker die zich toegang heeft verschaft tot nummer X, met als doel om via de tussenmuur in te breken bij nummer X+1 - omdat daar serieus iets te halen valt, een veel kleinere kans op succes heeft; hij kent die vertaaltabel namelijk niet.

Versimpeld voorgesteld in het geheugen van jouw PC: als een aanvaller weet dat na bijv. ruimte gereserveerd voor 80 bytes tekst, er uitvoerbare code volgt (die vroeger of later daadwerkelijk wordt uitgevoerd), en de programmeur er geen rekening mee gehouden heeft dat er meer dan 80 bytes tekst kan worden ingevoerd (bijv. omdat hij ervan uitgaat dat een achternaam nooit zo lang is), kan een aanvaller daar misbruik van maken door 80 bytes irrelevante tekst direct gevolgd door meerdere bytes met kwaadaardige code in te (laten) voeren - daarmee dus de oorspronkelijke uitvoerbare code (deels) overschrijvend.

ASLR zorgt er in zo'n situatie voor dat die uitvoerbare code waarschijnlijk niet meer direct achter de 80 bytes tekst te vinden is. Het is symptoombestrijding, want het verhelpt niet het oorspronkelijke probleem dat de programmeur er geen rekening mee hield dat iemand meer dan 80 bytes kan invoeren. Het is ook zeker geen fix, want er kan nog steeds geheugen bestemd voor andere doeleinden worden overschreven. Wat er in zo'n situatie gebeurt is onvoorspelbaar: het programma of het besturingssysteem kan crashen, er kan data corrupt raken maar het is ook mogelijk dat je helemaal niks merkt van een aanval. Het doel van ASLR, het voorkomen dat een exploit ertoe leidt dat kwaadaardige code wordt uitgevoerd, wordt echter (meestal) wel gerealiseerd - en dat is winst.

Het probleem met ASLR zit hem erin dat ook programmeurs er soms vanuit gaan dat data of code elke keer op dezelfde plaats in het geheugen staat - iets dat altijd klopte toen ASLR nog niet bestond en nog steeds klopt als niemand ASLR inschakelt.

Doordat ASLR nog steeds niet by default aan staat, laten we problemen (uit laksheid?) langer bestaan. Sterker, daardoor bestaat de mogelijkheid dat, vandaag de dag nog, programmeurs code ontwikkelen die niet (goed) meer werkt zodra een gebruiker ASLR aanzet. Hierdoor legt Microsoft het risico van het aanzetten van ASLR volledig bij de (security aware) gebruiker, die -schijnbaar out of the blue- met foutmeldingen of crashes te maken krijgt zodra hij ASLR aanzet. En als die gebruiker nou alleen maar ASLR aan zou hoeven zetten voor een substantieel veiliger systeem, zou die gebruiker even kunnen checken of uitzetten van ASLR zijn probleem oplost. Maar in de praktijk zoek je je suf als je meerdere maatregelen hebt genomen.

Daarom vind ik dat Microsoft veel meer beveiligingsmaatregelen standaard aan zou moeten zetten, en via een handige GUI foutzoeken zou moeten vereenvoudigen. Lever bijv. een VM mee waarin alle beveiligingsmaatregelen uit staan (waarin je de problematische software test) en waarin je via slimme methodes (binair zoeken bijv.) beveiligingingsmaatregelen in-en-uitschakelt tot de "boosdoener" is gevonden, en je met een zo veilig mogelijk systeem toch je werk kunt doen. Op Internet zul je vervolgens veel meer info vinden hoe te handelen bij problematische software, iets waar je je nu vaak een ongeluk naar zoekt vanwege de vage symptomen.

Voor oudere code (zoals kennelijk die AMD/ATI drivers) waarvan Microsoft zelf ontdekt dat deze niet goed werkt met ASLR, is het voor Microsoft een koud kunstje om specifiek voor dergelijke software (bijv. middels registerwaardes) ASLR te disablen. Dat niet doen is in deze tijd de wereld op zijn kop.

Dit is nou één van de vele dingen die ik bedoelde in https://www.security.nl/posting/538649/Microsoft+wil+internationale+afspraken+over+cyberwapens#posting538652 toen ik schreef:

Als je niet verder kijkt dan dat wat je toevallig in huis hebt. Je moet lezen wat er niet staat.
Er staat niet "we hebben alle hardware en drivers getest" Je kent hopelijk de gangbare denkfout van bewijs door maar 1 geval in ogenschouw te nemen. De buurman is een prutser (buurman & buurman) dus alle buurmannen zijn prutsers.
Ik ken genoeg van dat soort zaken.

ASLR is een security by obscurity manier. Beter zou zijn om de memory protectie met hardware en ringen van niveau's te doen. Dat moet een OS wel ondersteunen. Het is er een uit de oude doos. 1 byte per 4k page extra alleen voor dat doel.

Door het open karakters van de Intel dozen en het open karakter van het maken van drivers is het voor microsoft ondoenlijk alle software the valideren en aan te passen. Met RedHat zou je die rol toeschuiven voor Linux hetgeen ook niet lukt. Er worden zelfs opdrachten uitgeschreven voor nog te maken aanpassingen voor te maken specifieke hardware als one-offs.
Alleen Apple heeft een dusdanig gesloten systeem dat ze eisen welke hardware volgens hun mag. Alleen veranderd dat ook nogal snel kom niet met iets echt ouds.

Ik vind dat je daar het begrip security by obscurity verkeerd toepast. Die is namelijk bedacht voor algoritmes die de bedenker geheim houdt in de veronderstelling dat dat een bescherming tegen aanvallers vormt. De veiligheid van ASLR volgt niet uit het geheimhouden van een algoritme, het volgt uit de onvoorspelbaarheid van adressen, en dat is primair het resultaat van goede (speudo-)random getallen. Als je blobjes random data en sleutels en dergelijke onder security by obscurity gaat plaatsen wordt het hele begrip betekenisloos, omdat alle encryptie afhankelijk is van het geheimhouden van iets. Daar was de kreet niet voor bedacht, hij was bedacht voor de denkfout die mensen maken als ze verwachten dat een zwakke beveiligingsmethode door geheimhouding sterk wordt.

Zou het niet handiger zijn als Microsoft dit voor alle gebruikers instelt via een update?
[sarcasm]Want Windows is toch zo'n veilig en gebruikersvriendelijk OS?[/sarcasm]

Je zou toch mogen verwachten dat Microsoft een vrijwillig te installeren hierop gebaseerde Windows Update voor gaat aanbieden.

Het is beter om deze setting met het Windows defender security center aan te zetten en niet door de Registry te editten

Je snapt karma4 niet. Ja, de problemen in die specifieke hardware drivers zijn opgelost. Maar het probleem in specifiek die drivers is een gevolg van een onderliggend probleem, wat mogelijk ook invloed heeft op andere vendors. Dit is de reden dat Microsoft het standaard anders instelt.

Waarna er misschien een heel hoop gebruikers problemen naar voren komen, omdat hun applicaties niet met ASLR overweg kunnen? En al die gebruiker daarna vloeken op Microsoft dat die hun applicaties om zeep heeft geholpen?
Nee.... Het is geen verstandige keuse om zit zomaar even aan te zetten. Risico op gebruikers problemen is veel te groot.

Goede samenvatting. Het doet me denken aan de opmerking over root-kits van Microsoft (kan de link zo snel niet terugvinden): Windows is veiliger dan Unix want de eerste Root kit voor Unix stamt uit 1990 en voor Windows (NT) uit 1999.Tja, dat had meer te maken met het feit dat je in Windows heel lang geen geheugenbeschgerming had (en dus geen root-kit nodig had) omdat alles backwards compatible moest zijn met DOS en oudere Windows waar iedere applicatie overal in het geheugen kan schrijven...

Q

Als je in de ICT professioneel bezig zou zijn zou je weten dat datgene wat beweerd het minst interessante deel is.
Zoals de uitspraak Linux werkt op desktops wel te vaak in de praktijk gelogenstraft is omdat net die hardware het niet doet.

Waar staat ze alle hardware drivers voor de setting getest hebben?
-> Nergens.
Waarom zou microsoft het uitgezet hebben en niet standaard aan. Als ze niet tegen vele incomptabilteits issues met anderen hadden gezien dan was dat ook gebeurt. Ze (MS) waarschuwen er ook voor.
-> Wie zou het meeste getest en nagelopen hebben.
Gezien de effort lange periode moet je MS toch het voordeel geven. Zij zijn de maker bouwer tester hebben aparte gebruikersprogramma's als insider etc gedaan.

Interessante stellingname dat omdat het mechanisme bekend is het geen security by obscurity is.
Ik zie het ASLR bedenksel als een gevolg van het ontbreken van een behoorlijk memory isolatiemechanisme. zoals eerder gesteld uit de oude doos, hoofdstuk 3 protection. http://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1 het systeem moet een ankerpunt voor infoblokken hebben die zijn te achterhalen want verplicht fixed. Het is niet iets voor cobollers of andere normale programmeurs.
Als je verder komt dan is het veranderen van de standaard software soms vereist, Jet komt in het grijze gebied.

Met de SVC calls en andere interfaces de oplossingen om rond de machine-code instructies de hack te zetten. Dat werd door de leveranciers zo gedaan met het argument dat het toch niet uitmaakte het systeem wel veilig genoeg was om dat te doen. Vrij eenvoudige theorie om van iets wat je weet in het eigen deel ta manipuleren in andermans standaarden.

Vandaar dat ik het flat memorymodel dat in de gangbare hardware als fundamenteel zwak beschouw.
Nu kun dat fundamentele zwakke proberen randomisatie te maskeren, het lost de fundamentele zwakte niet op. Vandaar dat security obscurity terecht vind.

Zucht. Als je denkt dat 'flat memory model' equivalent is met 'ontbreken van geheugenprotectie' heb je nog wel een boekenplankje te gaan.
Het zegt niets over het (on)beschermd, writable of executable zijn van die geheugenruimte, noch over het al dan niet hebben van privilege levels.

Net zo goed als denken (en hier schrijven) dat memory protectie of verschillende CPU privilege levels ontbreken in Windows dan wel Unix/Linux .

Ik denk dat je uit de mainframe tijd komt, ooit geleerd hebt die geheugenprotectie hebben, en nooit meer in detail naar enig ander systeem gekeken hebt - en daar je misplaatste ideëen haalt over wat er zou ontbreken .

Het nogal uitgebreide IBM document waar je naar verwijst is (ook) de indrukwekkend _back_wards compatibility hacks die IBM moest doen over ca veertig jaar systeem - van 24 bits naar 31 (!) naar 64 bits adresspace , en allerhande bits om bijzonder low level implementatie gedrag te kunnen emuleren om maar compatible te blijven.

Je kunt bijvoorbeeld https://software.intel.com/sites/default/files/managed/7c/f1/253668-sdm-vol-3a.pdf (en meer) lezen voor de protectie features van x86 CPUs.

Alleen je blijft de uitdaging houden wanneer de control flow _binnen een programma_ , een verkeerde kant op gaat vanwege bepaalde condities [zoals externe input en events] . Je hebt protection tegen _andere_ processen, je hebt privilege levels tussen user en kernel, je kunt pages hebben die Niet Executable zijn, en de exploits die dan overblijven zijn meer gebonden aan het (her)gebruiken van bestaande/bekende stukken code die het programma geladen moet hebben.
Met ASLR is die code niet meer eenvoudig herleidbaar te vinden.

Roepen "ASLR doe je als je geen memory protectie hebt' bewijst vooral dat je in detail niks weet van moderne OSen.

Er _zijn_ inderdaad architecturen (CPU+OS+programmeertaal) die op echt ander niveau inzetten van geheugenprotectie. Dat was niet System 360 tm system Z en nakomelingen (noch x86)

Ze kunnen toch wel even een Fixit maken voor de gewone doorsnee PC gebruiker ?

You wish, MS fixit wordt niet meer ondersteund. Was veels te lastig, moesten ze namelijk ook steeds updaten.

Dat "lijvige dicje" was enkel de intro een enkel ça 5cm dik boek. De rest ging in 4 dubbele kasten compleet vol met de subsysteem en andere onderwerpen tot in kleinste details.
De moderne manier lijkt een Blog van een andere pakken te zijn.
Nogal een groot onderscheid.

Als je de intel zaken bekijkt en vergelijkt zul je het onderscheid zien. Het plaatje memory model verwacht intel via software in het os afgedekt te hebben. Ging fout met de 286 beter met de 386. Het belangrijkste verschil met de eerdere referentie is dar memory protectie door de hardware zelf gedaan wordt en op dat vlak niet afhankelijk van software is.
Zoek een op linux one bij ibm en je ziet het kostenverhaal. Het weglaten van die kostbare hardware opties maakt de boel goedkoper.

Voor de subsysteem echt multiuser dbms transactie interactief is dar verhaal van memory randomisatie en echte memory protectie gewoon uit de oude doos. De hele problematiek en de blijvende kwetsbaarheid als fundamenteel iets.
Dat is met de svc call anders omdat die echt een privilege switch doet ondersteunt door de hardware.

Ik geloof overigens niet in de toekomst van die mainframes als je dat mocht denken. IBM heeft het laten liggen. Ebcdic asciii ofwel Unicode krijgen ze nooit meer goed verwerkt.

Verder houd ik me meer bezig met big data waar ik alle basis fouten van ict en misvattingen over een os langs zie komen.

Dat geld voor een ieder.

Het meest simpele voorbeeld.
- je kan je uab interface tegen ongewenste code via software proberen af te schermen.
-je kunt met het doel enkel laden de data lijn touwtjes in de kabel fysiek verbreken. Zet er nog een overspanningsbeveiliging bij.
Wat zou meer zekerheid bieden met onzekere apparaten?

Als je veertig jaar hardware en OS in volledig detail wilt beschrijven heb je inderdaad veel volume nodig.
Destijds kon je op sommige werkkamers ook een paar vierkante meter oranje en grijze ruggen zien staan (DEC manuals)

En (net als nu en hier) maar bijzonder weinig mensen die ze allemaal ook snapten .


Nou nee, als je die Intel architectuur manuals zou uitprinten heb je ook een hoop meters papier - en dat is alleen nog maar de processor .
Nu zijn het alleen PDFs in plaats van een hele plank papier.


Hou toch op met bullshitten als je het echt niet snapt .

Misschien zie je je zelf als een old hand die hier Linux fanboys een beetje komt trollen, maar het doen alsof je expert bent terwil je die dingen gewoon niet snapt is alleen maar zielig - iedereen die wel wat snapt van software, OS design en CPUs ziet het rondstrooien van termen die net niet van toepassing zijn op de plekken waar je ze rondstrooit.

Het is ongeveer kaliber leraar (of ouder) die rap/straattaal probeert te doen maar zowel de uitspraak als de betekenis mist .

De enige memory protectie die zonder software werkt is ROM . De rest heeft software nodig om te markeren welk geheugen welke protectie heeft , en wie er privileged is en wie niet.
Als de zaak is ingesteld , is het de CPU die memory exceptions krijgt en controle aan het OS geeft .


En hier komen weer aan paar termen (en missende woorden en zinnen ) . "de subsysteem echt multiuser dbms" bla bla bla."
Jeez.
Transactie interactief ? Je weet dat een nogal forse workload van mainframes nog steeds batch gewijs is, inclusief daarvoor geoptimaliseerd OS ? Dat is bepaald niet interactief . Er zijn inderdaad ook interactieve mainframe OSen, en ze kunnen DBMSen zeker ook goed doen. Maar "echt multiuser" is bepaald geen exclusieve mainframe eigenschap , noch zijn dbms transacties of 'interactief' exclusieve mainframe kenmerken.

Maar verras me eens, geef eens een precieze verwijzing naar gebruik van memory address layout randomisatie in de IBM mainframe wereld - op dezelfde manier en metzelfde doel als in de Windows en Unix wereld ?

Misschien is het er, maar aangezien jij meent te weten dat het daar uit de oude doos is, laat maar zien .


Hou toch op met suggereren dat een x86 (of power, of Alpha, of Sparc) geen echte privilege levels zouden hebben.
De SuperVisorCall is gewoon de IBM term (mainframe en POWER) voor wat syscall of int 0x80 heet op x86, SC heet op PowerPC of trap heet op Sparc - aanroepen van kernel en switchen van privilege level, ondersteund door de CPU.


Ik geloof ook niet in de toekomst van mainframes, maar IBM is wel erg succesvol om er nog steeds geld mee te verdienen in hun niche - iets dat een hoop andere speciale systemen niet gelukt is. Ik zal ze niet al te snel dood durven verklaren.
EBCDIC is inderdaad een stevige reality check voor verborgen aannames omtrent ascii in heel erg veel software .
Maar het is slechts een software standaard in MVS en aanverwanten - Linux/390 aka zLinux werkt gewoon met ascii .


Veel echo en spiegels in het pand ?

@ Special agent 0:09
Stilte te verklaren door een forse workload aan biological interactive batch searches in virtal space with a lot of random accessed adresses. A.k.a. stilte voor de storm, druk aan het googlen naar linkjes om te strooien als een virutele piet met een scheur in de zak. Verzoek hier vaker dergelijke repliekjes te doen. Hard nodig.