OpenBSD hoopt buffer overflows uit te bannen

Als alles volgens de planning blijft verlopen zal op 1 mei versie 3.3 van OpenBSD vrijgegeven worden. In deze versie zullen buffer overflows en de daarbij horende veiligheidsproblemen hopelijk tot het verleden gaan behoren. Om dit mogelijk te maken heeft het ontwikkelteam gebruik gemaakt van drie tactieken. De stack (de plek waar data is opgeslagen) wordt nu op een random plek in het geheugen neergezet. Verder worden belangrijke adressen binnen de stack nu op een random manier neergezet. Als laatste verbetering heeft het team het geheugen verdeeld in een lees- en schrijfgedeelte. Programma's komen terecht in het leesgedeelte terwijl data in het schrijfgedeelte terecht komt. Er zijn echter experts die opmerken dat er altijd bugs in software zullen blijven zitten en dat een product dus nooit volledig veilig zal zijn.

Reacties (31)

[Sfynx]

Ter informatie: de random stack base functionaliteit is ook in Linux te gebruiken door de kernel te patchen met grsecurity (www.grsecurity.org). Random kernel stack base schijnt nog niet 100% goed te werken, user level random stack base wel.

edit: foute URL

[EfBe]

Je kunt ook developen in een hogere taal dan rauwe C, waardoor je constructies zoals de string class of de vector class uit de std:: kunt gebruiken, waardoor je niet meer geheugen hoeft te alloceren voor buffertjes en dus ze ook niet te klein kunt alloceren, waardoor je buffer overflows voorkomt.

Beetje symptoombestrijding dit.

[Verwijderd]

Ja en vervolgens vindt men een overflow in een van die classes en is niet een product maar een hele serie producten kwetsbaar.. Beetje kip en het ei constructie dus.

[EfBe]

Nee, de std classes zijn bewezen veilig want zij doen de allocatie voor je, dynamisch. Dat is het punt: buffer overflows zijn bv in C# ook niet echt meer waarschijnlijk, juist hierdoor: je allocatie van memory laat je over aan bewezen routines die veilig zijn, waardoor je niet meer de fout in kunt gaan.

[Verwijderd]

En hier ga je er dus vanuit dat de "bewezen veilige" routines ook echt veilig zijn. Dat is per definitie al fout. Java was ook "bewezen veilig" alleen jammer dat de virtual machine dat niet was.

Het feit zit hem er in dat je nooit 100% zeker kan zijn dat je code "bewezen veilig" is.

Je kunt dus wel in managed code gaan schrijven maar dat is dus ook niet veilig omdat je niet weet of je VM veilig is. Als je een hogere programmeertaal gebruikt is er hoe je het ook bekijkt ergens een stuk code dat niet managed is geschreven dat je niet kent. De STD is daar een voorbeeld van, class libraries een 2e.

buffer overflows zijn bv in C# ook niet echt meer waarschijnlijk, juist hierdoor: je allocatie van memory laat je over aan bewezen routines die veilig zijn, waardoor je niet meer de fout in kunt gaan

Ik heb net een half jaar onderzoek naar c# achter de rug. Er is een reden dat versie 1.1 er nu is van het framework, neem dat maar aan.

[Verwijderd]

Er zijn technieken in ontwikkeling zowel universiteit als in het bedrijfleven om software te bewijzen. Denk hieraan aan meneer Hoare en zij Hoare tripels. Techinieken om software automatisch correct te bewijzen worden ook ontwikkeld. Zo kun in HOL bewijzen automatiseren. Een andere techniek is een model van je software bouwen en deze laten doorrekenen.

Dit is nog steeds erg kostbaar in tijd en hoogopgeleiden (man/vrouw)kracht. Maar wordt wel toegepast op essentieele systemen.

[ANdrode]

Het is een afweging...
Een erg snel product, of een product dat een stuk langzamer is.
Hoe hoger de taal is, hoe langzamer het programma in principe word.

[Verwijderd]

Hogere talen zoals c++ hebben ook nog hun overflows (integer, unsigned/signed int probleem bij malloc), het blijft dus kip en ei.

Pax ... en nu dus ook openbsd (die gewoon pax's research werk hebben gebruikt maar dat nooit zullen toegeven) lossen dit op een betere manier op, het hele probleem wordt zo ondervangen zodat je nog steeds buffer overflows kan hebben maar dat deze geen schadelijke gevolgen kunnen hebben.

[Verwijderd]

C++ is dan ook geen "hogere programmeertaal".

Een hogere programmeertaal, dat is COBOL, Pascal, BASIC of, om wat "moderner" te kijken; Smalltalk, Python of Java.
(En die laatste gebruiken niet toevallig allemaal garbage collection.)

[Dim]

Mwoah, je hoort altijd mensen dit soort dingen beweren, maar als je dan vraagt "Waarom is er dan nog niet een heel OS in Java of C# of een andere taal zonder buffer overflows geschreven?", dan krijg je zelden antwoord...

Het probleem is zoals altijd de legacy software, miljoenen regels code die je niet zomaar even kunt wegpleuren en opnieuw kunt schrijven in een "veilige" taal (hoewel ook dat zeker relatief is). We kunnen natuurlijk wel erover dromen, maar iemand zal zich moeten opofferen om al die ellende over te doen.

Daarom is dit initiatief best okay, je kan wel stellen dat het overgrote deel van de standaard "exploits" hiermee onbruikbaar wordt voor OpenBSD.

[Verwijderd]

Behavle het bovengenoemde feit dat C++ een C++ runtime nodig heeft (libstdc++), hebben jouw oplossingen ook nog eens een VM nodig. En guess waarmee je een VM het beste kan vergelijken... Met een OS!

Je zult dus eerst in machinetaal (delen kunnen in C of C++, maar dan heb je weer libstdc++ nodig en dus... Kip-en-ei) een VM moeten schrijven waar de rest in kan runnen, en pas daarbinnen kunnen talen zoals C# en Java runnen. Je verplaatst je probleem, je lost het niet op.

Om maar niet te spreken van de gruwelijke performance, ken je de systeemoverhead van een atomic operation in systeemtaal of C? Denk je nu eens in dat je daar een VM overheen gooit... Dat gaat op een 10 GHz machine nog niet draaien. .

Er bestaan we OS'en die in C++ zijn geschreven, maar om nou te zeggen dat die per definitie veilig zijn... Nah... AtheOS is er geloof ik eentje.

[Verwijderd]

Zeker waar -- gebruik van Java of C# kan een hoop van dit soort triviale problemen voorkomen. Het punt is alleen dat het juist voor een OS geen kwaad kan om zo goed mogelijk voorbereid te zijn op ALLE software, dus ook die in C of machine code geschreven is.

Een extra veiligheidsfeature daar kan je OS alleen maar sterker maken -- dat je daarnaast veel applicaties beter niet meer in C kunt schrijven staat daar los van,

[BramBo]

Er zijn echter experts die opmerken dat er altijd bugs in software zullen blijven zitten en dat een product dus nooit volledig veilig zal zijn.

dit lijkt me redelijk normaal

Als er iemand in staat is om een volledig veilig product te bouwen dan is hij bij voorbaat al binnen

[ANdrode]

een volledig veilig product bouwen is heel makkelijk, maar om het functioneel te houden is moeilijker!

[Verwijderd]

#include <iostream>

int main()
{
std::cout << "Hello World!\n";
return 0;
}

[Ralph Smeets]

Is dit simpele voorbeeld wel zo veilig als je zelf denkt?

Want je laadt een library met functies, genaamd <iostream>. Deze library laadt op zijn beurt ook weer een aantal libraries, waaronder stdio. Dus daar kunnen allemaal fouten in zitten.

En waar wil je Hello World op afbeelden? En hoe krijg je het in het geheugen? Inderdaad, je zult dus een of andere debuglink moeten gebruiken met alle nadelen van dien. Die link betekent onder andere communicatie met de buitenwereld.

Dit simpele "Hello World!\n" programma is meestal een milestone bij de ontwikkeling van een nieuwe CPU. Als je dat namelijk kunt afbeelden in de debugger, dan weet je dat de basis-functionaliteit van je debuger, link en OS waar je het programma onder draait werkt. Het zijn dus niet een paar regels C waar je het over hebt, maar enkele duizenden.

[goodfella]

hello world

[Verwijderd]

De stack (de plek waar data is opgeslagen) wordt nu op een random plek in het geheugen neergezet.

Zo'n simpele oplossing!

Ik kan er zo geen concrete nadelen bij deze oplossing bedenken. Als die er niet zijn zal het ongetwijfeld ook in de linux-kernel opgenomen worden. Goede zaak.

edit: maar goed dat OpenBSD geen patent op zo'n idee zal aanvragen. Sommige bedrijven zouden dat in ieder geval wel proberen en daarmee innovatie in de weg staan.

[EfBe]

buffertje wordt lokaal gealloceerd, dus in het stackframe van de routine, buffertje stroomt over, returnaddress wordt overschreven -> error (DoS waarschijnlijk).

[Janoz]

Goed, je kunt 1 computer/service/applicatie laten crashen. Je kunt echter niet meer (zo makkelijk) code uit laten voeren. Dat is juist het grote gevaar van een worm. Nu zal iemand specifiek computers moeten blijven aanvallen ipv dat de aangevallen computer op zichzelf anderen gaat infecteren.

Het meest schadelijke onderdeel was juist deze enorme verspreiding. Dat zal met dit soort technieken een stuk lastiger zijn.

[SvMp]

Programma's komen terecht in het leesgedeelte terwijl data in het schrijfgedeelte terecht komt.

Dit is iets wat heel normaal is, althans hoort te zijn. Een code segment is altijd execute-only, en niet te beschrijven. Ik zou het wel heel vreemd vinden als een op veiligheid gericht OS als OpenBSD beschrijfbare datasegmenten heeft waarin zich gebieden van codesegmenten bevinden, die ook van buiten de kernel toegankelijk zijn.

[Verwijderd]

Idd, volgens mij gaat het hier om readable en executable?

http://marc.theaimsgroup.com/?l=openbsd-tech&m=104391783312978&w=2 punt 1

[..] All real Unix systems I know of support PROT_READ and PROT_WRITE correctly, but PROT_EXEC has largely been implied as soon as you ask for PROT_READ.

This is because the pmap modules have been poorly written, or because the mmu's in question are not fully capable. This change makes a best effort based on the MMU in question to enforce PROT_EXEC as an independent flag.

Dus, wat-ie doet is PROT_EXEC onafhankelijk van PROT_READ. Dus in plaats van dat je zegt 'deze is readable en executable' kun je nu zeggen 'deze is alleen readable' en nu heb je de keus 'wil ik dat stuk readable wel of niet executable?'

[YoMarK]

Dit alles is al een hele tijd bekend, maar dat maakt natuurlijk verder niet uit.

Een heleboel toekomstige en huidige exploits(voor zover je daarover nog kan spreken) zullen op deze manier zinloos zijn/worden.
Zij hebben dus geen effect op OpenBSD en FreeBSD.

Ja..want voor FreeBSD versie 4.8 is een patch beschikbaar die ongeveer hetzelfde doet.
(Link: http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html)
Zou me niet verbazen als die in de volgende STABLE zit.

[jb044]

Altijd goed dit soort ontwikkelingen. Overigens voor mensen met linux een oplossig zoals deze voor OpenBSD is er nog niet, maar met libsafe en de openwall kernel patch kom je aardig in de buurt. Libsafe is een systeem lib die gevaarlijke functies opvangt en zo buffer overflows moet voorkomen en openwall maakt je stack non-executable.

Maar of je nou de nieuwste OpenBSD hebt of een linux met dit soort uitbreidingen, 't is een extra stukje veiligheid maar zeker geen reden om lekke software niet te vervangen. In het geval van linux bv waar ik ervaring mee heb: buffer overfows zijn haast onmogelijk, maar dat betekend niet dat het programma dat ze veroorzaakt gewoon blijft werken, 't wordt gewoon simpelweg beeindigd.

[bertjan]

OpenBSD 3.3 of is het toch versie 3.4 ?

Purging of dangerous string functions @ deadly.org

[Dim]

Nee, het verwijderen van 'riskante' string functies zoals strcpy(), strcat() enz is een project dat nu bezig is, en dat zal dus pas in 3.4 terecht komen.

Dit nieuwsbericht slaat meer op het invoeren van propolice. Er zijn op zich meer OS projecten die hiermee werken, maar OpenBSD is toch wel het eerste dat het consistent overal doorvoert. En daarbij zijn ze bereid om eventuele bestaande applicaties te fixen die hier niet tegen kunnen (het zijn er altijd meer dan je denkt ).

[Verwijderd]

weten we eindelijk waar Random Access Memory goed voor is

maar zoals hierboven al wordt gezegd, zolang code en data door elkaar heen blijft lopen, en c een taaltje is waarbij je elke byte expliciet moet reserveren, hou je problemen.
Ik zie dit soort oplossingen als 'mosterd na de maaltijd', een workaround omdat de onderliggende laag zwak is.
De enige oplossing is om c alleen te gebruiken waar nodozakelijk, drivers e.d., en voor de rest een betere programmeertaal te gebruiken. Maar gezien de hoeveelheid bestaande code is dat op korte termijn onhaalbaar, en zitten we de eerstkomende 100 jaar nog wel met buffer overflow problemen opgescheept.

[Dim]

Naast propolice, dat de stack beschermt, hebben ze nou juist precies proberen voor elkaar te krijgen waar jij het over hebt: het scheiden van code en data. Het enige probleem is dat de x86 architectuur daar te beperkt voor is, hopelijk wordt dat beter met de x86-64.

Voor de rest blijft het expliciet managen van memory in mijn ogen toch een voordeel ten opzichte van "bloated" talen zoals Java en C#, waarbij je nooit controle hebt over het geheugenbeheer (en heel typisch vreten de Java runtime en de CLR dus altijd belachelijke hoeveelheden geheugen).

[Verwijderd]

Ram indelen in read/write/exec geheugen is functionaliteit die in OpenBSD 3.3 niet geboden gaat worden op x86 en powerpc cpu's, alleen voor HP risc processoren en Sparcs en dergelijke.
Op x86s is er geen onderscheid tussen PROT_READ en PROT_EXEC.

Maar nou lees ik op openbsd.org weer dat deze beschermingsfunctionaliteit vanaf obsd 3.4 toch ook wel op x86 en ppc processoren wordt geboden. Weet iemand dan hoe dat zit? Wordt die bescherming dan softwarematig geemuleerd ofzo?